Tag: thoughts

It’s been a busy past couple of weeks so I figured I would post a bit of an update on progress and upcoming plans.

Just before Christmas I uploaded All Ways Down to newGrounds and shortly after to Kongregate, with some reasonable success, managing to hit the front page of newGrounds just a few days after uploading :-). I received some great feedback from the users of these sites, which has allowed me to improve the gameplay, iron out some bugs and give it some more polish overall(I’ll include the full list of changes at the end of this post).

Because I’ve been working on these further updates I decided to temporarily put the android build on hold, and focus on improving the version that was available. But, do not fear, I am still planning on releasing All Ways Down on Android. However, I want to make sure it is ready and tested before I do so, which may take a little longer. Though I do currently have a stable finished build running on both a mobile and tablet so it shouldn’t be too long, it just depend on whether or not I add a feature I’ve been thinking about…

Now All Ways Down is almost finished, (again), I’m starting to think about my next project. I have a couple ideas in mind which you might hear more about once I’ve fleshed them out a bit. I also have a couple ideas for this site but we’ll have to wait and see.

So it’s almost been a week since I finished All Ways Down, and seeing as everyone else is doing one :-), I figured I’d do a bit of a postmortem of the game/experience, looking at what went right and what went wrong. Like many who entered, this was my first Ludum Dare, and whilst at times it was stressful( especially the last two hours), in the end it was an amazing 3 days and I had a lot of fun taking part. Overall, I’m very happy with how the game turned out, though there are plenty of things that I think could be improved (more on that at the end). The jam also meant I got to learn a bit about Unity webGL exporter, which up to now I had not really been following.

What went right:

The mechanic: The basic concept started quite simple, ‘a rolling ball that has to be a certain mass to finish a level, it does this by consuming objects and growing. Player can spin the world?’. From this I sketched out what I thought a level would look like with a simple storyboard for play and put some ideas for level hazards underneath. Thankfully I was able to implement this mechanic and it worked.

Thankfully most of the core development went quite smoothly(unless you count Unity crashing twice), with no major issues or bugs.

Sound: This is an area I generally find the hardest, but I’m quite happy with the end result, and have got some positive feedback on it.

Unity webGL, a day before the jam I decided to update unity. In hindsight this could have ended up going very wrong but, in the end it meant I learnt more about unity’s WebGL exporter, deciding from the start that I would use WebGL as my target platform.

What went wrong:

Whilst not wrong per se, based on feedback the ball could be a bit heavier at the start of levels, so that it moves around the level a bit quicker.

Deciding to make 5 more levels 4 hours before the end of the jam, resulting in no playtesting of these levels.

The size of the web player. I would have liked the actual game screen to be the max size allowed on this site, but unfortunately as this was the first time I had used the WebGL exporter I didn’t realise that the export size set in Unity doesn’t include the custom Unity bottom bar, thus cutting off bits of the game screen when its embed size is set at the same size as export. Meanwhile exporting without the Unity bar means you need to provided the functionality that makes it go fullscreen. I really wish I had known all this before the jam, and not learnt it in the last two hours when I was trying to submit😀

Whats next:

I think I’ll be developing this game further post comp. I’d like to make more levels, add in a couple of hazards and puzzle that didn’t make it due to time, along with polishing the graphics and adding more effects, maybe even a camera shake 🙂 . I’d also quite like to port it to mobile as I think its control mechanism is very well suited for the platform.

Overall I’m very happy with end result, and looking forward to working on it a bit more and making it even better 😀

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.

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.