WITCH GAME? Dev Diary

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

Research

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;

• • A range of obstacles with newer and tougher obstacles introduced slowly throughout the game to keep things interesting

  • New challenges introduced after the player successfully "masters" a section of the game (measured by the number of obstacles passed)

  • Enemies which also become tougher over time and forces the player to manage flying and shooting. During initial testing, I died more times running into obstacles when trying to shoot an enemy onscreen, rather than to the actual enemy itself

  • New enemies as the game progresses, with different movement patterns increasing in difficulty

  • The ability to 'upgrade' your weapons with interesting downsides (e.g. The double shot fires two projectiles, but the path of each shot can sometimes move around enemies that are directly in front of you)

  • Randomised game over messages

  • A confusing name

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). 

Graphics

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;

For some reason I also looked at some math bits;

Actual animated bats were also added eventually

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.