Around the end of October 2005, I decided to try to write a complete computer role-playing game in forty hours. I was inspired by this article by Jay Barnson on GameDev.net, Jeff Vogel‘s excellent work, and by my own love of RPGs. I am a professional game developer, but I’d never written an RPG engine and considered that a “hole” in my experience.
I picked a time limit because I’ve also been fascinated by people being forced to do the best they can with their skills under such limits; this was one reason why I wrote my Iron Gamedev article (the other reason was that I was feeling really goofy that day). And of course competions like the Ludum Dare also inspired me.
Now, the point of this project was to learn, not necessarily to make a complete and fun game. That said, I did want to make the game as good as it could be in the time I had. Here’s an excerpt from my original design doc with my goals:
We need four things to be able to call the project a success.
We need to create the map structure and populate it with an initial terrain layout.
We need to allow the player to walk around the map and be blocked by passability data.
We need to create monsters and have them move toward the player and attack him when they get in range.
We need to allow the player to attack back, and to have the player somehow gain in abilities when he succeeds in killing monsters.
That’s it. If we get that, we can publish it without fear of too much ridicule.
But that’s not enough. What I want is:
A map structure where every map cell is a list of critters placed on that cell. When the cell is drawn, all objects in that cell are drawn, from bottom to top. Since the terrain object will be pushed on the map on load, it will always be drawn first, on the bottom.
A map structure that contains data for map links.
An inventory and a current equipment screen.
If we get all this implemented, I will consider the experiment a resounding success.
Finally, what I’d really like is:
An overworld, three towns, two castles, and eight dungeon maps.
An overall plot, no matter how thin.
Quests and quest objects.
If we get all this implemented, I’ll be damn suprised.
Well, I didn’t get quite everything on my list done, but I’m still very surprised at how much I accomplished. I got the map structure I wanted, an inventory, buying and selling, NPCs with different AI behaviors, levelling up, one town, two castles and eight dungeons. And a very, very thin plot, but not quests or quest items.
I kept rigorous track of my time, but since I have a full-time job and a family, I wasn’t able to spend my hours over the course of a weekend or even a week or two. It took me about three months to finish the project, and I actually feel I did well completing it in that time. I am actually alloting myself four months to complete my next forty-hour project.
I would break down my time spent as follows: about five hours was spent fiddling with graphics, about thirty hours was spent writing code, and about five hours was spent creating the NPC data files and game levels.
What Went Right
Kicking it Old-School
Emulating an old Ultima-style RPG was the right tack to take. If I’d tried to write a 3D RPG, I simply would have gotten overwhelmed and probably quit. The feature set I wanted fell into the “tough but doable” range and made for a perfect forty-hour challenge.
Using the SDL
I wouldn’t have completed what I did if I had not used the SDL and instead just used DirectDraw. End of story. I cannot imagine why someone would not want to use it for a project like this, it was so easy to use and saved me so much time.
Grabbing Graphics off the Web
All the items, monsters and NPCs in the game came from this page of free RPG tiles. This was a lifesaver – if I’d had to create the graphics myself, not only would they have looked like crap, I would have burned so much time on them that I would not have had any chance of completing my goal. As it was, I could not find any decent terrain tiles that I liked, so I ended up grabbing a lot of the ones I used out of Ultima VI. This cost me at least two hours, unfortunately.
Making an Editor
I spent about five hours making an editor for the engine – you can see a screenshot of it here and it’s included with the source package linked above. I think this may have been my smartest move. I ended up spending far too much time on the code and far too little on the maps (see What Went Wrong, below), but if I hadn’t had the editor I probably wouldn’t have gotten more than one or two maps into the game.
Using my PDA to Sync Projects
I have an Asus A620 PocketPC-based PDA. I love it, and one of the things I use it for is to keep projects synched between work and home. This way I was able to work on my project at work, sync my PDA, take it home, sync it at home, and pick right up where I left off. Now that I’ve got some webspace, though, I’ll probably set up a Subversion server to make it even easier, and give me real source control features like versioning.
Blogging the Process
This was vital. The fact that I knew people were watching kept me going when I got really tired of the project 🙂 I’d like to thank my friends Ryan Clark and Tom Mauer from work who tracked the progress of the project with interest, as well as Andrew Wooldridge and Gianfranco Berardi who linked to me, and to Sol who piped up with helpful suggestions when I mentioned I was using his tutorials.
What Went Wrong
Hoo boy, where to start?
Well, first, here’s a screenshot of the most visually interesting bug I encountered during development:
Multiple Mistakes with the Editor
I made two huge mistakes with the editor. First off, I made it too early in the project. I made the editor when I felt I needed map data to work on, but once I had the map I then added lots of features to the map structure…which the editor then didn’t support. I had to add the map level number, map name and map links all by hand. The editor still saved me time, but it could have been even better if I’d just made a temp map by hand to work on, finalized my map data structure, and then made the editor.
My second mistake was a doozy. I split the editor off into its own project, instead of simply creating a new editor source file in the base project. By splitting the editor off, I ensured that all maps would have to be moved from the editor folder to the actual game folder before they could be tested – and then moved back if additional work was needed. Maps quickly got out of date and filenames got confused. I finally fixed this by putting a hardcoded path into the editor source so that it saved and loaded from the game folder, a terribly hacky solution.
Secondly, I ensured that all the changes to the source files I made while writing the editor had to be merged back over to the game project, and then changes made there had to be merged back into the editor…it was just bad. Still much better than no editor at all, but these mistakes caused me to eat up time that could have been spent making the maps better. Which leads me to…
Too Much Time on Infrastructure, Not Enough on Content
Now…this is a thing that went wrong, but in the end, this was a learning exercise, not an attempt to make a publishable game. I wanted the game to be as good as it could be, but in the end the quality of the game is not that important.
That said, the game could have been twice as good with just one or two more hours spent on the content – and I’d have had those hours if I’d both planned better and not made those boneheaded mistakes with the editor. There are features in the engine that the player will never see…because I didn’t have time to write content that uses them. Yay!
Schizophrenic Source Code
I almost didn’t want to post the source…in just about every case, I started doing things the “right” OOP-ish way, and then reverted to procedural programming when time got tight.
For instance, there is an NPC class. Great! Do I subclass from that for all my NPC types so that I can program in individual unique NPC actions? Nope, I simply use that one class and have the Update() function determine the NPC’s type and perform actions based on a classically bad switch/case statement. The input code is atrocious; I’m doing tons of stuff there that have nothing to do with input. I felt like crying when I put the code to draw the hit marker and projectile marker inside the input function with their own frame pumps…but it was either do that or cut them completely. I guess I can console myself with at least knowing that it was bad.
Despite all of that, I do consider the project a success. I learned a lot and created a fair amount of code that can and will be reused for other projects. And I’m planning on doing three more of these forty-hour learning exercises over the course of the next year.