Post-Mortem: Robot Warz

Well, technically, the name was changed to Mecha Warz, but to prevent confusion with Mecha Asylum, I’m going to use the original name. There is a bit of history with this game, so I’ll start with how I came to work on this project and then go on to the postmortem.

When I joined the project, it was already in development with three to four developers. I recovered from a period of depression and wanted to start development on a PBBG. I contacted the person I worked with 6 months prior after the second iteration of Mecha Asylum was a failed attempt. I wanted to get to work on a project that was complete and had active players.

What Went Right

  1. Group project.Well, there were multiple developers working on the project, but that was a WTF? in and of itself. There wasn’t any version control, so there were some interesting instances of overwriting another’s work.

    It was an accomplishment to go from one developer working on a project to four and I still do think that is what I liked most about the project. It would have been better if all of us were intermediate to advanced level developers and used version control. I’ve rectified the situation in the present to prevent the failures from occurring again.

  2. Active player base.I enjoyed entering the development with an active player base. It helped with the motivation to add and fix features for them to play. I think it speaks a lot that people will play any game or give any game a try, just to waste a little time. It gives me hope that at least someone will play my game, if it at least functions.

What Went Wrong

In the case of Robot Warz, we were developing portions of the game live, so a player could, if they knew where to look play the parts that were being worked on. It also meant that some portions of the game could suddenly stop working, when a missing semi-colon or another bug was inevitability was introduced.

  1. Administrators and developers played the game also.The game playability must protect the boundary of fairness, whether real or perceived. In the case of this instance, it is a gray area, because the administrators didn’t cheat. However, they could have and to the player it means nothing if the administrator could easily with a click of the button give themselves more money than any player in the game.

    After thinking about it a great deal, if you are going to develop the game, then the other players shouldn’t know that you are an administrator and if you are, then you shouldn’t have access to play the game. Administrators, if they want to play the game, should have another account to do so with the same access as the rest of the players.

    Ethically, an administrator probably shouldn’t play the game at all and should be completely separated from the playability to be as neutral as possible. If an administrator crosses that line, then feelings might be hurt when a decision was made against another player, because of an in-game alliance. Whether or not the administrator made the decision based on that is irrelevant to the player and would cause to destroy the fun factor of the game.

  2. There wasn’t any version control.I remember implementing a feature and bug fix four times, because every time the file was overwritten by another developer who didn’t download the file from the server. It was only resolved, because I contacted the developer who was doing it and told him the situation. If version control was used, it wouldn’t have mattered, because his changes would have been merged with mine and resolved.
  3. Security, what security?When I joined the project, register globals was used throughout the code base. I had to inform the other developers about super globals. I also spent a great deal of time going through code and updating the code to use the correct super global. I should also mention that in all fairness, the project was based off an open source browser based game engine that had these flaws inherent in the code. It might not have been the complete fault of the developers on the project.

    Validation and sanitization was only added when an security hole was already being exploited. Therefore, it was more of a cat and mouse game of patching holes after the hacker exploited it. There were also too many areas in the code that had to be patched to prevent future attacks. I wasn’t much of an security expert, but you don’t really need to be when all validation and sanitization is programming common sense.

    It is difficult to take much from the project, but when you have your name associated with a project that has a magnitude of attack vectors, then you pretty much have to take it personally.

  4. Disjointed game features.The game features were developed separately from other developers and also separately from the original game purpose. I think I added a farming feature, because it “would be cool”, as opposed to matching the rest of the game playability. Yeah, I didn’t really get the whole game design concept and planning games at that time.

What I Learned

I learned the importance of version control and I’ve used it every since, even when I’m working by myself. It was the first time, I really seen an importance for it. Actually, I didn’t know about version control at that time, but I thought there had to better way to prevent events like when my file was replaced from happening without having to create a copy to ensure a backup was saved. I’ll learn the name Version Control and Subversion, 8 months later while working on Astrum Futura.

Security is important! The crackers that attacked the site, really expressed the importance of sanitization and validation. I’ve since practiced a great deal with making sure that I always code projects around a paradigm that includes those two. It is easier to sanitize and validate when first coding the project, then it is to react to attacks and fix security holes retroactively.

I’ve also learned that games tend to play better, when they’ve been planned and the game features flow together. When you add features, because they are cool and not to complement or extend the current game base, then you create a patchwork game that ends up confusing the player. For example, if you are going to add a pet, then make sure it isn’t for a robot game.

Wish there was more?

I'm considering writing an ebook - click here.



Tuesday, January 27th, 2009 postmortem
blog comments powered by Disqus


Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.


Got Something to Say?

Send an e-mail to, or get in touch through Twitter at