Tuesday, February 15, 2011

Programming Post-Mortem

Writing this took a bit longer than expected. Probably something to do with the sudden trip to Hamburg. Fortunately I still remember most of the stuff pretty well. As with the design, this considers only the Global Game Jam part of the work.

Because it was my first game jam, I wanted to work with stuff I'm familiar with. XNA was my tool of choice (in retrospect, not a very good choice but more about that later) and I teamed up with Teemu because we both wanted to work with XNA and at that time no one else did. Of course it turned out we had four teams working with XNA in the end. Anyway, when we were still brainstorming game concepts I already kept in mind what I knew I was able to do. Inside my own head I discarded any ideas I was not sure how to do. I did this because I wanted zero implementation risks for our team and, again in retrospect, I think that was a good decision.

Hamsters and Plague is a grid-based game. I hadn't done a grid on XNA, but I had done one with PyGame earlier. We divided our programming tasks at the beginning to control logic (grid and user input) and game logic (hamster aging, copulation and plague spreading). Before actually doing much, I did my usual code planning: deciding which classes we will have and what their function will be. This was quite helpful, as it allowed us to work on different files most of the times, avoiding editing conflicts. Since I was more familiar with the grid stuff, I decided to take care of that.

For the record, my optimistic estimation for our implementation time (first playable version) was around four hours. We definitely took longer than that but we did have a playable game Saturday afternoon, and I think we were the first group to have that at our site. So yeah, when the instructions say 'scope for four hours production, because you will take longer than you think' they are right. We didn't use any kind of version control, which was not such a great decision as we basically had to discard Teemu's work from Friday evening because I decided to redesign much of the code on Saturday morning. Let it be noted though that I'm not fluent with version control systems, so using them might've added overhead.

Actually there weren't many problems with implementation of the game. Grid, controls, logic - it all came together in straightforward fashion. No mystery bugs. No banging head against the wall for many hours. I wish application development at my job always went as smoothly. I guess the biggest problem was that we wasted some time when there was not enough for both programmers to do. In the end this was good though as it gave me at least some time to focus on level design, although clearly not enough.

Although we had our working prototype quite early, we were still programming to the last minute. The 'trivial' stuff like screen overlays and such take surprisingly long time to implement, especially when it's the first time you actually care enough to polish the game properly. One bug that seriously affected the gameplay was left in the code - at one point it was intended behavior but when we changed the rules a bit, it made the game too easy. I fixed it later, by removing one line of code...

So the take-away:
- When unsure, especially if it's your first jam, it's best to design a game you already know how to implement.
- Scope for four hours or less (in a 48 hour jam). Estimates without experience are really optimistic.
- In a project with multiple programmers, use version control or very careful code design to keep everyone working.

No comments:

Post a Comment