Owl Tower Quest Postmortem
It’s now Wednesday, and I finished my game Sunday evening. I’ve had a few days to think about it and my experience.
What went wrong
Graphics - I didn’t have a plan for creating graphics, nor a pipeline for doing so. I ended up finding and using a for-kids drawing program, which was just as advanced as I needed, but if I had put more thought into it I could have tried to create something more original.
Preparation - I had used Java2D to do some moving of an image on a tiled background, but I stopped short of using the color key to make it transparent, (wrongly) assuming it would be trivial. I still don’t know how to do it, and I wasted about an hour trying to get Java to make the background transparent, when I discovered that if I saved it as a gif, I could make it transparent using Gimp. That was work that didn’t need to be done during the competition, and it burned me out on learning for a few hours.
Motivation - I don’t know what concrete steps I could do to improve this, but once I had a level up that mostly worked, I had very little motivation to improve it. I was concerned about getting something playable enough to enter, so when the keyboard controls were easier than I expected, and the graphics rendered fine, I was not prepared to tackle the next hardest problem, because I couldn’t see what it was. I now wish I had a project plan that prioritized tasks and had estimates of time and effort, because it didn’t seem worth it to do better graphics, or add more levels, or add more variety since it was such a relief to have gotten that far.
In that sense, I definitely could have worked more on my entry, but I ended up taking back some time that weekend for doing real life stuff. I don’t regret it, but it did make my game less finished and less fun.
Not taking hard problems seriously - I don’t know why, but I slapped in collision detection long after I put up walls and the player. This was dumb, and my solution was even dumber. I strung a bunch of if-then statements together, and instead of making sure a move was legal, I just undid it in the collision code if it turned out to be illegal. This resulted in passable, but buggy collision detection, and only got worse when I added stair cases and vertical walls separating floors and doors. It also made the player jumpy near walls, since the player was moving, possibly being drawn, then moved back when the wall was determined to be hit. I should have wrote tests for what needed to happen, and then write a sensible way of dealing with obstacle management.
What went right
A good start - I made my design quickly, and sketched out an entire level before I started coding. Then, when I started coding, I didn’t need to make design decisions that could slow me down. I had the tower up in about 10 minutes, with a moving player who couldn’t pass through walls in another 30. That was great motivation, and allowed me to incrementally improve my game, which was great for my morale.
Preparation - I used Java2D a few times before, but in the 3 weeks leading up to the competition, I made 3 separate projects with it. This really helped me understand what things were doing, rather than going the cargo cult programming route. Also, eclipse was ready, I had a basic Java WebStart XML file so I didn’t have to mess around with it, and I was loading my resources in a WebStart-friendly way. All in all, the time between my first successful build of my game and my first successful WebStart deployment was very small.
Conclusions
I have definitely learned that it is far easier to improve upon an existing product than to nitpick about design and implementation before anything actually exists. So, I am a convert to rapid prototyping.
Overall, I learned a lot about making a game, and my code is now a perfect candidate for some serious refactoring and test writing. I’m looking forward to improving my entry, and building on the idea.
Tags: postmortem