Convergence Postmortem

uDevGames 2011 Entry

• 1st place Best Gameplay
• 4th place Overall

Overview

The concept for Convergence is something I’d been kicking around in my head for the better part of a year. I wanted to make a game about roles and interactions; situations you’d have to solve differently based on what sort of character you were playing, with many possible choices. I’d also been itching to work on an adventure game, with a real story, world, and characters. I never wrote a design document or made any kind of start-to-finish plan for the game, so the concept mutated week-to-week as I worked on it. You’ll notice a lot of what I just wrote didn’t make it into the game – more on that later.

I was pumped about the contest, and had a good surge of productivity right at the beginning. In short order, a basic game was up and running with a level and enemies roaming around. Collision detection was a bit of a snag; I didn’t have a working collision system I could drop in from a previous game, and I wanted to solve the problem in a better way than I had in the past, so I spent a lot of precious time implementing a sophisticated collision system from scratch. It wasn’t until around the halfway point of the contest when I was able to finally move on from collisions and work on more interesting gameplay elements.

I managed to get sidetracked once more by my stubborn insistence on implementing gamepad support. I think it adds a lot to the game, so I don’t regret it, but it cost me quite a bit more time than I would have liked. It really wasn’t until the final month when I was able to focus entirely on gameplay. I went into full crunch mode for the final week, out of necessity – the build I posted four days before the deadline was barely a game, so I had a lot of ground to cover. The final push was hugely productive, though, and I’m very proud of the results!

What Went Right

Pre-built Framework

For the last couple of years, I’ve been working on a set of libraries based on my past game development experience. I looked at the technical problems I’d repeatedly had to solve, and coalesced them into generalized implementations with documentation and solid unit tests. This became the framework now known as Stem, which was mature enough as of uDevGames to use a base for Convergence. I was able to get the benefit of my past experience without having to copy-paste large chunks of code from old projects and rework it to fit. This freed me up from a lot of worrying about mundane technical details, so that I could focus more on writing the game itself.

Sound Effects

Audio is an easy thing to overlook in a game when you’re working by yourself and have dozens other things to worry about. To keep myself from slacking on audio, I asserted at the beginning that placeholder sounds were just as important as placeholder graphics, and made sure that every action and effect that deserved a sound effect got one as soon as it was implemented. The sounds were generated using sfxrX, which became an absolutely invaluable tool to me. It was a huge time-saver (each sound took only a minute or two to create), and it gave the game’s audio a nice retro aesthetic. The intent was to make quick placeholders in sfxr and replace them later, but the “placeholders” ended up being good enough that they became the final sounds in the game.

Enemy AI

Artificial intelligence was one of the biggest unknowns I took with me into the project. I’d done a game with basic AI before, but it was so long ago that I had almost no memory of how it was implemented. Fortunately, it went as smoothly as it possibly could have gone. There are three distinct enemy types in the game (and three “ranks” of each type with minor behavioral differences), which use line of sight, A* pathfinding, and a simple state machine to control their behavior. My first blind guess at an AI design worked perfectly well, and apart from difficulty and balancing tweaks, I barely had to change anything beyond the initial implementation.

Player Class Balance

It was a long and arduous effort to design the five player classes available in the game. At different points in development, there were as many as nine and as few as three classes I had planned on including. I wanted each one to be distinct and interesting to play, but needed to keep the game balanced – if their mechanics were too different from each other, I wouldn’t be able to use the same game levels for all classes without dramatic difficulty differences. Using different levels per class was actually the plan for a while, but I dropped it in favor of keeping the class mechanics similar enough to each other that it wasn’t a problem. The designs for the Duelist and Speedster changed the most – my original concepts were far more complex than what ended up in the game, and I’m glad I ultimately simplified them. In the end, the game difficulty was roughly the same for all classes, though the Ranger could still be considered easy mode to some degree…

Public Dev Log and Feedback

On the very first day, I created a thread on the iDevGames forum to serve as a progress log for the game. I tried to keep it updated for most of the contest, posting design notes, in-progress game builds, and planned next steps as frequently as I could. This helped me not only to get valuable feedback from players, but to generally organize my thoughts and give myself some accountability – if I’d posted that I was going to implement something, I’d better have it done by my next post! The #idevgames IRC channel was also invaluable, as I could bounce ideas off of other developers and get a quick sanity check for whatever I was doing.

What Went Wrong

Slow Start due to Depression and Rust

When I started work on Convergence, I was pretty demotivated as a game developer. The last full game I’d released was memset 0×801 in November 2006. I had a long chain of false starts and failed projects after that, and was hurting pretty badly from it. This project was a glimmer of hope, but in the back of my mind I was always worried it would be another failure to add to the pile. This put a damper on my motivation, and on a lot of days, it was hard to work up enough enthusiasm to write any code at all. It wasn’t until the last few weeks that I managed to set my worries aside and just build something awesome – if I hadn’t been in such a slump early on, much more of my time could have been spent productively making the game better.

Feature Cuts

There were a lot of major things that had to be cut from the game in order to get it done. I’d been planning to replace the basic geometric graphics with real art, but all I had time to do was to polish them up as they were and roll with it. Only two hours of total time went into writing the game’s music, and it shows. I wanted to have a much larger dungeon in the game, with many more enemies and puzzles. The most painful thing to cut, though, was the game’s story. I’d written a basic draft of the narrative I was going to use, but it came too late in the contest to be able to get it into the game in any capacity. The name “Convergence” has entirely to do with the story, and it doesn’t make any sense without it. If I’d worked the story in from the beginning instead of trying to add it late in the process, I think it would have added more to the game than any other single thing I could have done differently.

Difficulty Tuning

When you’re developing a game on your own, it’s completely impossible to judge the difficulty by playing it. I had the choice of either tuning the game so that it would be fun for me to play, or to take a blind guess and make it much easier. I chose the former. While a few hardcore players stuck with it, the vast majority were unable to complete the initial contest version of the game. I hadn’t implemented any kind of lives/continue/checkpoint system, so death sent you back to the very beginning. It wasn’t an obvious problem when I was playtesting it myself, but became quite apparent once voting opened. I made a quick fix that restarted from the beginning of the current room on player death, and released it as version 1.1.0. I had mixed feelings about this change, since giving an infinite number of attempts in each room removed a large portion of the game’s difficulty, but I’m still not sure what would have been a better solution.

Last-minute Level Design

Among the mountain of things I had to get done in the final days of the contest was building levels. It kept getting pushed back until it was the very last thing on my to-do list on the final day. All things considered, I think the dungeon turned out pretty well, but it was nerve-wracking to have to release the game with completely untested levels in it. This was largely the reason I didn’t notice the death-sends-you-back-to-the-beginning problem mentioned above – until the final levels were built, the game was so short that restarting was hardly a setback at all!

Things I Learned

Placeholders have a habit of sticking around. If you don’t start on important parts of the game early enough, they won’t make the cut. The game’s graphics and lack of story are a result of poor prioritization on my part.

That said, gameplay can shine through any presentation layer as long as players give it a chance. One of my sources of inspiration was Dragondot, which has fantastic gameplay with a basic graphical style very similar to what ended up in Convergence. Gameplay was the only voting category in uDevGames that I was seriously competing to win, and it seems it wasn’t hurt too badly by letting other aspects of the game fall to the side.

Feedback at all stages of development is tremendously helpful. The earlier and more often you can show people your game, the better. There’s a fine art to interpreting feedback, though – most of the time, what players will tell you can’t be taken at face value, and you have to figure out what they’re really getting at in order to fix it. Sometimes it pays to stick to your guns even if everyone tells you to change something. Sometimes great suggestions can come from people who say they hate your game and insult you for it. Sometimes a major flaw in your game will be invisible to you, and you need another person to point it out. It pays to listen to your players, as long as you know how to listen.

Closing Thoughts

While I wasn’t always sure my game would be any good (this graph is highly accurate), I’m extremely pleased with the final result. Winning first place in gameplay is a great honor. I had never placed at all in any previous uDevGames contest, so the win felt like a great triumph, showing me that I’ve finally leveled up as game developer. Right now, one of my highest aspirations in life is to create a game good enough to win something in the Independent Games Festival, and I feel like this brings me a big step closer to that goal. I’d like to extend huge thanks to all of the people at iDevGames who made this contest possible, and to everyone who played my game and believed in me. You guys rock!

Dev tools	BBEdit, GNU make, svn, GIMP, sfxrX, Amadeus Pro, Reason, Inkscape
Language	C
Lines of code	16828
APIs	Stem, OpenGL, OpenAL
Platforms	Mac OS X, Windows, Linux
File formats	JSON, PNG, Ogg Vorbis, SVG
Hours of sleep lost	Too many to count