Aftermath: The Post-Mortem

Interestingly enough, the lessons I "learned" from working on a game with such impossible constraints are very applicable to the development of any game, on any budget and schedule. A lot of the lessons Hackenslash taught me weren't completely new to me – but these sorts of things often bear repeating.

Without further ado, here are the Top Ten Lessons Hackenslash taught me:

Lesson 10: Doing something like this really was worthwhile

I didn't think I'd have time to do something like this when I first found myself challenged. But now that it's done, I found it not only taught me a few things, but it increased my enthusiasm for continuing work on the project I put on hold for this. You wouldn't think that working on Yet Another Game would feel like a vacation, but it did. And after all, I didn't lose that much time – only forty hours. This was a fun experience – one I'd be happy to repeat again in the future.

Lesson 9: Cutting features isn't always free

Some of the last-minute changes to Hackenslash really blew the game balance out of whack. The inability of monsters to cast spells, and the lack of need to for the player to 'conserve resources' as he pushes deeper into the dungeon trivialized some of the challenge to the game. If those features were going to stay 'gone,' the game needed another design pass to re-balance it and improve the modified gameplay. In other words, cutting features introduced an additional cost to the development of the game. This made me wonder how many retail games were released in a terrible state because the development team didn't have time to re-visit the game design after features were cut to meet schedule.

Lesson 8: Do the important stuff first

I found I tended to be more productive, efficient, and make more progress on the game when I was in 'crisis mode," realizing how tight my deadline was and making a conscious decision to (usually) only work on the pieces that made the biggest difference in the game.

I think I may run through a similar exercise with all of my future projects: I'm going to try to break my development time into, say, 8-hour segments, and play a little game with myself: If I pretend that I only have those 8 hours to 'finish' the game, what could I do that would make the biggest difference in those 8 hours? I don't know if it would pay off as well at the end of the project as the beginning, but it's worth trying.

Lesson 7: Scope will expand to exceed your budget and schedule

Every programmer I've ever met tends to underestimate the time required for him or her to complete a feature. Add to that the dreaded 'feature creep,' and you can guarantee your project is going to be way over schedule. I'm not one of those guys who believed that "feature creep" is always a bad thing. I think some of the most killer features – the ones that turned games into hits – often came about as a form of "feature creep."  But new features are seldom free. You will have to make room for them in your budget – and that often means cutting other, less worthy features. This project taught me a little bit about being ruthless in cutting features. In truth – if I had the option, I should have added an extra ten hours to make the game truly "work" – but only after cutting all the fat (like doors, magic wands, etc.)

Lesson 6: Get the Game Playable as Fast As Possible

The sooner you are able to get things on screen and start playing around with it, the sooner you can revise and improve your design, weed out the things that don't work, and come up with great ideas for making the actual game better. It also helps you catch bugs (especially those ugly design bugs) earlier, which makes them much easier (cheaper) to fix. It also aids you in sorting through priorities.

Lesson 5: It's sometimes much faster to throw away old code and start over

I only ended up completely throwing away some code and starting over once in this project. While I can't know with a certainty if I really saved time by doing this, I suspect I would have been fighting the design flaws of the original method all the way to the end of the project.  On the flip side – throwing away the old rotating feature code and starting over with a better design might have saved me some trouble.

Lesson 4: Python Rules!

I can't believe how quickly many features came together using Python as opposed to, say, C++ or even Java.  Things like typeless variables, dictionaries, and extremely easy-to-declare lists (allowing a mixing and matching of object types) made it very easy to implement content lists, attribute handling, spell effects, and so forth. I was already a fan of the language, but now the prospect of using Python, tied into a high-level 3D engine, has become extremely appealing to me.

Lesson 3: Don't underestimate the art requirements

Looking up source art, drawing, tweaking, testing, and re-tweaking artwork… even little 32 x 32 bitmaps – consumed a great deal of my time – and the results weren't nearly as satisfying as what I'd have gotten if I had devoted those hours to programming.

Would an experienced artist taken less time? Undoubtably – though the difference probably wouldn't have been too extreme. Would their results have been better? Absolutely. Be careful not to trivialize the effort it takes to generate art for your game, whether you are doing it yourself or getting someone else to do it for you. It can suck up a great deal of time if you aren't careful.

Lesson 2: I need to be more efficient in my use of time.

A night where I'd devoted four hours to working on the game often ended with only two hours (or less) of actual development time taking place. Some of the time went to documenting what I was doing, but I also found myself losing focus, taking extended breaks, not immediately returning to work after a minor interruption, surfing the 'Net, playing (quick) games, or whatever. Now, taking breaks during long stretches of development is a good and healthy thing. But by recording my actual productivity, I was pretty surprised at how inefficient I was with my usage of my development time.

I'm not getting paid by the hour. Better use of my time means I can get more done AND have more 'free time' to do other things. So I'm going to be making a concentrated effort to improve my use of time when I am "on the clock."

Lesson 1: IT CAN BE DONE

While Hackenslash in its current, 40-hour incarnation is hardly a poster-child for high production values, I think it demonstrates how much can be done – on a fairly complex game – with no budget and very little time by a single developer. Given more time – and even a fairly insignificant budget – or the help of a few friends – who knows how much better it could become?

The bottom line is this: If you want to develop games, nothing is stopping you. You can find the time. You don't need a big budget or fancy tools. You don't need a team of specialists. You don't need years of training. All you need is the will to make it happen.

And that's the most important lesson of all.

About the Author

Jay Barnson has been writing computer and console games professionally and as a hobby for over twenty years, starting with his initial struggles to put graphics on the screen with the Sinclair ZX80 and Commodore 64. Past credits include Twisted Metal, Warhawk, Jet Moto, Animorphs, and Extreme Championship Wrestling. More recently, he has been developing games as a part-time independent developer for Rampant Games. His first independent game release, Void War, recently won Independent Multiplayer Game of the Year for 2004.