Subby and the Fishes: Postmortem

So how did the development "Subby and the Fishes" go. My goal was to write a simple applet game that could be sold to advertising based sites. Lets review 10 things that went right and 10 things that went wrong on the development.

The Good:

1. Starting with a small project.
2. Choosing Java2D over 3D.
3. Rewriting to make code more elegant
4. Having other people play it.

The Bad:

1. Estimate to completion was completely off.
2. No refined sprite class.
3. No refined sprite manager class.
4. Display class was not abstracted

The Good in detail:


1. Starting with a small project.


Starting with a small project is just about the best thing a programmer can do. We all want to make an even better World of Warcraft but this isn't the way to go. First progress is immediate. It is quite motivating to see the game become better and better by the hour. I found the how to write an RPG in 40 hours quite inspiring.

Second, it is much easier to rewrite your code. If you did something wrong with the structure, you only need to refactor a few classes versus thirty or more. I think rewriting for elegance is key. With a big project, there is just no time to rewrite with huge pieces of code. My first rewrite and reorg took almost 8 hours on a very simple game. I hate to think how much it would have taken on a larger one.

Third, feature creep is limited. For example, my sprite class resizes, animates, and alpha blends. It does not flip, rotate, or force pixel colors. At some point I will want to add these features but they are not needed for this game. Each would probably take me hours to complete if I implemented properly with speed tests.

Fourth, there is little to no artwork delay. Art takes a long time to make and can be expensive. It can be quite quickly developed. In my case, my wife, Miho, can knock out most of the sprites in a weekend.

2. Choosing Java2D over 3D.

This could probably be retitled to "Go with what you know." In my case, I've spent a month playing with Java2D. It is familiar, and there are a ton of excellent tutorials on the subject. JOGL looks extremely attractive and will probably be the only way to go in the long run for developing desktop applications. However when I sat down to try to learn it, I found myself wasting valuable time. It was going to take me a month to become quite comfortable at least.

I also felt like I had more important things to learn like object orientated structures, sound, map management, user input. Kevin Glass has a nice tutorial that abstracts the display of the game from the game itself. Flip a switch and run JOGL, Java2D or LWGL. I'm still deciding if I should go this far perhaps as a final rewrite.

3. Rewriting to make code more elegant

I can't say enough about this. Since it is a small game, there is time to go back and make it right. For me, my first rewrite was to make reusable sprite and sprite manager classes. Maybe this is just good object oriented design but it was a first for me and I love the way it turned out. I can now add sprites in a matter of minutes. My code is much easier to read.

A spin off of the sprite class was to create a resource manager for the art work. It was simple hash map that loads everything into memory. But it sets up my sprite manager for timely reads so I don't have to wait for hard drive loading. It also sets things up for later if I ever need to manage video or PC memory with a large game.


4. Having other people play it.

Feedback is invaluable, no matter how hard it is to listen. About 10 people played it on JGO, finding bugs and making excellent suggestions with regards to speed and difficulty. What was also quite important was that I was able to pare down my TODO list just to get in what players wanted.



The Bad in detail:


1. Estimate to completion was completely off.


My original estimate was one week. Total time was four weeks, working part-time, nights and weekends. Rewriting the code to make in organized well took a week and half alone but improved my programming skills. The sound was a bit of a nightmare. I originally tried to add some music but the EasyOgg and another free library have major bugs in them, making them scratchy and bugging on different operating systems.

Here is the list of things that took longer than I thought.

Rewriting the code 1.5 weeks
Reorganizing the code 2 hours.
Sound and music 1 week, OGG never worked.
Compiling for Java 1.5 1 hour
Art mistakes 2 hours

2. No refined sprite class.

I spent the most time working out a nice sprite class. This took a long time to get it perfect. The nice thing though is that is completely reusable. I loved the fact I can add sprites in minutes.

3. No refined sprite manager class.


The overall structure of the code could still probably be improved. There are controllers and actors. Then there is a controller for the controllers. The first time going through this makes it a little confusing as to what controls what.

4. Display class was not abstracted

This is more of an I wish I would have thing. I wish that my display class was setup perfectly for a JOGL or LWJGL conversion. I'm very curious to see how much more speed I would have with these in place. 33 FPS cap just doesn't seem that good. However, no one that played it really went lower.