Monthly Archives: August 2014

Last winter I was working on a Unity game project, discussing game concepts with 3D artist colleague Magne, namely the simplicity of “Flappy Bird”. How can it be that simple, and at the same time so addictive? We talked about having a go at it ourself, creating a spin-off or tweak to the concept. Shortly the idea of making a circular scene came up, like the old classic ‘defender’, but also inspired a little by the brilliant iPad game Osmos. Instead of the player going through ports, he/she would rather circle a planet only avoiding colliding into satellites or entering outer space. Our first goal was then to see if this was something worth spending time on – to answer that I created a prototype of the game. Try it for yourself, keep your black “spaceship” within the red “atmosphere” of the darker red planet, pressing the mouse or keyboard to add thrust clockwise.

Did you like it? Was it to hard? Was it at all addictive? I knew creating a prototype of the game mechanics was the only way to answer this, as simple and quick as possible. JavaScript provides that with simple coding, great number of resources, and using a service like JSBin – a super quick start without needing anything else than a browser installed. JSBin also provides revisions, so you can demo and compare the game to older versions. For more control now however, I have moved the game to my Dropbox continuing coding with trusty editor Sublime. I also find that it’s easier to debug outside JSBin, using breakpoints and the handy debugger statement.

I started developing the game with just moving DOM-objects around, but due to performance issues on mobile I ported it to use Canvas as it is highly optimised on mobile browsers. It also meant more lean code, as I could eliminate both jQuery and CSS from all together.

A (1k) challenge arises

After being more or less happy with the game itself, my focus turned to the code. Could it be squeezed into, and be suitable as a 1k JS game? A challenge was created for myself, which really ignites an extra fun factor in coding. I first remember reading a post on creating 1k games, with tips including substituting and and shorting method and variable names. This of course creates a lot of unreadable code, so a lot of comments was desirable. Take a peak at these excerpts from the game code:

Shortening variable names saved a whole lot of bytes in combination with normal tools to minify JS. However I later learnt that Google Closure has this ability built in, without needing do make your own variable names unreadable. I bit of information I wish I had before obfuscating my code into byte sized ugliness.

As a bonus Closure also analyses your code for efficiency and checks for errors. Note that while Closure shortens and substitutes your own variable names, it does not substitute JS own functions. There are a lot of bytes to be saved substituting Math method names, as they are extensively used in games.

A note on difficulty

After the first afternoon of coding, I wanted to preview it to a number of people. I posted it on our work intranet resulting a nice portion of constructive feedback. Interesting enough, I got colleagues both complaining it was to difficult, and at the same time having others achieving three times the high score I had. Surely it was a good sign that they bothered to play it so much.

The initial version started with numerous enemy satellites to crash with, a little too difficult start for some players. To mend this, the game now starts with zero enemy satellites, adding on for every 100 points the user scores, with the maximum of seven.

So, what do you think? Post your score and feedback in the in the comments. If positive, Magne and I might progress into implementing the game in Unity and publishing on the app-stores!