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.
Responsiveness
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.
Joe