Last month I was contacted by Kotaku for interview to comment on the fifth annual Game Boy Jam (#GBJAM) and reflect on my entry, “Global Defense Corps”. The following postmortem is based upon comments from that interview.
A little background…
A couple of years ago, some fellow Ubisoft developers and I attended an IGDA meetup. A number of games were being presented, many of which were built over a single weekend at a prior Ludum Dare. Impressed and inspired, we decided to participate in the Global Game Jam the weekend following… I’ve now been taking part in game jams for around 3 or 4 years, and I don’t plan on stopping anytime soon. The nature of a compressed production can be incredibly satisfying; at the end of the jam you are going to have a ‘thing’ that you didn’t have before. The quality may vary, but you will have created a thing. On the flip side, accelerated development will give you a feeling of completion that full-time development may only provide every 2-3 years.
It’s not just as an escape from the larger productions that I am attached to with my day job. It is a means to tap into the games that got me interested in game development to begin with.
With all that being said, I was still rather hesitant to jump into another game jam, due to the bad taste left in my mouth by my last Ludum Dare attempt. However, this jam was different.
The Game Boy is very dear to me. I have the same fond Game Boy memories as many others do, I’m sure; from sharing tips on how to get past the looping forest in Link’s Awakening (spoiler: use the powder), to trading my Hitmonchan with my friend’s Hitmonlee in order to fill out my Pokedex in Pokemon. Oh, and Tetris. So much Tetris.
There are the less fond memories, of course; such as raiding TV remotes for batteries and failing to get the “right light” when playing in dark or bright conditions. But perhaps what makes the Game Boy so personal to me specifically, was that the Game Boy aesthetic became wrapping for my first indie game, Jack B. Nimble. All thanks to the second GBJAM back in 2013.
There’s something about that monochrome restriction and green glow that speaks to developers. Removing colours from the equation, (particularly from mechanics) can push developers to come up with interesting solutions in order to provide feedback to the player. For example, something simple like “blue key, blue door” or “red means enemy” must be approached in a different way. Just like most restrictive jams, they steer a greater focus on mechanics and offer an interesting art challenge.
This is why I love the GBJAM, it’s an excuse to indulge in that nostalgia. No longer are you using retro visuals to cut down on production time, costs or to satisfy the requirements of low-end hardware, but adhering to those limits to create something that (within reason) could have appeared on the platform. A couple of exceedingly talented people even do this and release their games on emulators!
For all of these reasons, I couldn’t miss another opportunity to work on a game like that again.
From the outset, I knew I wanted to work in a team for this jam. My plan was to focus on pixel art without compromising the design, so I needed a code buddy. I asked on Twitter if anyone wanted to join me in the jam, and Pete Smith (someone whom I had jammed with previously) expressed interest. I then contacted Barry Topping (a frequent collaborator of mine), and a team was formed. My responsibilities were the concept, level design, artwork and sound effects. Pete would handle systems design and all programming duties. And Barry would provide the all-important music. We were all based in the UK so time zones weren’t a problem.
After discussing how much of our free time we could reserve for the jam, we established a time frame. Neither Pete nor I were available for the first weekend and were busy throughout the week. We decided to treat it as a 3-day jam rather than the 10 days specified by the rules. This determined the scope of the project, and based on our past experiences, drove the design in a very specific direction; the Arcade-Action game.
In the first weekend, I was able to use some time (whilst traveling on a train) to sketch out a mockup of the game, as well as scribble various design notes onto scraps of paper. I sent a mockup (and notes) to Pete to help him define programming requirements, and to Barry to provide him with an aesthetic to work towards and form a tone around. The plan was to riff on the design of early score attack games that graced the Game Boy, such as Tetris or Alleyway, but with the art style of Link’s Awakening or Pokemon.
Although not actively working on the game, we spent the week thinking about the mockup and discussing ideas. Unfortunately, my Internet access was cut off for various reasons and our workflow was significantly altered. I was reduced to tethering my phone in order to upload assets. As a result, I was unable to download large amounts of data to run a local build. It wasn’t ideal, but we made it work.
Once we began the jam for real, I used the original mockup as a reference point and produced sprites and animations from there (almost entirely in PyxelEdit I might add). I began by providing first passes of the basic required assets; a character, a projectile, an enemy and a basic level, before moving onto the larger and riskier elements. This allowed Pete to start working on the core of the game while I continued to build the remaining assets.
Once we had our first playable prototype, we could nail down what our minimum shippable product would be. We judged which areas needed to be improved and which were timesinks to be focussed on or cut. The concept of multiple levels was dropped at this stage, in order to deliver a more polished experience. So rather than level-to-level progression, we instead opted for a single level with a high score focus.
Once the minimum shippable product was defined, we focused on reaching feature complete and simply iterated until the deadline. Barry provided the music track early in the process and later added a loop for the main menu.
In the final hours we were both feature and content complete, but the game was very buggy and the gameplay felt flat. There was no challenge, and everything played at a snail’s pace. It was down to the wire. It was in the last hour or so before submission that we fixed our biggest bugs. We also balanced the game in a way that it was both challenging and fair.
Basically, we increased enemy speeds and paced the spawn frequency. Quite simple really, but we needed those first rough initial values to build from. It’s crazy how a couple minutes work can change a project from feeling awful to becoming a polished, fun experience.
What went wrong?
The level design was upside down. The idea was to build a level that gave the player a chance to anticipate enemy direction. Players would toss bombs over the buildings to stop them in their tracks. Surviving enemies would be funneled into a kill corridor in the middle of the map. This would teach the player the basics with a manageable challenge, the first in a series of levels. Civilians weren’t even planned for this setup.
Due to our tight time constraints we had to lose the concept of multiple levels. Moving towards an endless approach meant moving all gameplay into that first level; a level that arguably couldn’t quite support the addition of civilians. It also didn’t offer a great deal of variety or options for the player. A very simple solution would have been to flip the building layout. This way, the player could make some meaningful decisions over where they should be shooting; i.e. in the left or right lanes rather than just the middle. We just didn’t have the time, and I feel that I should have had a contingency in place to support an endless approach rather than a series of levels.
I was also a little disappointed that we didn’t get to scoreboards. That may have been a way to retain player interest for more than a couple of minutes (a criticism we received in abundance). Though admittedly, we didn’t have the time to fairly tune the score system.
What went right?
From an art and design point of view, my goal was to aim for authenticity. As far as the visuals were concerned, they needed to be feasible on a real Game Boy. I feel that we nailed this. I also love that we managed to achieve a polished experience with very few bugs in such a short time. With our additional self-imposed time limits, the achievement felt that much greater.
All in all, we were all very happy with how the game turned out. Pete and I have had some early discussions on whether we should go back to this idea and flesh it out for iOS, but it’s still early days and my focus right now is on Jack B. Nimble and Star Marine.
If you’d like to play the finished game, check the banner below.