One Game a Month (#1GAM) 2013 – postmortem and retrospective

In 2013, I decided to participate in One Game A Month (aka #1GAM). The goal was to create a game with a proper start, middle and end, each and every month of the year. It was a bit like one big ongoing game jam.

While I don’t like to think of it as a competition, I’m still going to brag; I managed to rank within the top 100 after the 12th month (somewhere around ~75th). I’ll admit this helped push me to get games made in the last few months while juggling the responsibility of being a new parent, so I guess the ‘gamification’ aspect worked :) Here’s a rundown & some thoughts on the 11 games I made:

Warning mega-post ahead.

TLWR; I did One Game a Month and made lots of games, several of which I’m happy with the result. I made l a bunch of games that run on OUYA, kind of by accident. I’m not (intentionally) doing 1GAM this year, but if you haven’t done it, you should.



Big & Small (#1GAM web version here). I made this prototype for the OUYA / Killscreen CREATE gamejam. Since the response was reasonably positive, I decided to continue developing this game, with an aim for a commercial release as an OUYA ‘launch title’.


I didn’t do a #1GAM game in February, and I really should have. In this month I decided to prioritise work on expanding the Big & Small prototype, since I wanted to shoot for the official OUYA launch date with at least a ~5 level teaser. As it turns out, by April those launch dates turned out to be a little flimsy (with a protracted Kickstarter ‘beta’ launch, prior to the official ‘retail launch’ in June or July), the Unity plugin support wasn’t quite up to scratch at this stage (it’s pretty good now), and I’d grossly underestimated the time involved in creating interesting levels for this particular platformer. Additionally, some early sales numbers for OUYA games were trickling out and I felt like I’d never recoup my costs in time & artist contracting fees to make an OUYA launch worthwhile. To cut a long story short, by April I’d decided Big & Small wasn’t going to be a June/July launch title, but I would keep working on it casually when I felt like it.


  • Raxen's Run

Raxen’s Run. I’d been planning making something inspired by the Atari 2600 title ‘Nexar’ for a while, and I also wanted to do something with the Vectrosity Unity plugin I’d recently bought. The two goals converged this month to spawn Raxen’s Run. You might also notice some similarity to the original vector graphics Star Wars (1983) arcade game – this wasn’t really intentional, but I’m sure I played it once or twice many years ago, so I think some buried memory might have influenced the final result. It doesn’t help that Nexar itself was probably riding on the coat tails of Star Wars hysteria with enemies that looked like pixelated TIE fighters. I did a few things that I thought were interesting with this game. I made the levels a combination of procedural random generation within certain constraints, with progressively increasing difficultly, but fixed the random seed and overlaid hand tweaked waves and obstacles. This saved a lot of time I would have otherwise spent hand constructing waves, while still allowing specific challenges to be intentionally designed (eg, arrangements of barriers or enemy spawns). I also played with the post-processing effect visuals extensively, settling on an extremely glowly look (“bloom”) where distant objects effectively merge together. Personally, I really like this since it makes the visuals a little more ambiguous – I’ve noted that others dislike it, and those people are free not to play the game and make their own shooter with less glow. I called this my “Kongregate Experiment” – simply because I’d never released anything on Kongregate and Unity games on that site were a relatively new phenomena, so this made it a bit of an experiment for me. Questions: 1) Would there be much interest in a retro-styled arcade game the required the Unity plugin ? 2) Would there be any vaguely worthwhile ad revenue ? 3) How does the whole Kongregate highscore and achievement system work ? Results: 1) Basically, there was a small amount of interest in the first week or so, after which nobody played the game (except me occasionally, when I’d go to check the highscores). This probably shouldn’t be any surprise, since I guess a simple highscore attack game in the tradition of classic arcade games isn’t very ‘sticky’ for most players, particularly those flicking between a constant stream of new and polished web games. It wasn’t designed with the types of reinforcement schedules that a lot of Flash games use, and so I don’t think this style of game really meets it’s best audience on Kongregate. Or it’s just a crap game. 2) So far I’ve ‘made’ $0.53 on Kongregate. Woo ! 3) The Kongregate highscore and achievement API for Unity is awesome. Dead simple to integrate and easy to understand.



Def (the LD48 prototype). This is where Def started, and what became the ‘Practise Grid’ mode in the full commercial release. I forgot to post my LD48 postmortem for the prototype, but the text was lying around at the top of my original ‘design document’, so here it is:

Playtesting I only playtested by myself, and neglected to take time out from coding to throw a build out to the community for feedback. Even the kids that flunked Game Design 101 know you can only go so far without external playtesting, so it was a dumb thing to do. I even had the perfect opportunity – at about the 38 hour mark right before I went to bed. Y’all could have been testing for me while I slept, but I missed the opportunity.

Balance Tower defence games are pretty much all about balance (I say that like I actually know something about Tower defence games … in fact this is the first one I’ve made ever :) ). I think this is why they tend to appeal to a lot of designers, since there a lots of knobs to turn in order to tune the difficulty and elevate the player into the coveted ‘flow state’. The 48 hour version of Def had what you would call a …er… balance issue. A sufficiently skilled player could hold off the increasing waves until a point where as the enemy swarm reached it’s maximum, the player was able to build impenetrable defences. In most tower defence games I’ve ever played, this is the last wave, and once it’s over, you win that round. My intention was to eventually overwhelm the player no matter what, but because I hadn’t spent enough time mastering my own game before submitting, I only discovered that you could actually reach a stalemate. Since I only discovered this at about 50 hours into the compo, it was too late to define the stalemate as a ‘win’ condition instead. Thankfully, you are all generous and forgiving players – and all keep sending me screenshots of the stalemate saying “I win”. Yes, you do :)

I kept working on expanding Def into a more substantial (and balanced !) game in the following months, and released a version with a ‘story mode’ to the OUYA Discover store in September. I’m currently working on an expansion with a bunch of new levels and extra stuff for eventual release on other platforms.



Catching Tadpoles .. Oh my .. is that Comic Sans ! (Actually, I think it’s Apple’s weak attempt at Comic Sans glory, whatever that font is called). I made this silly little game because Sophie Houlden was running Fishing Jam, and I like Sophie, so why not. It was a good chance to play with Smooth Moves skeletal animation again.



Arriving in Damascus … fasten your turtlenecks and top up your red wine – here’s where we go all highbrow and artsy. Arriving in Damascus is a Dear Esther fan-fic game – a somewhat unique 3D first-person hypertext interactive fiction set in a post-Dear Esther universe. I like Dear Esther. There, I admitted it. Turns out I own most of the games tagged on Steam as “Walking Simulator” (and I’d love to play the ones I don’t). Primarily I made Arriving in Damascus as a way to battle test the “Twine for Unity” (uTwine) plugin that I’d like to release at some stage. Not only did this help generalise the uTwine codebase so it could be used more flexibly in other projects, but I fixed a whole swag of bugs in the process. This was also my first foray into seriously using Unity’s terrain engine with vegetation, and I discovered a few gotchas and solutions along the way. I really enjoyed replaying Dear Esther, and getting into the head of the protagonist, then producing my own prose that tries to mimic the writing style (complete with cryptic references to unseen characters in the original). I even worked in a simple puzzle, so it’s technically more game-y than the original, if you care about that sort of thing.



Shootshy:TE. July. The month in which I learnt that making a ‘simple’ vertical shmup that’s worth playing is hard ! I can’t say I’ve figured out the perfect system for sequencing enemy waves in the Unity editor … but I do have a (slightly painful) system. Still, I think it worked out okay, even if it’s a tad short. It’s on Google Play for Android now too. I intend to add more levels, at my own pace.


(no screenshot, boring)

Blackmarket. Move along, nothing to see here. Horrible embarrassing game – my excuse is that it’s another tech demo for uTwine. But it’s not one that I’m keen on showing widely since I’m sure it’s buggy and really no fun at all.



Flying High – a story book + hidden object game of sorts for very little kids. I made a large chunk of this in the times waiting around at the hospital where my first son (yay, I’m a Dad !) was born. The most time consuming part was removing and repairing backgrounds from the Creative Commons story book I chose to remix. Maybe it’s not really much of a ‘game’, at least for adults, but I think it becomes a game for a one year old testing and remembering what they can interact with.


2013-11-07 22:50:44:888 Editor Screenshot 1

20.8 % – Warning – another art-game alert. Here’s a chunk of text from a longish piece on G+ I wrote at the time, detailing how this came about:

I had already decided that a core mechanic would be searching for ‘oxygen’, which would deplete over time, ultimately resulting in death. I also knew that I wanted to play with visibility, and use that to indicate oxygen levels, along with breathing sounds. Then I went searching for Public Domain literature written about space or the ocean, looking for some text to use as inspiration (or wholesale steal). I ended up reading this – A Hundred Years Hence : The Expectations Of An Optimist by T. Baron Russell, 1906, (Chapter 6: UTILISING THE SEA): . Russell’s vision of the future and the challenges we might face with resources and continued human expansion set the direction for this game. It still blows my mind that this was written in 1906 ! I tweaked the colour to be ocean-like, so as to intentionally make it ambiguous as to whether the setting is space or the ocean floor. I tweaked the level generation to embrace the idea of increasing scarcity, and incorporated Russell’s text.

I also ended up putting this on OUYA, with a option to donate to the Sea Shepherd Conservation Society. On the technical side, this was the first game where I’ve hit garbage collection thrashing issues with Unity, along with some fiddly optimisation issues related to static/dynamic colliders – it’s playable but there are some framerate stutters that I’d ideally like to fix in a future update. Despite a few performance issues and the fact that this type of game usually attracts the derision of some ‘core gamers’, it’s been strangely popular in terms of ‘thumbs ups’ – and yet when OUYA introduced star ratings a few weeks ago, it ended up with a mediocre 3/5 star rating (average of 30 ratings). To me, this reveals some interesting dynamics occurring the the OUYA Discover store – I think people thumbs up based on primarily on screenshots alone, but ratings only happen when you exit the game, so they are biased toward people who start playing, don’t like it and exit quickly giving a poor rating on the way out. I guess I should have added shooting or something :)



>be worm – I think this is actually pretty cool, but it needs more playtesting. It’s a crazy local multiplayer worm race. You control the flexing (actually, lifting) of a worm with six segments, either using the keyboard (QWERTY) or gamepad analog sticks (left/down/right on each stick maps to segments 1-6), or a set of 6 buttons on the gamepad. It takes a bit of practise to effectively drive the worm, but it does work once you get the hang of it. You are also forced to lift the head, tail or middle of the worm to dodge/collect moving skulls/jelly cubes that help/hinder your progress. I’ve got a few ideas about some insane alternative controllers I could couple with this that would work well in a game party / installation type setting, but it’s going to require a little hardware hacking.


2014-01-23 15:18:39:198 Screenshot 44

Golden Scarab – I’m pretty proud of this one. In fact, despite the number of hours I’ve put into developing Def, or earlier in the year Big and Small, if I were to step back and be entirely honest and self-critical, I think Golden Scarab is the best game I made in 2013. Maybe even ever. I made it because I’d never made a proper dual-stick shooter, so I thought I’d give it a crack. My secondary goal was to force myself to learn to use some of the 2D specific features that had been added to Unity recently, and to learn to use Unikron’s 2D Toolkit. The short, psychedelic and intense gameplay was directly inspired by Rob Fearons shooters (most recently, War Daddy), as well as some stuff by Jeff Minter, Kenta Cho, and just a little inspiration from the philosophy of Locomalito. I was able to further refine my home-rolled leaderboard system and moved it one step closer to being something other Unity developers may be able to figure out how to use for themselves (Unity related changes aren’t in the repo yet though). I was so happy with the result I kept working on refining it in January 2014 and put it on OUYA.

The one that got away

Because I was anticipating that the birth of my son in September would slow things down on the game development front, early in the year I tried to get one month ahead by working on an ‘extra’ game for September. Sometime in April I made a clone of an old DOS game I used to play, “The Game of Harmony”, or “E-motion”, with the aim of adapting it with some new ideas and mechanics. I made some changes to the design, removing the Asteroids style ‘screen wrapping’ of spheres found in the original (basically since it was a PITA to implement in Unity, so I decided to just to try something different), and it turned out this completely changes how you need to approach the level design when compared with the original game. After producing a working prototype, including an in-game level editor, I decided it just wasn’t any fun. Actually, upon replaying the original, I can’t say that was much fun either … not sure why I played that game so much as a kid.

2014-02-22 13:17:19:113 Editor Screenshot 1

The one aspect of the “E-motion” clone that I liked was the ‘rubber band’ ball flinging gesture I’d made for touchscreen support (it only strikes me now that this was very much like the bird flinging gesture in Angry Birds). So I took this and started producing a local multiplayer ‘lawn bowls’ or ‘skeets’ type game, I tentatively titled “Disco Party Bowl 2000” (as a little nod to some of the magnificent Wii shovelware I own). I guess in the startup world this is what they call a ‘pivot’ – take the strong parts of what you have but switch to a new market, product or service. I spent too much time trying to get local multiplayer via wifi working with this prototype, (using the TNet plugin, which is okay, but it’s not the NGUI of networking), and I hit a few performance issues on mobile (largely as a result of my inexperience using Unity on mobile at that time – too many draw calls !). The game as it is kinda-sorta-works, but it’s not ready for anyone to play, and is missing piles of features and polish it needs to make it really ‘pop’. On one hand I feel like I should pick it up and finish it (I briefly tried in late December), but realistically I’d probably be better off taking the ‘rubber band’ ball flinging code and just starting from scratch, applying the skills I’ve learnt since to a fresh version of the project.

An accidental year of OUYA

You’ll notice throughout the year I made a lot of games targeted at OUYA, even if not all of them have been released on the OUYA Discover store. Part of this was because, at least early in 2013, the console was all new and exciting. Shiny ! I’m a big fan of OUYA’s mission, but it’s not like it stops me building for all the other usual (read more popular) platforms, depending on the game (hooray for Unity supporting a gazillion platforms !). Some types of games are well suited to touch screens, or mouse and keyboard, but many of the types of games I wanted to make are better played on a traditional style console with a gamepad. As a result, I found that putting stuff on the OUYA to playtest with a gamepad much more fun, and it simultaneously forced me to keep things optimised enough to run on recent mobile devices if I decided the game was suited to a touchscreen control scheme. From a business perspective making the OUYA my primary focus earlier in the year was a risk that didn’t really pay off – but it’s still a helluva lot of fun making stuff for it.


This year, I’ve resolved not to do 1GAM. It’s not that it wasn’t a fun and fruitful exercise in 2013 – the pressure to produce a game a month, come hell or high water, meant that I was able to test out lots of ideas, refine lots of skills and produce a bunch of games (some good, some bad). But that same time pressure meant that sometimes I felt I was reducing scope and cutting games short before they met their full potential. A few of the games listed above, given another solid month or two, have the potential to be a lot better (both in terms of gameplay, length, and in a commercial sense). Having to drop everything for at least a few days (often longer) each month meant that larger projects (like Def), moved much more slowly than I would have liked. The flip side, of course, is that without the motivation provided by 1GAM, I may never have started some of these games in the first place. There’s nothing stopping me picking one or two up to expand into something bigger this year.

Many thanks to the wonderfully positive Christer Kaitilia aka McFunkyPants for starting and continuing to drive the 1GAM initiative with enthusiasm, as well as all of the other 1GAMers that helped make it ‘a thing’ in 2013. If you haven’t done 1GAM … do it ! Start now ! Don’t worry even if you’ve missed the first one or two months of this year … just finish making a game with a start, middle and end this month. And then the next month. And then ….

One Response to “One Game a Month (#1GAM) 2013 – postmortem and retrospective”

  1. The study also shows that people benefit more by centering on eating the proper food than eating less food.
    If you think for any reason you must eat take out, just try not to eat it many time a
    week. There is a lot to be considered when it comes to having surgery
    also it should be done with pride and will ‘t be done


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>