Oct 16, 2011—
uDevGames 2011 Entry
- 1st place Best Gameplay
- 4th place Overall
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 FrameworkStem, 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.
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.
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 Rustmemset 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.
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.
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.
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|
|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|