Antholojam was a month-long, remote game jam on the theme of golden age science fiction. The resulting anthology of some dozen games – curated at the point of application by Zöe Quinn and Alex Lifschitz – is due for release in January 2015. As the jam has wound up and the bug-free games have been submitted, I thought I’d reflect upon my time as designer, writer and UI artist under my team’s collective name, Wonder Games.
This was my first time participating in a remote game jam, having preferred to work in the same room even during Boob Jam in 2013* – my only other effort in such a format. I still harbour a strong preference for physical-location game jams, however I learned a lot from working in this fashion for a change. My overall conclusion is that A Planet Wakes ended up being a much more professionally-handled project, precisely because we had to co-ordinate our part-time efforts across national boundaries and a 6-week development period. Put simply, there a line quickly became blurred between hobbyist game jamming and the experience my team all have as contract game developers. Credit definitely needs to go to the other individuals who made up Wonder Games, namely:
* Coincidentally, also working with Delia. Sadly we were unable to finish Boob Jam, for reasons truly worthy of anecdote. By the time the weekend was over, a router had actually exploded.
Work began in mid-November after we’d drawn up our brief, submitted it for consideration and been given the go-ahead. Because of some tricky scheduling (mostly on my part) we had to front-end the design work even more than usual for a game jam, then attempt to build the game for a while without much further input. I was then able to start, designing the levels, balancing the game and writing our dialogue once we came into December.
Unfortunately this phase brought with it our first major hurdle, as we had budgeted for (and recruited) a dedicated artist, but by week two had no assets other than the placeholder ‘coder art’. We had to bring in different artists, to handle the game art and UI in a now narrower time frame. A short bout of recruitment on social media brought artist Liz onto our team along with a UI designer, but we hit similar problems again when no UI assets were forthcoming by the time our deadline was in sight. Twice we’d planned tasks around team members who then became absent, for one reason or another. Suffice it to say: we all learned a great deal about maintaining clear communication of responsibilities between team members, right from the start.
As it was, we managed to pull the game together with Liz’ sterling work on our game environments, and my stepping in to add fresh assets to Barry’s existing UI layout. Our process made use of GitHub, Trello, and Slack in particular – with message channels devoted to each stage of development. Our Slack was centralised around a standup channel, working in tandem with Trello to track check-ins and check-outs on current tasks, and to solicit quick responses on any work obstacles which might arise.
Speaking for myself, I believe that A Planet Wakes‘ design process was reasonably straightforward, building as it did on my past experience and really benefiting from time devoted solely to documentation. One of my secret joys is writing design documents, despite the fact they’re seldom used or maintained during rapid changes towards the end of the development cycle. It was, however, the only way we could ensure that a sound idea was thought up, then built upon during a time when not all of our team was present.
A Planet Wakes actually deviated very little from its original idea. We always intended to build a base-building strategy game, with about 3-5 levels and a narrative framed around the terraforming of a planet. We endeavoured to craft an intriguing narrative, conscious of our development time being relatively short, and in recognition of the fact the jam called for games to last no more than an hour. Neither of these factors allows for a particularly compelling amount of strategy – rather, we sought to introduce basic tactics, add supporting gameplay mechanics, and keep the player engaged through story delivered in the form of dialogue boxes. The latter was important because we knew art assets would be in short supply. This allowed us to avoid messy factors like animation, complex 3D modelling and texturing.
Specifics about the plot, the character designs, the levels and even the units were all designed at the halfway point of development, after Barry and Delia had crafted a versatile environment in Unity. Employing Unity Patterns’ TileEditor plugin, we built a game around 3 very basic ideas:
- management of 5 different resources, which are generated and spent by units in running costs and their initial construction;
- placing units, each of which has a different size and shape, so that they fit within a limited space and with access to all the resources they need;
- non-interactive dialogue, which would direct and respond to player actions as much as possible.
From that point on, I was able to simply develop units to achieve certain goals – be it to generate resources, unlock further technology, or act as plot points. The level maps were constructed relatively simply, testing the player on their spatial planning. I planned for a shift from a relatively pre-planned level with only one or two viable results, to freer reign and then the introduction of obstacles, which have to be weighed against access to more resource-generating units.
Resource flow was trickier, as I have yet to develop any more reliable tools than a running spreadsheet calculator, instinct and steady playtesting. Nor, on some level, do I feel the need to. Starting with the conceit that resources would flow every 4 seconds, I found my best approach was to set a metronome going and attempt to direct player actions to that rhythm. As long as the initial resource gathers (Vaporator, Magma Well, Arboreum and Nutrifarm) could support each other even when the player is in freefall, the game could stand. Every other unit from there simply had to pull on one resource in slight preference to the others, and strategy would emerge from ensuring that they were ordered only when the base was able to sustain itself.
As it stands, I feel satisfied with a level flow which steadily demands more of the player, but which only lays a serious threat of resource shortage in the final level. As far as I can tell, it is nearly impossible to complete with only basic resource units; the player simply must invest in metal, which is treated like a currency resource with which once can buy more advanced resource-gatherers.
I treat game jams as opportunities to try out new things, and this was my first time producing UI assets and writing dialogue. Although I am relatively new to UI, having only dabbled in its disciplines for the sake of paper prototyping before now, it is in A Planet Wakes‘ 146 lines of dialogue that I feel I learned most. More than writing barks, crafting name generators or drafting plot outlines, this was where I needed to stretch my creative imagination whilst simultaneously directing the player in the playing of the game.
It was a unique opportunity to try a different approach to tutorials – something I’ve only tackled through paced demonstration of mechanics and GUI prompts before now. I also sought to lend greater meaning to the abstract buildings the player installs on each subsequent base – again, feeding back into the game’s necessary but non-terminal brevity.
What I wrote is quite light, partly because I lack the experience to write epic arcs or breathtaking plot-twists. It was also my intention not to stray too far from the actual game mechanics – to keep the narrative rooted and believable, and not introduce conflict by either making the game look dull by comparison, or have the dialogue come off as ridiculous and distracting. Of course, only player feedback and time will tell how successful this attempt was!