SA GameDev VI Challenge Post-Mortem: Psychopomps

The Something Awful forums run an annual game development competition. Participants are given one month to design and develop a video game based around a rotating theme. Everything, from planning mechanics and developing ideas to the actual creation of assets and code needs to take place between 12:01AM July 1st and 11:59PM July 31st. It’s a mad whirlwind of activity as developers, artists, and musicians come together to attempt to complete something worthwhile and still meet commitments to their jobs, friends, and families.

Like many of the other participants, I am a hobbyist game developer with big dreams of breaking into the industry at some point. This contest provided the perfect excuse to sequester myself from the world and really knuckle down to produce a portfolio worthy. Feel free to give it a play.

Psychopomps - Finished

The Finished Product: Psychopomps (Click to Enlarge)

Flixel (or, ‘Learning to Let Go’)

The single largest contributor to our success was to use an awesome Actionscript library called Flixel. Flixel did an enormous amount of the heavy lifting and asset management, and allowed the team to focus on gameplay concepts from day one. In fact, we had a playable demo on the first day that was loading a level, allowing the player to move around, jump into water, and aim at the mouse.

Day 1

Pyschopomps on Day One

In previous years that I’ve attempted to compete I’ve inevitably dropped out because I would hit the middle of the month and still be working on the best way to import a sprite sheet, realize I had no hope of actually getting to gameplay, and giving up. Like many other software developers out there, I have a compulsion to know exactly what all the code I’m using is doing. If I wanted to complete a polished game in a month, I knew I would have to stop worrying about the minutiae and trust in another developer.

It was a big leap of faith for me. I’ve been burned by engines before, and nothing is worse than hitting week 3 and realizing that the engine just doesn’t do what you need to complete your vision. I’m glad I made it, and I plan on relying heavily on Flixel for my games projects moving forward.

Set Aggressive Deadlines and Cut Features

From the outset, we knew we had 31 days to make a polished game appear from thin air. I’m a big believer that simple things executed well are better than complex things executed poorly. So I set a deadline for our feature complete status of 15 days into the competition, and did my best to reserve the remaining time for asset generation and polish.

Did I hit the mark? No. In fact, the third boss was added roughly 2 hours before the competition ended which explains his somewhat exploitable attack patterns. Still, the core of the game’s feature set was done on the 17th. It included all three characters, extra movement abilities for each character, all the enemies (plus all the code to support an enemy that was never used), support for all the sprite sheets and animations, asset loading, and game state switching.

If I failed to meet the deadline, why was it so valuable? It forced me to stop adding new things to the game and instead focus on making the existing things better. Everything added to the game after that point was to address an issue that the team or testers felt was a problem. One of the biggest complaints in initial tests with the wife and friends was that there wasn’t a clear direction or reason for the character to go and do things. Thus the Messenger was added to the game to provide some context for the Anubis character. The majority of the changelog after the 17th was about incorporating new assets provided by Jordan or Teck, changing some constants to tweak gameplay (bounciness of coins, for example), or smoothing out issues with the game like adding variable height jumping to the player.

Cut Features

Art Resources for Cut Features

Additionally, I found that having a buffer of time reserved for unexpected problems was invaluable. I think I set aside four or five days at the end of the month as a bank for issues earlier in the project.

Usability Testing

Roughly one day before the contest ended I posted the WIP build to reddit’s /r/gameDev for feedback. It was humbling, eye-opening, and incredibly useful.

Usability Testing

A Small Sample of the Feedback Received from Reddit

I found that if I presented the game to a fresh audience who had never played it before and gave them no introduction or instruction beyond telling them that I wanted their feedback on a contest entry I received very honest feedback. Within a few hours of posting I had a list of dozens of bugs and improvements that would be trivial to fix, but would address almost half of the players' main concerns with the game. Everything from the bounciness of the coins to the feedback for the player when he was damaged was covered, and I credit this usability session for making the game an enjoyable experience.

I just wish I had started earlier.

Spiral Model

My basic goal for development was to implement a new feature every rotation, collect feedback on it, improve it a little, then start another iteration. This worked astoundingly well for the purposes of cranking new features out. Isolate a single thing to improve on or add, give it one or two cranks, and put it down. For a small game on a short time frame like this it meant I could readily drop a new build on the IRC channel running parallel to the competition. The spiral model allowed us the flexibility to flow away from our initial vision of a game called ‘Psychopimps’ – a game featuring the three main characters out participating in the various questionable activities that a pimp does. It was much more of a slapstick game trying to eke out a few cheap laughs.

Charon Pimping

Charon decked out in his pimping gear

While the concept still makes me chuckle, I couldn’t connect a line from platform shooter to pimping underworld entities cleanly in my mind, and we ended up spiraling away from it. By only focusing on a single issue at a time, and not trying to mandate the game from the start, we ended up with a much more organic growth where we could experiment a little and explore what was fun without making long term commitments to the features.

What it did to my code, however… Well, that’s for another post.

Google Docs/Dropbox

I’m sure a number of other teams used a very similar model to ours, but we had all the code and resources stored in a Dropbox folder, which meant the other team members could update their work without needing me around, and I could keep them working with the latest releases.

We also kept a few files on Google Docs:

Asset Lists

The three of us did our best to maintain a list of assets required to support the features we needed, and tried to prioritize them. The asset lists grew a little out of date, but they were useful reference up until crunch time hit.

Design Log

This document was critical to our success. It was, essentially, a single running log of everything we did. Whenever I would go in and add a feature to the code I’d drop into the log and mention what I had done and why. Teck would use it to let me know when assets were done, or when he needed clarifications on the specs.

Design Log

The Design Log kept us communicating

It was totally informal, a giant team scratch pad, and we used it constantly. We never really had any issues with miscommunication (or lack of communication) within the team. Because Teck was in Australia, realtime communications were more or less out of the question, so every morning I’d check the document when I woke up and record my progress every night.

Fix List

A basic bullet point list of feedback experienced by us or people playing the game. I didn’t really act on these items until we were in the last week, but having a running backlog of all the things people felt were broken or issues was invaluable in properly polishing things up.