(Note: This post-mortem is slightly old, as it was taken from a different blog of mine that most people never knew existed).

The Duelist is nearly complete. All that’s left is some AI programming, sound implementation, and the addition of a little bit of content. I should be doing all of that right now since the deadline is in about 24 hours. However, I’ve decided to take a small break to write a summary of my experiences while creating the game.

The Evolution of the Idea
The original concept for The Duelist was embarrassingly simple. It consisted of a Simon-like game where two players would go back and forth hitting a constantly growing series of steps until a player messed up. You might recognize this as the Mind Hack duel technique that went into the final design.

I quickly realized that the idea was too shallow. It might be fun for five or ten minutes, but more was needed. Thinking of more was a struggle. It hit me in the shower sometime. Why not make a bunch of simple little games where players could face off against each other?
With the right dynamic, this could be a lot of fun. At the very least, you could trash talk with your friends.

The minigame ideas came relatively quickly. I wanted them to be simple, fast, and fun. I wanted the players to constantly be moving (so long as that was possible), and I wanted things to be varied enough that things didn’t stagnate too quickly. However, I also wanted things to be simple - no complicated art, little complicated programming. With these requirements in mind, it wasn’t long before I had my original set of 6 games.

And then I hit a snag. Again, the idea seemed a little bit too shallow. Just multiplayer? Just a minigame at a time? No, I wasn’t happy with any of that. So I started slamming my head against the ceiling (a difficult task considering the height of our ceiling) trying to think of more to add.

In parallel to doing all of this, I was working my way through Revolutionary Girl Utena - an anime where a high school student has duels with her peers for, well, the reason isn’t important (and it’s awfully weird and ruins the street cred I have built up). Further, I was thinking a lot about telekinesis. I had also watched Volcano High a few weeks prior, where school students fight each other with super powers.

And - again, in the shower (I spend a lot of time in there) - I came up with my idea. The player would be a student attending a university where the only way to graduate would be to beat everyone in telekinetic duels. The duels would be setup in multiple turns, where each turn would be a minigame (or, to follow our theme, would be a battle in a certain telekinetic technique). Players win by winning three more duels than their opponents have won. That is to say, it’s not a ‘best out of 5′ system where one player can just barely win; you have to clearly come out on top to be proven the victor. Thus, there can be a bit of a struggle to come out on top. To top that off, when the player isn’t dueling, he can go around the university and talk to the students.

I had my idea, and I was happy with it. Now to submit it and hope.

Course of Development
The first week went slow. I spent most of my time waiting for the DDR pad to arrive. I could have easily setup a temporary solution wherein I use keyboard keys for input. But I didn’t. I was stubborn and wanted to wait, and thus I burned a lot of time here. In lieu of programming actual content, I built up my framework and made sure everything was bug-free.

The second week went somewhat better. Realizing that the pad may come the very last day, I decided it would be best if I went ahead and implemented the temporary solution. In retrospect, this was a great idea - not only did it make testing much easier, but it was easily convertible when the pad arrived (in fact, when I did finally get my pad, I just mapped the pad buttons to keyboard keys and kept the same code in place). I got a quick proof-of-concept minigame working and setup the infrastructure that would allow easy university navigation. I also came to one very grim realization.

I’m not an artist. My friends know this. Anyone who’s ever visited any of my sites know this. I knew this, but I ignored it. The game required art - a pretty sizeable amount. I bought a sketch book prior to being accepted and started practicing the craft more heavily. But when it finally came to content generation, I knew I wasn’t going to cut it - my drawings looked bad and took too long to produce. A compromise needed to be made.

The compromise was actually pretty straight-forward. My game takes place in a university. Why not take pictures of actual people, apply some fancy image filters, and let those be the graphics? That just leaves me with some simple GUI stuff and the buildings, which I could create easily enough using Google Sketchup.

The third week is when everything came together and I kicked myself into high gear. I got the code functionally complete - it was missing some of the bells & whistles I would’ve liked, but it was a recognizable game. I got pictures of my friends and doctored them for in-game use, and I made the scenery that the game would take place in. My time was being juggled between content generation and intense coding, and surprisingly everything was going relatively smoothly.

Strangely enough, most of the game came together in the last few days. There was a lot there before that, but it wasn’t recognizable as a cohesive whole; there were just a series of fragmented pieces waiting to be glued together. It took a lot of work and a few late nights, but I was able to get most everything together.

When it was finally over, I had actually done pretty well. I did have to cut one of my listed features (multiplayer using only 1 pad) because I failed to make my code in such a way that it would be as easy to implement as I had hoped. But I was also able to add one extra minigame and get things looking pretty good.

What Went Right
The Framework
I’m happy with my framework. I’ve got this great process manager that helps me write some very modular, very robust code that’s easy to modify and tweak as I go. I’ve also got a nice event passing mechanism. With these systems in place, I was able to quickly see the results of my development, and I was able to quickly track down and edit bugs. I won’t say it’s the greatest system around, but for small games, it’s definitely handy.

The People
I was a bit hesitant to ask people if they’d want their picture in the game. In the end, most everyone seemed excited about it. I’m really glad they helped out - the game wouldn’t look anywhere near as decent without them.

Memory Management
I remember a time before I coded a Smart Pointer class, and I remember how many memory leaks and problems this caused. Even with it there, things weren’t flawless. I’m to the point where I just don’t enjoy wrestling pointers anymore. Truth be told, the XNA Framework came out mid-development, and I was tempted to port everything over to it just to get that automatic memory management.

The Concept
I like my game idea. I think there was a lot of potential for fun there (even more than I managed to bring out), and the general simplicity really helped to move things along. I could see results fast, and I never really got bogged down in my code.

Data-Driven Development
I setup my game in such a way where I could drop in a few text files and immediately see changes to the course of the game. This is essential. There’s nothing worse than having to go in and change your code every time you want to see something change in your game. Having the ability to edit a few files and immediately see the changes makes things go orders of magnitude faster, and it feels a whole lot easier.

What Went Wrong
Time Management
I could’ve spent my first week a lot better, and even that second week could’ve been more productive. This lead to me feeling pretty rushed near the end, which is both good and bad - good because I got a lot done and my mind was in the constant ‘game development mindset’, but bad because I had a few really late nights.

Feature Creep
I’m not talking about ‘feature creep’ in the sense that I kept thinking of features I wanted to add. I’m talking about feature creep in the sense that I kept thinking of features I needed to add that I hadn’t really accounted for. Player feedback was the biggest one. A few of the minigames are noticeably missing in messages to the players - you just see who wins/loses, and you might not be entirely apparent why. If I had a little more time, this would’ve been fixed, but other features took priority.

Cut/Unimplemented Features
I got really disappointed when I realized that I would have to cut out the 1 pad multiplayer, since it was one of the better features my game advertised. The game also could’ve used some more user-friendly features, like a configuration screen or even a credits screen. In the end, though, this again came down to the time factor - I had to decide what I could implement that gave me the most for the least amount of work.

What I Learned
I’m Not a Professional Game Developer
I’m not bagging myself or being self-deprecating here. There is one fundamental difference (aside from experience) that separates me from a professional: time. A professional is paid to work at least (hah) 8 hours a day 5 days a week. I’m a college student working on a Master’s in CS. I can’t work that much on a game. It just isn’t possible for me to hold down school, do my job, and keep the kind of game development schedule I’d like. So in the end, I have to make compromises on how much time I can spend developing and how much sleep I can bare to lose.
As an aside, I lost a good deal of sleep trying to get this game finished on time.

Event Passing Rules
This post-mortem has been relatively non-technical thus far, but allow me to say this: communicating between modules via event passing is a really, really nice. It often allows you to drop modules in or take modules out without anything breaking or needing modified. It should be a serious consideration for anyone developing a game of any size.

Fighting Distractions is Hard
If your job isn’t game development, you’re always making compromises. But sometimes, the game development has to come first. And that is when everything else seems to call for your attention. There’s no easy way to get around that - sometimes you just have to tell your friend to shove off or push that school paper aside for a few hours.

What I Knew and was Happy I Used
Code Reuse is Your Friend
I can’t stress this enough - make your code reusable. Break things into functions and modules. If you find yourself repeating something over and over, it’s time to refactor. I had a great infrastructure to support this, and it saved me a whole lot of time.

Data is Your Friend
This goes hand-in-hand with my section on data-driven development. Make your game as modifiable outside of the game code as humanly possible. Scripting is good. Specifying object data with data files is excellent. You’ll be able to swap these in and out quickly, and your game development will move so much faster. Also, if you want to add the ability to modify your game later, it’s a whole lot easier.

What I Knew and Shoul’ve Used
Get the Right Set of Tools, and if They Aren’t Around, Make Them
Often I’d find myself waist deep in text files trying to make sense of some numbers I used that would break when in some place but would work perfectly other places. This could’ve been easily alleviated by slapping together a quick tool. .NET makes creating a lot of tools trivial.

Conclusions
There’s a whole lot more to say about The Duelist and game development in general, but it is not for this post-mortem. In general, I’m happy with the course the development took - I wish I could’ve used some of my time more effectively, but overall I’m happy with the outcomes.
Now, it’s time for me to go put the finishing touches on this.

Are you asking for a challenge?