Post date: Feb 02, 2015 2:23:6 AM


I wanted to design a game that made it simple for a player to grasp the initial concept, but challenging enough to keep the player motivated. My favourite mobile apps are the ones you can "snack on" - digesting short pieces of the app during a short break, such as on the toilet, where regular snacking is unhygienic (and you probably shouldn't do it but we all know you totally have). Duolingo is a great (non-videogame) example of this.

Endless runner games were the first games I researched gameplay mechanics - Adam Atomic's CANABALT (go play this right now if you haven't already) and Lima Sky's Doodle Jump are some of my favourite mobile games, as well Adult Swim's Robot Unicorn Attack. Games with one or two buttons reduces the complexity of player-controlled input with the challenges mostly coming from the player responding to the game's environment. 

The first game I looked to for visual inspiration was from 1985 Palace Software's Cauldron - My brother and I had a Commodore 64 growing up (although the C64 was already a few years old by the time we started using it) and Cauldron was one of my favourite games.

(Image sourced from WikiMedia Foundation - http://en.wikipedia.org/wiki/File:Cauldron-Gameplay.png)

The game involved platform and action elements, shooting at bats and pumpkins and flying around collecting magic from fountain sources (gameplay video here) and was tougher than an overcooked steak. Shout out to my mum for trading her sewing machine for the Commodore 64 in the late 80s/early 90s so that my brother and I could have a computer growing up.

Design and Development

The bulk of my experience in University was programming (B. Multimedia majoring in Interactive Entertainment and Games Programming at Griffith University in Nathan), mostly in ActionScript 3.0 (Adobe Flash), Java and C++. There were subjects on Adobe Photoshop and Adobe Illustrator but my favourite part was definitely turning lines of code into a playable game.

For WITCH GAME? I used Clickteam Fusion 2.5 - while my inner pure nerd wants to write code, my focus was on getting a game up and running quickly. Once I had the basic gameplay happening, I started to write down some ideas on how I wanted the game to remain challenging or interesting;

One of the first playtests with people who weren't familiar with the game showed a positive response - having a few stubbies with mates and one of us was constantly tuned out of the conversation while playing the game (I figured ignoring the real world directly in front of you and favouring the game was probably a good thing in this case). 


Here's how WITCH GAME? looked when it was an early prototype;

At this point the game is quite simplified - the play is represented by a circle and the obstacles are functional. The choice of colour is questionable; the solid fecal-brown palette used has the aesthetic appeal of a dead kangaroo on the side of the Bruce Highway in a Central Queensland summer, but it was the first colour I clicked on in the palette so it stuck for the time being.

Eventually I started looking at Greek and Roman architecture - I think I had the idea after talking about how I hadn't gotten around to watching Spartacus yet.

How it ended up in game;

Woops, made the flappy pipes

That's a bit better

For some reason I also looked at some math bits;

In game image

In game image

Actual animated bats were also added eventually

Early prototype

Click for animation

Optimisation And Other Nerdy Bits

Now that the game was functional and the graphics looked a little better than a smashed crab eating a dropped pie, it was time to fine tune the game's performance. 

Clickteam Fusion 2.5 excels at getting a game up and running very quickly. Memory management can be challenging though when you don't have code access to each individual class and object.

The biggest performance hits in the game were loading objects into memory. Initially, each obstacle was instanced and created off-screen and scrolled to the left, and it was up to automatic garbage collection to remove the object from memory. With each obstacle around the 640x1024px, this was a fair bit of data to be loaded into RAM every few seconds.

The more efficient approach used was keeping just three of these objects in memory at all times and never destroying them, with each different kind of obstacle a different frame of animation in the same object. Once the barrier object leaves the screen, it's position is moved to the far right of the screen ready for the next time the game decides to start it's movement.

The same approach was used to each particle effect generator - rather than spawning a new one for each projectile, the position of the particle generator was simply moved between shots and turned on/off once the projectile leaves the screen.