SoulMate – Global Game Jam 2012

NOTE: This post is a bit late, but its taken me a while to actually get around to putting together a version of our game that was suitable for the web. You can skip ahead and check out the game here.

During the weekend of Jan 27-29th, myself and numerous other game devs submitted ourselves to the gruelling process of attempting to make a game in just 48 hours. My team consisted of Pouya Aflatoun (art), Michael Theiler (audio), Jenn Sandercock (design/project-management) and myself doing the programming.

The theme for this years game jam was simply an image of an ouroboros (see below), a symbol that has been used to represent the cycle of life death and rebirth in various ancient and medieval cultures. Drawing on this theme we developed Soulmate; a game where the player must travel around a circular, wheel-shaped world looking for their ideal partner. When the player’s soulmate is found they breed and the player then takes control of child and the process starts all over again. There are two modes of play, Reality where players have a limited time in which to find their partner, and Denial, an un-timed “zen” mode with  unlimited play.

To make things interesting the little creatures that we created to inhabit this world were all given different combinations of three simple traits; a shape (circle, square or triangle), a colour (red, green or blue) and a voice/song (bird call, camel roar, or robot buzz). Finding a soulmate requires players to find a partner with the one trait they desire, but with neither of the two traits they are trying to avoid. The child produced when a suitable mate is found, takes on a single trait from each parent plus one randomly assigned one.

While we tried to keep our game design simple and minimise scope creep, this game still ended up being a bit more ambitious than I had expected. All the time we thought we would have to play-test and debug the game ended up being eaten up by development and wrestling with our own unique approach to version control*. In the end we did submit our game within the 48 hour limit, but it was fairly buggy and had a number of user interface and gameplay issues that confused players.

So in the two weeks following the Game Jam our team spent a bit of time polishing and fixing up the game for presentation IGDA Melbourne‘s post jam showcase. The end result is something the whole team is really proud of and I’m already looking forward to teaming up again for next years Global Game Jam!

Links:
Web Player Version (requires Unity Plugin)
Windows
Mac OSX
Original Game Jam Submission (with all the original bugs!)

* I had quite stupidly opted to manually merge exported packages over taking the time to install the free version of Unity Pro on offer that weekend and setting up Unity’s Asset Server. A lot of work was lost or had to be redone because of this. The lesson here; always go with the option that removes or minimises the risk of human error!

Done in a Flash! Wait? …where’d my holidays go?

Just before Christmas break Unity launched their open beta for Unity 3.5. To kick things off they ran a competition to showcase the new Flash Exporter in their developer preview by asking game devs to build a game in two weeks that exports to Flash.

So instead of just kicking back and playing Skyrim all holidays as I’d planned, I tried to see if I could put together an entry for this competition and expand my knowledge of Unity as I went. The end result was this very simple prototype/proof-of-concept I’ve dubbed “Lap-a-thon” (for lack of a better name). You can check it out by clicking here.

The idea was to make a simple slot-car-esque game where player control their car’s acceleration while switching lanes to overtake and avoid obstacles. I only managed to implement about a quarter of the features and content I had planned but building the game was a lot of fun and I learnt a number of interesting things, including…

Nice Art is Nice. I totally plundered the Asset Store for all the free/cheap art assets I used in the game. Which meant I barely had to rely on the dreaded “programmer art” at all. The game coud still use more polish but I’m just happy I didn’t have to name the game “Grey Box-a-thon”. It may sound dumb, but when my game looks nice I’m a lot more motivated to work on it.

Regularly test your Flash builds! The Flash Exporter is clearly in beta and not perfect and some stuff just doesn’t work. While this probably another obvious statement I have to  admit I found myself spending a whole bunch of time tracking down bugs that turned out to be caused by using features that just didn’t work with Flash. This could also be name “Read the Release Notes provided by Unity!” as that probably would have cut the time I spent  in half.

– Planning == Prioritisation. One of the things I’d really wish I’d done when I started was sit down and brutally prioritised the features I wanted to implement down to a few core things and either cut the rest or at least put them in order of importance. As it was I sort of winged it as I went (hey I was on holiday!) and really only started cutting features as the deadline loomed. Hence I found myself focusing on things I thought were easy instead things that were probably essential or at least more important. This is probably why Lap-A-Thon has a fancy-but-ultimately-useless title screen, yet no sound or music.

Regardless of mistakes made and the hi-jacking of my own holidays (I skipped out on a day at the beach to develop), I enjoyed the challenge and look forward to seeing if I can apply what I’ve learned at the Global Game Jam on January 27th!

News from the Tin Mines

   

These last few weeks I’ve been working with Ben Britten of  Tin Man Games here in Melbourne, helping out with some tech for their awesome Gamebook Adventures series of games. If you haven’t heard of Gamebook Adventures, imagine a Choose-Your-Own-Adventure novel mashed together with Dungeons & Dragons played on your iPhone or iPad. If you ever read any of the Fighting-Fantasy books when you were kid/adult then you’ll know exactly what to expect. If not then the title of the series pretty much sums up the experience: Game + Book = Adventure.

Tin Man Games have released seven Gamebook Adventure games to date and already has some very cool new releases slated for next year, including porting all their existing games over to Android, PC and Mac. Of course all these releases are going to need A LOT of testing and that’s where Ben brought me in to develop an automated testing program dubbed GAP (Gamebook Auto-Player) that can find problems and map the structure of each Gamebook Adventure. This would reduce the time needed to test a Gamebook by quickly finding any dead-ends or infinite-loops that might leave a player stuck as well as letting developers know how many unique pathways a player can take through each Gamebook.

Well, we now have the first version of GAP up and running, and you can read this excellent blog post by Ben over at the Tin Blog describing the whole adventure and how we managed to generate a 26 GB text file of data which only maps a small portion of the possible pathways through the first Gamebook Adventure: Assassin in Orlandes.

Our next task is to speed up the process. We had to leave the program running continuously for 60 hours to find 2.25 million pathways out of possible 500 million – according to our roughest estimates (which gives you some idea of how we ended up with 26 GB of data and why it took so long). But when its done it should make it much easier for Tin Man Games to test their games and hopefully generate a whole heap of cool data that will help them balance and improve future Gamebook releases.

It’s been a blast working with the guys at Tin Man Games, particularly on such a cool little project as this. If you haven’t checked out their selection of Gamebook Adventure title I recommend you do!