New Project Announcement

It’s been awhile since my last project Mamore, almost two and a half months in fact, but during this time I haven’t just been playing through my Steam back catalogue whilst refreshing the Fallout 4 countdown timer(even though I may have a couple of times), instead I’ve been busy working on my next project. In fact you may have already seen some of the early screenshots and concept art for the game that I’ve been posting over the last month. Now today, I’m happy to officially announce my new project TaO-VARG.


TaO-VARG is a challenging action puzzle game where your goal as the player is to guide a Ballistic Acceleration ellipse(BALL for short) to the goal by using two special gravity particles: Thrusts and Orbits. Further, in order to successfully complete a level, not only must the BALL reach the goal, but it must do so within certain limits, these limits are imposed on the number of respective particles that can be used each level, with three pass marks(bronze, silver and gold) associated with how few(or many) the player uses. If the player reaches the goal but uses too many of a particular particle then they must try again.

The different pass requirements for a level.
The different pass requirements for a level.

In total there are currently 40 levels to beat, with the later levels becoming more and more challenging for the player(though some of the early levels can be a challenge as well). The levels start simple, but as the player progresses through the game they  will encounter a variety of obstacles, ranging from turrets to lasers.

An early TaOVARG level
An early TaOVARG level

The game is currently still in alpha, though it is finished for the most part(I’ll list the things I want to possibly add to the game at the end of this post, along with download links). But the game does need some fine tweaking. This is where I’d like you, the reader, to come in. Unfortunately I’m a bit too familiar with the game(having made it and all), so it’s hard to tell if some levels are a bit too hard. Therefore, I need some more widespread playtesting and feedback on the levels, so that I can put the finishing touches on the game. Basically, I’d like you to just play the game; if you finish it that would be awesome but its not a requirement, and hopefully whether you finish or not you have some fun doing so. And if you want to give me some feedback on the experience that would be awesome too, all constructive criticisms are welcomed.

Below you will find a link to a windows installer along with a standard Unity standalone package.

Windows Installer

Standalone Package

Things I’d like to add or do in no particular order:

-In game tutorial;

-Add more particle effects – for thrust particle, orbit and collisions with walls;

-Alternative control schemes, along with controller support;

-In game options menu, for controls, sound and resolution;

-More sound effects;

-Better end screen;

-Better aspect ratio support;

-Mobile version (This will likely come after all the others);

So that’s that, I had a blast making TaO-VARG, and I am looking forward to making it that little bit better with all your help 🙂


Project Reflection: Mamore

It’s been just over a week  and a half since I finished my last project Mamore. Similar to my previous project, now I’ve had a week to clear my mind,  I’ve decided to write a post reflecting on the experience and summing up a couple of the things I have learnt or came across during development.

Time Constraints

The idea and design of Mamore was solely the result of the IGM competition. In fact as I mentioned in my last post,  it was brainstorming with the idea of growth from which the game was developed. As a result, during the ideas development stage I was very much aware that development of game features was going to be constrained by the limited amount of development time. And that, whilst the competition stated that games did not need to be perfect or necessarily finished for the competition, they had to be finished and/or complete in a playable sense. At times I felt this limiting in terms of creativity, stopping me from going down and trying different avenues. However, I did find that it kept me focused on the core game and gameplay, preventing me from going down rabbit holes that would take time away from areas that needed it. For example, during development I focused on making a minimum viable product (ExtraCredits did a great Youtube video on the subject). This way, if time became constrained I would at least have a playable game. For Mamore, this was staying focused on the enemy block’s AI and the life block logic, the two elements that I felt around which the game was based; in hindsight player movement should have been in this list, but I’ll get to that in a moment. Elements I left until last were the purchasable items, turrets and traps,  particle effects, animations and sounds; things I wanted to add to the game but felt weren’t necessary to the core experience.

Physics of Movement

This is something that caught me near the end of the project, in fact on the day I submitted it. Much like in Click ‘n’ PoP where input was key, in Mamore a key element was making sure that movement felt right. Too often I have played a game, this applies to platformers especially, where the players movement just feels off, and for Mamore this is the core gameplay element. Now, I should say that unlike Click ‘n’ PoP which was actually broken, Mamore was not broken, it just didn’t feel exactly how I wanted it to; the player’s movement was just a bit slow and sluggish in nature. It played fine, and performed as it should, it just needed some refinement. And so this is exactly what I did; on the morning I was planning to submit my project I decided to put my head down and spent the whole of the morning playing with various values, tweaking them until the player’s movement felt just right.

In hindsight I should have done this a lot earlier in the development cycle, which would have allowed for further refinement. However, unfortunately that was not the case, though in the future this will definitely be at the forefront of my mind when I start a project.

Final thoughts

I feel that this projected helped to highlight that sometimes you need to focus on the core game and try and keep feature creep at bay, as this can consume time you may not have, especially if you have a tight deadline. It also made me realise that you should make sure you have all the base mechanics tuned, at least close to ideal, early in development, so as to allow for more time to fine tune. Overall I probably learnt many more things from this project than just the two listed, some I don’t even realise, but I feel that the above two concepts are things that, after a week and a half, stand out clearly in my mind. Much as I said in my previous post, whilst I realise the game is far from perfect, I am happy with how the game turned out and most of all I enjoyed the process.

Finally you can check my IGMC2015 submission, Mamore, here


New Game: My Indie Game Maker Submission – Mamore


A few weeks back, around the time I was finishing off Balloon pop, I was visiting HumbleBundle, if you haven’t heard of this site you should seriously check it out, games + charity = Awesome,  to check out their new main bundle, what I found was a bundle dedicated to making games, specifically, a bundle supporting the Indie Games Maker Contest 2015 (IGMC2015).

I wanted to find out more about this contest, and as I didn’t know much about IGMC I decided to investigate further. I headed over to the site and had a quick look through the rules and guidelines. At the time I thought it would be interesting to enter, but felt that I wanted to concentrate on finishing my then current project.

After I finally wrapped up balloon Pop,  I started thinking about my next project and what I wanted to do both in scale and type. I wanted my next project to be another simple-ish project but to be slightly larger in scale, a tad more ambitious.

It was then that I remembered the competition and thought it might be an idea to make a game that follows the rules and guidelines, that way if I finish it before the cutoff date, and I think it is good enough, I could enter it into the competition. And so I decided to investigate the competition a bit more. I headed back over to the site and reread the rules and guidelines, making note of the twist growth. At this point the competition had already been running for almost a week, leaving me about three weeks to make a game, which aligned nicely with the amount of time I wanted to dedicate to my next project.


After rereading the rules and guidelines, I started brainstorming ideas for projects that were somewhat simple and incorporated growth. I played around with a couple ideas, including a platformer where you must grow a central beanstalk to reach higher levels, but I felt this would take longer than 3 weeks to make. I wanted something simple both graphically and mechanically but still had some depth, whilst also adhering to the theme of growth. Eventually  I settled on an idea where the aim of the game was to protect a central block from a growing number of incoming blocks, and where these incoming blocks could also grow in size. I created a few concepts, settling on a style I liked before starting work on the prototype.

Early Concept


For most of the development from prototype to finished game not much really changed in terms of core gameplay and graphical style. Not to say things didn’t change, in fact as a game starts to flesh out you find somethings just don’t work or could be done differently. For example, initially there was going to be a health bar at the top of the screen to represent the health of the block the player must defend. But early in development I decided I didn’t want the top of the screen obscured, so I came up with the idea to use the block itself to take on the role of the health bar, changing colour as it loses, or gains, energy; along with the introduction of a two stage size increase as the energy drops/rises; I also felt this was a nice nod to growth. But for the most part the core remained the same.

Centre block changed from single size and colour to increasing in size and changing colour.

The majority of development time was probably spent on the enemy blocks, as not only do they add variety to the game, but also because I wanted each block to be slightly different. With different characteristics such as speed or its behavior once it got close to the target.

The last thing to really get added, other than last minute particle effects, was the inclusion of turrets and block traps. These were in fact in the initial design outline, but I felt I should leave them until last in case I didn’t have enough time to implement them properly, as the game was still fully playable without them. Thankfully this wasn’t the case however, and I feel they add a nice element of strategy and resource management to the overall feel of the game.

Final game, Particle effects were added to the lifeblock(centre block) and when the player destroys an enemy. Turrets and block traps were also added.

Final Thoughts

I realise the game is far from perfect, with plenty of areas for improvements, such as difficulty balance and different game types etc, but I feel that it’s a good improvement, even an increment on my last project, and was completed in roughly the same amount of time.
Overall I’m pleased with how the game turned out and glad that I stuck to the time window so that I could enter the competition, and most of all I had a lot of fun making it.

You can check out my IGMC2015 submission over at

Wish me luck


Project Reflection: Click ‘n’ PoP

Monday last week I uploaded the finished efforts of my first project using Unity. Since then I’ve had some time to reflect on the experience and to think about some of the challenges I faced and the solutions that I applied to the various problems encountered. As such I have decided to write a, hopefully, short-ish post about the experience.

Click ‘n’ Pop was the first game based project I’ve worked on for probably close to twelve months, which was due in part to being busy with University studies and just life in general. As a result of this I found that my design flow had become a bit rusty, added to this was the fact that I was trying to learn about Unity and how to use it. However, thanks to the many excellent Unity resources and tutorials out there, before long I found myself getting back into the swing of things and moving to full steam ahead.
I started by setting out a basic game design and overall concept; usually I would follow this by creating a prototype of the core game features. However, due to the simple nature of the game I decided to integrate the prototyping into the actual game development, as in my mind this was as much about learning Unity as it was making a game. And so I found myself progressing quickly, but it wasn’t before long I encountered my first problem.


At this point the game had progressed to a screen full of falling balloons (the original design had them falling rather than floating upwards), but something just didn’t feel right. As I playtested I would feverishly try and click on as many balloons as I could, but sometimes it felt as though the clicks just didn’t register. Initially I put this down to my poor gaming skills and that it was just me missing the balloons, and yet no matter how hard I tried to click accurately the problem persisted, which soon lead to frustration.
Now I admit that I’m not the greatest gamer in the world, far from it, and that games can, and sometimes should, have some difficulty to challenge the player, or at least enough of a learning curve so that there is a sense of accomplishment. In fact some of my most stand out memories as a gamer are the ones where I overcame something difficult or mastered a complex combo perfectly. But for me there is a considerable difference between a game being difficult because it challenges the player to do better, and a game being difficult because it is broken or has bad, non responsive input, and in this case it was the latter.

Something was broken

After doing some digging and a few web searches I discovered the cause of my frustration. The 2D box collider that I was using check if balloons had gone off screen, and if so destroy them, had the same Z value as the balloons. This meant that sometimes the mouse click would register with this box collider rather than with the balloons box collider, thus not triggering the code to pop the balloon. And so with one value change I found myself suddenly becoming a master of balloon popping, a god among mortals, a legend in the making…I’m sure you get the picture, it worked, the game was responsive, it was fixed.

Now that the game felt responsive I moved to implementing the colour target and multiplier, which I then followed with more play tests. It was at this point however, that I started to feel that the game just wasn’t challenging enough, even to the point of it not being much fun. I could just sit and watch balloons go past the screen for as long as I wanted, taking my time to decide which balloon would come to its early demise, without any penalty to the player. It was then that I realised that, even though this was supposed to be just a simple game, it was still missing something vital at its core.

Importance of Urgency

That something was urgency. That music speed increase as the timer runs out in platformers of old, or the quickly approaching obstacles that the player must masterfully align their character to avoid. These simple things create urgency which makes you want to get to the end of a level or tap the screen at just the right moment; this was what my game was lacking. At first I wasn’t sure how I could implement this and still make the game fair and skill based, rather than just random luck. The base mechanic was to spawn balloons of random colour, and the player must then click a balloon of randomly chosen colour. I played around with various ideas, such as having the game end if the player misses a balloon of the required colour. But a lot of the ideas felt too much based on chance rather than the skill of the player.

In the end I settled on the concept of a countdown timer. As the game progresses for every correct balloon popped some extra time is given to the player, whilst if the player clicks on either a wrong colour in haste or the timer reaches zero then it’s game over. Suddenly with this simple addition I found the game had a new lease of life, it was now a race that pitted the player’s accuracy against the clock.

After this I started putting the finishing touches on the game such as UI elements and menu screens, and thankfully this was all easy sailing.

Final thoughts

I learnt a lot from this project, and not just about how Unity works, it also reminded me there are some core concepts of games that can be easily overlooked or misjudged. The importance of difficulty in games is something I feel you learn about quite quickly in game development but urgency was something, at least for me in this instance, I had failed to appreciate the importance of. In the end the game, whilst not perfect (it could probably do with some time tweaking), did serve its purpose, to help me learn to use Unity and to make a simple, and hopefully fun game.


First Unity Project Click ‘n’ PoP Finished

Yesterday I finished Click ‘n’ PoP, my first Unity Project. Below is an overview of the game along with a link to play it in browser, with a standalone download version coming very soon.


About Click ‘n’ PoP

The goal of Click ‘n’ PoP is to simply click on a certain number of balloons of a given colour before time runs out. Each balloon popped gives the player a little bit more time along with increasing their score.

However, as the game progresses it gets harder by increasing the number of balloons on screen, increasing the number of balloons needed to be popped and reduces the time gained from popping a balloon.



You can play Click’n’PoP in supported browsers here.

Unity’s 10th anniversary: My First Unity Project

Last month Unity celebrated its 10 year anniversary, that very same month I started work on my first project in Unity. Whilst I think I’m a little late to the party, in my view a little bit late is better than never.

So far I’m still working on my first project, excluding a couple tutorial projects from Unity’s site, which I started a couple weeks ago. It’s a very simple 2D game, the main goal of which was to help me learn Unity, but it was also an idea I had for a game a while back which seemed quite simple and thus perfect for my first project using Unity.

Game Idea:

Pop screen1
Early game test

The game, currently called PoP(working title), is a game where the goal is to pop a given number of coloured balloons as quickly as you can in order to score points. The game ends if you click the wrong colour balloon or if the time runs out. That is it, as I said quite simple.

Overall I feel it’s about 70% done, with just sound and menu screens to finish. Hopefully I will have this all done by the end of this week so I can move on to my next project.


So far thoughts:

Compared with other toolkits and engines I have used Unity is a joy to work with. Everything, currently at least, seems straight forward and very easy to use. I’m definitely looking forward to the next few weeks of spending more time with it so that I can learn more about it, and have some fun making games.

First Post

Welcome to the noddingTortoise blog. This is the statutory first post which, whilst not particularly interesting, is required, much like writing a hello world program.

You can find out more about this blog/site under the about tab, though currently there is not much really to say about it, other than the awesome tortoise graphic in the header, marvel in the awesomeness of the nodding tortoise!

Anyhow, I don’t currently have a schedule for posting, though I will try and be somewhat regular, I may end up posting weekly or it may be monthly, you will have to wait and see. Whilst  if you’re reading this in 2016 and there are no other posts, then I decided to post yearly 🙂