Snowman’s Quest Post-mortem

Posted by (twitter: @dekart1234)
December 14th, 2014 3:05 am

LD31 was my fifth jam and it went in some ways better than previous jams, but I also experienced new issues I never hit before.

Snowman’s Quest is a top-down survival shooting game with a little twist – in order to win you have also to collect carrots to beautify a Christmas tree. While doing so you have to protect the tree from lumberjacks trying to hit it.

Play Snowman's Quest

Click to try the game

What went right

Idea

As soon as the first 4 rounds of the voting were finished I started thinking over an idea of a  snowman game. When the final theme was announced I found that my game idea fits it so I didn’t have to change anything.

Art

I don’t have much art in my game, only few objects which I had to animate. I drew all images by hand on paper, then made a picture with my tablet, and made final versions of the art in Photoshop on top of the hand-drawn drafts. All sprites are drawn in a significantly larger scale and then down-scaled – it is much easier to manipulate larger objects than object of a size of a pixel. In photoshop you can use smart objects to contain larger versions and resize them according to your requirements.

Coding

This is my second jam where I use a base code with a very simple app skeleton and all necessary libs. This time it was even more useful than before – after previous LD it became much more solid, so I was able to start implementing actual game logic from the first minute.

Scheduling

I planned my development in the following way:

  • Draw basic art with no animation
  • Code basic game logic using basic art
  • Add basic sounds
  • Deploy the game to make it ready for submission
  • Improve art by adding animation
  • Improve experience by adding particles, visual feedback of attacks, snowflakes, etc.
  • Improve sounds, add music

In the end didn’t have enough time to do the last task in the list, but it wasn’t mission-critical. I had a working game at the beginning of the second day and spent the rest of my time polishing it.

What went wrong

Lack of drive in the first day

Due to some personal reasons I wasn’t that excited about the jam as I was during previous events. After thinking over the idea I started working on the art and coding, but everything had a slightly bitter aftertaste because I understood that I could’ve done everything better if I had enough drive and passion for what I’m doing. At the end of the first day I spent half of my time   browsing LD website, reading status messages from other devs, and wasting time on trifles.

The second day started the same way, I didn’t feel any drive. I forced myself to finish some, started working on animation – and it hit me! As soon as I made the simplest possible animation of the rabbit (see it in action) – the game came to life! I started working on it like mad, it was exciting again.

Audio

My base code contained a library named Soundmanager2 which I was going to use for audio. However, after trying it I found that it didn’t provide the quality I was looking for. I used it for some projects before, but mostly for background music, so lags and long pauses when playing samples didn’t bother me. In this project however it was a critical issue – I wanted to synchronize audio and animation. I decided to re-write audio effects using pure HTML5 audio tag but it seems that it provides poor API and requires some dirty hacks to make everything work smoothly, so I spent a lot of time and didn’t manage to make it the way I wanted.

HTML5 technology

Despite the fact I was using a pretty stable framework and a modern Chrome browser I hit a very strange issue – frame rate in my game was stable at 60fps and dropped down to 30fps when closing developer console. I didn’t find any reason for this, not even clue. When playing in Firefox frame rate floated around 30fps with sudden drops to 15fps with no reason – I didn’t have any processes running on background, no actives, nothing. For sure, such drops immediately broke synchronization between audio and animation, spoiled the experience, and made me mad. I was thinking about trying Unity for this entry, but decided to go with a technology I already familiar with, and now I see that by doubts had a reason. For the next entry I’ll try Unity, definitely, since it’s the most mature technology for indie development at the market.

Conclusion

Choose technology wisely

It’s always a good idea to start with a technology you already know, but it doesn’t mean that the technology you already know is the best suitable for the mission. If your current tool set doesn’t allow you to make a game of a decent quality – it’s better to spend some time to learn a new technology before the competition. Otherwise you may end up fighting bugs in a mediocre framework or hacking your tools to make it possible to implement your ideas instead of polishing your own game.

Have a base code

Even simplest skeleton with vey basic things such as libraries you’re going to use will save you some time. You’ll also start your 48-hour journey working on your game, not setting up your work environment and tools.

Do something fun first

If you’ll start with boring stuff – you can fall into a trap of lacking motivation. All boring stuff can be made at the end when you already have a working game with something that makes you excited about it, you’ll be in a good mood to finish what has to be finished.

Deploy and test ASAP

You may not notice certain flaws until you see the game in someone’s hands, on a different machine, in a different environment. It is also very likely that at the end of the 48 hour race you won’t have enough time to think about deploying your game. Now we have an additional hour for submissions, but what if something will go wrong and you won’t manage to deploy your game in that time? It’s better to think about submission upfront, at least few hours before the deadline. Deployed version of the game will also allow you to give it to other players, show it to colleagues and friends.

Hopefully this post  will be helpful for your future developments and will give you some ideas how to improve your own workflow. What kind of issues did you hit in this jam? Please share!

Previous Posts:

Tags:


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]