Battlemaster “Post Mortem”

by Tom Vogt <>


As far as post-mortem articles go, this one does not really qualify. For one, it is neither “post”, nor “mortem”.

BattleMaster is a game that has been in development for over eight years now, and most of that development has happened while the game was public – people have been playing it while it changes all the time. It has been declared a “permanent beta”, and evolves continually. There are no “versions” or “releases”, but continuous updates. I will focus on the pros and cons of this style of development.

Development Style

What does “permanent beta” mean, in more detail, and how did I decide on it?

The second question is easier to answer: I didn’t. It happened. When BattleMaster was first released, it was intended as a small add-on to another game of mine. It was very simple and outright primitive. It proved hugely popular, quickly passed the original game that had spawned it, and I could not help but start to expand it. Today, the BattleMaster code is roughly 45,000 lines of code.

What “permanent beta” means is that there is no version number or fixed release cycle. Whenever a new feature is ready, or a bug is fixed, the updated code is uploaded to the game. This sometimes happens several times a week. It also means that many features are available in the game while they are still incomplete, and players can test those changes early on, provide feedback, and often influence the ongoing development.


The advantages of developing the game while it is being played are considerable. The primary advantage is that for an amateur like me, it would not have been possible to come up with a game as complex as BattleMaster in a different way. When you are coding for fun, not money, you don’t want to code for two, three or eight years before you release the game.

Early feedback from players also prevents dead ends, places where you move into one direction and then find out it all sucks. That still happens, but the player feedback usually stops it before too much time has been invested into a feature that only sounds good on paper.

Another advantage is that the development cycle is very short. For simple features, players can see an idea of theirs in the game within days of suggesting it. This keeps players “in the loop” and encourages them to actively contribute ideas and suggestions.


There are also some considerable disadvantages to this “permanent beta” method.

The main problem I see in the game today is that there are a lot of game features that were never properly finished. I either abandoned them or other things came up that were more important. These beginnings of a new, never-finished feature often remain in the code, and while they usually do no harm, they make future changes more difficult.

Not having specific releases also hurt teamwork within the developers and makes bug hunting more difficult.

You also alienate players that do not like the game changing around them. On the other hand, there are many players who enjoy exactly that, so it kind of balances out. I list it under disadvantages because new players more often fall into the first category, as it makes it more difficult to learn the game. This limits the growth of your game.

Another huge problem is that I have broken the game quite often. Often, that is just painful, with a backup having to be used to restore the game state. At times, you do irreparable damage. That’s when you wish you had your own QA department.

What Would I Do Differently?

When you’ve done a project of this size, you have to ask yourself if you would do it the same way again. If the answer is “yes”, you’ve learnt nothing and wasted your time. There are quite a few things I would do differently if I were to write another BattleMaster today:

One is the use of an MVC framework. As BattleMaster is written in PHP, I’d pick CodeIgniter, which I’ve been using for other projects, but the exact choice is not as vital as the decision itself. BattleMaster is coded in 2001 PHP, and freely mixes input handling, game mechanics and output. It’s also chock full of direct database queries right in the pages. While over the years I’ve separated out often-used queries into a library of game-mechanics functions, today I would make sure that any and all database queries are encapsulated somehow. Of course, back in 2001 there simply were no frameworks around that would have done the job.

The second thing that I recommend to anyone starting a new game today is to use as many globally unique identifiers as possible. In BattleMaster, game worlds are separated with each having its own database. ID numbers are unique on that database, but not globally. When the game was started, there was only one game world, and no plans for more, so everything was coded for one game world. Later expansions added more game worlds, by simply changing the database to access. But then players wanted to move characters between game worlds and that’s when fun starts. Also, identifying anything within the game always requires the combination of world and local ID.

The third thing on my mind is that I should have started using revision control (Subversion in my case), regular automated backups and a bugtracker much earlier. During the early days, I worked without these tools, and it did hurt me enough to finally start using them. Nowadays, when I start any software project, one of the first things I do is setting up a Subversion repository and if the project isn’t for purely personal use, I also set up a copy of Trac to cover the “bugtracker and more” part. And as soon as a project goes live, I set up a cronjob to at least do a daily database dump.

There are also a few things where I’m not sure if I would do them differently, but which caused me pains at one time or the other.

One is that I learnt just how much you make yourself tied to a specific database if you don’t work hard on avoiding that from the start. Even though I had a database abstraction layer very early on, it was a few years later that I realised that wrapping mysql_query() into a generic db_query() function isn’t enough. I tried switching to PostgreSQL once and found out that it uses serials instead of auto_increment, for example. The amount of changes that difference alone would have required was surprisingly large.


In summary, it has been an interesting trip, and a huge learning experience. It has done a lot for my coding skills, and the ability to test new ideas out quickly is very rewarding. There’s things I would not repeat, and like any hobby there are times when things suck.

One big thing that I learnt is that building things in small steps is a great approach to developing a game. Sometimes, my own enthusiasm gets the better of me, but most of the best features of BattleMaster started small and where gradually improved upon.

For a hobby project, I can recommend not being afraid of changing things “in flight”. It does keep the game fresh both for you and the players, and if you take steps to minimise the effect of bugs, it can be an overall positive experience. It also brings you and your player community closer together, and that is one of the most important things you can do for both of you.

Wish there was more?

I'm considering writing an ebook - click here.


Hobby game developer

Tags: ,

Thursday, January 29th, 2009 postmortem
  • Clel Perez

    what has recently happened to BM?! What is this trademark dispute about, and how long will it last?

  • Ethan Lee Vita

    As an additional note, I believe the game is 8 years old now.

  • anonymous

    I don't have official numbers, but:

    There are just under 1400 registered users
    with 900-1000 users logging in daily
    for an average ranging from about 1050 to 1100 for users logged in in the past 3 days

  • Ethan Lee Vita

    I've been playing the game since about august 2005 with a small break in 07. It's one of the few games that has kept me involved and mostly for how its primary focus is on player-interactions and politics.

    There are about 1400 registered accounts with about 1,000 logging in on average. There's almost 28k total accounts registered. I suspect many are deleted due to multi-cheating, realization of it being text-based, and auto-deletions of those who took a break and returned.

  • anon

    How many active users are currently playing? Just curious what 5 years of work has yielded in terms of turn out.

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