Post Mortem

Post Mortem for Robombs

As a great fan of game post mortems, i decided to write one for Robombs. Maybe it’s useful for somebody or at least an interesting read.

The game

Robombs is a multiplayer focused action/arcade game inspired by Bomberman/Dynablaster. The following text provides some insight into its goals and the usual “what went right/what went wrong” lists.
Robombs isn’t a commercial project and wasn’t planed as one. Nobody forced me to write it and nobody could have blamed me if i would have failed in doing so. So there was no external pressure applied, which eases things a lot. However, i really wanted to write a new game. The former one has been finished two years before i started Robombs and i haven’t written much game related code in between. I really felt the urge to do something new in that area, especially because i had to withdraw the former game due to legal reasons.

General conditions

Around March 2007, i started to write some abstract network code with a simple fps game on top of it as a proof of concept. I already had decided to write a network based game, but i was undecided about the game itself. Because my first child was “scheduled” for december that year and i expected to have less spare time afterwards, i decided to write the network code while i still had the time. I finished the network code and the example game in July 2007. Armed with working network code, i felt that it should be possible to write a new game while still taking care of the family. The actual game development started around late March 2008.

Decisions…

At first, i wanted to create a much more complex multiplayer game than Robombs actually turned out to be. The basic ideas (3d levels based on a 2d grid, maze-like levels, players running around trying to kill each other,…) were identical, but i had plans for collectable item parts, different player characters with different capabilities, “home zones” where no other player could enter and a kind of item factory in that home zone, where the player could create new weapons and items out of the parts that he collected in the level. Something like Feud from Codemasters on the CBM64, just not with magic but with mechanics. That’s the reason why the example game for the network code is being called Feud. However, i decided that this was way too much to accomplish given the available time and resources. So i reduced it to the core components and realized that i got something that was very similar to Bomberman.

What went right

1. Writing the network code beforehand and building a sample game with it

That was a good idea and it saved me a lot of time in a phase where i had less time available. It turned out that only a few things had to be changed to adapt the code to Robombs, so i could concentrate on the game itself and treat the network part as something that “just works”.

2. Reducing the initially planed game play to the bare minimum

Given the time constraints, this was a wise decision. I was able to finish the game in a reasonable time frame that way, plus i had to use less resources for artwork and 3d models.

3. Using external resources were possible

I’m not a friend of including a large number of third party libraries and source code into my projects, because i want them to be simple, small and independent. However, i decided to use some code from the jPCT community for font rendering and sound and i was very happy with the results. Both are running very stable and i would recommend them to anyone. Thanks to r.a.f.t and Paulscode for this.
For the 3D model of the players, i asked Reed Hawker for permission to use this Quake2 invader model that i had used in an applet game a few years before. The model is just right for a game like Robombs. It fits very well into the look and feel of the rest of the game and i can only thank Reed again for his permission to use the model. The same goes for the crate animations that were done by fireside from the jPCT community. Thank you all guys. Without your help, the game wouldn’t be finished yet.

4. Naming

This isn’t as unimportant as it sounds. First of all, you have to ensure to use a name that isn’t protected by some other company’s rights…been there, done that. Second, a unique name is better for being found on the internet. If you call your game “Super Bomb”, many entries will pop up in search engines that aren’t related to your game. If you call it “Soooba Boumba”, this isn’t the case but nobody can remember such a name. Robombs is quite a good compromise. Before i released the game, only a few results popped up for “Robombs” on google, all refering to a short form of “Robot bombs”, which was another name for the german rockets V1 and V2 in WW2. The name “Robombs” has the same origin btw, because at first, i thought about reusing some robot models that i already own for the players. I dropped this idea later, but i kept the name.

5. Distribution

Apart from some Java related sites with lower traffic, i submitted the game to one website only: To http://www.happypenguin.org
From there, someone posted it on softpedia and on softonic and especially the latter caused it to appear on a lot of other websites. With a minimal effort, i got maximum response. I guess, i was just lucky this time, but anyway…

6. Getting things done in a reasonable time frame

It took me around 6 months (on and off) to write the game. That’s ok and it’s exactly the time frame that i had in mind when starting with the project. Of course one could have done it in maybe three weeks, but my spare time was limited and sometimes you just don’t want to work on the game, so 6 months were just fine to me.

What went wrong

1. The bots

There are bots and they do something. However, they are quite dumb. I simply haven’t had the time nor the motivation to improve them any further before releasing the game. One major mistake was to build the first iteration of the bots’ AI based on a test level that didn’t represent an actual game level. The bots worked fine in that level, but when dropped into the much more narrow build levels that i planed to add to the game, but just plain sucked. You couldn’t even call them stupid without overestimating them…they simply did nothing at all. They didn’t even blew themselves up…not even that. So i dropped all the bot related code and started from scratch. If i would have noticed this earlier, i could have spent the time in improving the bot AI instead.
However, i’m still working on them from time to time, so the current situation is about to be improved in the future.

2. The network traffic

I simply underestimated the traffic that the website and the downloads would cause. I’ve purchased some web space which includes 100GB of traffic/month. I thought that this would be more than enough….i was wrong. It isn’t that bad, but it will cause the costs for hosting the game to raise in the future. If i would have known this before, i may had located the downloads somewhere else, but it’s almost impossible to change this now, because most downloads come from direct links to the file. I can’t move it anymore without breaking all the download links, which is something that i don’t want to do.

3. Internet play

Albeit i’ve claimed that internet play is untested and “at your own risk” from day one, i should have tested it at least once. There was a bug in the initial version (0.99) that caused the objects to disappear if the data transfer took longer than rendering a frame. This never happens on a LAN but it will happen on the internet. If tested once, i would have noticed this…

4. Shadows

I tried to test the game on as many cards as possible to make the shadows look good on all of them. After realising that they still sucked on some ATI based cards, i bought myself a card of that range and finally fixed the shadows. This is not something that really went wrong, but i underestimated the difference from one chip generation to another. That it looks fine on generation 2 and 4 doesn’t mean that it does on generation 3…


Final words

I had great fun writing this game. I hope you have some fun playing it!