For most retail computer and video games, once your game gets shipped into stores, the job is done. Sure, there may be bug fixes or future downloadable content, but those require a skeleton staff and minuscule budgets compared to the development of the initial game.

On a browser game, the process is a bit different. Since there is no physical product shipping out in flashy boxes, you can deliver new content with virtually no deployment costs. However, in this sense, it means the job is never quite done. It becomes a constant effort to continuously improve the product. It also becomes trickier to try to sell it.

So this article will be a little different than a “post mortem” on a typical console or retail game, as I am still actively working on the project. Forumwarz is my full-time job. At any given time we have a lengthy list of enhancements we want to add to the game. In a given week, I typically deploy 10 to 30 updates. Most of them are small bug fixes or enhancements to streamline the process, but sometimes they are larger features that make up entirely new components of the game.

What’s Forumwarz?

Forumwarz is a parody role-playing game. You play it in your web browser. The hook is, instead of playing as a knight battling orcs in dungeons (or whatever), you role-play an Internet user “pwning” fake internet sites. Yes, that’s right: Forumwarz is an Internet game where you simulate an archetype of an Internet user. You can play as a Troll, Emo Kid, Hacker, Camwhore or Permanoob. Within the game’s universe, there are hundreds of fake internet sites that you navigate to, leveling up, gaining new abilities and employing new equipment. You also meet and interact with all sorts of interesting and sometimes bizarre characters along the way. We like to call it “the Internet — in game form.”

Our team is quite small. I’m Robin “Evil Trout” Ward, the only full-time employee and I’m responsible for the programming. I came up with the initial idea for the game. Our head writer is Mike “Jalapeno Bootyhole” Drach and our third partner is Jason “BINGEBOT 2015″ Kogan. I’d say at this point all three of us are game designers and heavily involved in every aspect of the game’s development.

The Perks

It is awesome to have created something from nothing (okay, nothing but a high-speed internet connection and healthy dose of caffeine). A few years ago, Forumwarz was just an idea, and now it’s a game that players enjoy every day. I remember the first few pieces of fanmail I got and how awesome it was to hear people gush about it.

My professional background in programming before Forumwarz was J2EE and PHP, although I’d dabbled in many other languages in my spare time. For Forumwarz, I decided to try out Ruby on Rails because I’d heard positive things about it. I quickly fell in love.

Ruby made all other programming languages look ugly to me. Rails made complicated web tasks simple. I found it easy to jump in and start learning, but hard to master. I am still learning to this day and it’s a huge privilege to be able to work with it.

The Doubt

Before I worked on Forumwarz, I was a web developer who implemented other people’s ideas. This sometimes meant doing things that I thought were wrong for the products I was working on. Don’t get me wrong: I understand that I was building software for other people in exchange for their money, and I was happy to build things however they wanted it. But there was always this feeling in the back of my head that, “Wow, if that was my money I would do things differently.”

It’s one thing to constantly tell yourself that you wouldn’t make the same mistakes that other people make. It’s something completely different to step up and start putting your money where your mouth is. In fact, it’s downright terrifying.

I remember when I first started telling people about the game. Some were friends and family. Some were members of the local Ruby/Rails community. I must have explained the concept several dozens of times. I am not exaggerating when I say that, save one or two exceptions, I always received a blank stare. It wasn’t hard to read their reactions: They either didn’t understand the idea or, worse, thought it was stupid. The honest ones even told me so (and I appreciated it)!

If I could go back in time and give myself only one piece of advice it would be: Doubt is normal. If you are investing your time and money in a new venture or project, you will doubt yourself.

I worked for over a year on Forumwarz before we opened it up to the public. I kept up a furious pace of development, working 10-12 hours a day, usually taking one day a week for rest. I was investing an enormous amount of time in something that I couldn’t even explain to people properly! Before we launched our beta, I’d tell myself on sleepness nights that at least it was a blast to learn, and it gave me the opportunity to fall in love with Ruby on Rails, so it wouldn’t matter if only five people ever liked it. Still, I knew there was someone out there who would get the joke.

Launch

We launched the game in an invite-only beta on Halloween 2007, through the popular Something Awful forums. Hundreds of people played that day, and we watched them post their responses. Our entire team was blown away at how much positive feedback we received right out of the gate.

To this day, it remains one of the most positive experiences of my life. I learned a valuable lesson: Just because other people don’t get excited about your idea doesn’t mean it’s a bad one. I’m not sure if I was just terrible at delivering the pitch. Or maybe Forumwarz is a game that’s simply better experienced than explained. It’s likely a bit of both.

We took off the “beta” tag and opened our doors to the public in early 2008. We quickly grew to 30,000 accounts. In October, we launched our second episode of the storyline which had a small fee ($10) to play. Shortly thereafter we hit 100,000 accounts and have been growing aggressively since. Word-of-mouth recommendation and positive feedback from influential sites like Wired.com and Gawker gave us the initial boost in membership, and we’ve followed up by advertising wherever we think we have a chance of being noticed. Now, after about a year of being open to the public, we’ve seen more than 130,000 people sign up for the game. I can finally say with confidence that more than a few people do get the joke.

Growing Pains

Scaling from 1,000 users to 100,000 users in one year presents a great deal of difficulties. When I say “scale,” I am not simply referring to the site’s performance (although we underwent several major hardware and software upgrades to sustain the load). I am also referring to the infrastructure you need to deal with a community that large.

If your forums get 1,000 posts in a day — especially on a site that’s essentially “about” flaming forums — will you have the resources to moderate them?

What about bug reports? Would you expect that many users will submit a bug reports just because they can’t solve a puzzle in the game?

A small percentage of your users will try and hack your site. Most people are smart enough to avoid SQL injection, but is your site safe against XSS or XSRF attacks? And there are other, less immediate issues related to having a suddenly large community. Some users will simply email you with personal comments and you’ll seem ungrateful if you don’t reply. In a given day, I receive hundreds of emails related to the site (errors, correspondence from users, bug reports, etc). If I responded to each one I wouldn’t have any time to work on the game at all!

This is something we are still very much working on. We have elected a couple of moderators who are doing a great job maintaining our forums. We recently launched a knowledge base to help people find answers to their questions, but it’s far from perfect. I know that we’ll never be able to help every user through the game, but we want to make sure that people have as close to a painless experience as possible.

Having a thick Skin

Gamers are awesome because they’re often intelligent, focused and passionate. However, that also comes with the side-effect of them often being quite opinionated.

Gamers will criticize just about every decision you make. A certain percentage of it can be ignored as trolling, but sometimes I’ve made decisions that I thought were in the best interests of the game and it wound up upsetting many people.

Forumwarz has evolved to encompass many different gameplay styles that all interact in one game ecosystem. As I mentioned before, our team is small. We do our best to think things through, and we often solicit our users for feedback on upcoming features. However, in my experience, no small group can effectively predict how tens of thousands will use a new gameplay feature. We do our best when we launch new content, but the real testing is done when all those eyeballs fall upon the page.

If there is a major problem with something, it shows up immediately. Fortunately, since the game is web-based we can deploy updates quite quickly. In fact, I have gotten somewhat used to only launching a feature when I’m sure I’ll have a couple of days set aside to throw up patches to address any initial issues.

As I said, most of our users are passionate because they truly love the game and want it to be the best game on the web. Their feedback is invaluable. Others, however, can be quite mean. If your project ends up attracting any kind of sizable community, be prepared for nastiness. People will say hurtful things, and they will make it personal. Sometimes I find it hilarious (like when they Photoshop my head onto images) but other times it does sting. So make sure you have a thick skin!

The Road Ahead

I recently read a comment on the Hacker News (http://news.ycombinator.com/item?id=424111) that resonated with me:

I asked Jessica Livingston to speak at the business of software conference, and I suggested that
she talk about all the ways Y-Combinator startups fail. “That would be boring,” she told me, “it’s always they same thing: they just stop working on it.”

As someone who has started hundreds of software projects in my lifetime (most of which only lasted a few hours of development), I fully understand this. Keeping a web business online involves working hard through many periods of doubt. Most people don’t stop because they are starving to death and can’t feed their family; they stop because they have grown tired of it or have been discouraged by some kind of recent event (perhaps income drops, a new feature was a disaster, etc).

I’m quite proud of Forumwarz and the community it has spawned. It is worth the occasional sleepness night or headache to keep it going. Ultimately, it’s been quite rewarding to work on and I will continue doing it as long as I possibly can. If I hadn’t persisted through the doubt when this started two years ago, I’d still be developing other people’s ideas and wondering if anyone would get the joke.

Introduction

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.

Advantages

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.

Disadvantages

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.

Conclusion

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.

Booze Quest is a browser-based game written in C# using the ASP.NET framework. The game started about half a year ago as a few pages of scrawled notes. From then, the idea rolled around in my brain and I fleshed out a real design document over a period of several months. When I heard the BBGZ was hosting a competition, I decided to finally take the plunge and give the game an honest shot.

What went right?

- The design document. I wouldn’t have made it thirty lines of code into this project had I not had a solid design doc. The time limitation made it absolutely essential that I didn’t rewrite code or hammer things out on-the-fly, and fleshing everything out on paper beforehand saved my butt. Typically, I tend to write code in my spare time to learn something new and not to actually produce a finished project, so I’m not in the habit of producing documentation for personal projects.

- The beta testers. I’m blessed with some vocal beta testers who really acted like a free QA department for the last month or so of the project. I’m still getting great feedback, in fact.

- The humor! Booze Quest’s idea is that it takes a traditional fantasy RPG game and turns it backwards, making you the questgiver instead of the adventurer. I was afraid that nobody would get the overarching joke that is the game, but I received some positive feedback regarding the yuks so I consider the humor as a point which went well.

What went wrong?

- Time management. I suffered from the same problem everyone else did: I ran out of time, leaving some things undone. I had hoped to include player-versus-player combat in the game before the deadline, but ultimately I had to put that portion of the game on hold.

- Balancing was never done. The game was balanced using the “whatever sounds good” method, and the time I had allotted for proper balancing was swallowed up in bug testing. Ultimately, I’ll be adding more content before I take a stab at balancing everything.

- Database code & hosting policies. I never considered where the game would be hosted until about halfway into the project, and that was a big mistake. I ended up going with a shared hosting plan, which put me in a trust environment which broke ALL my database code, requiring a total rewrite and swallowing several days’ worth of time. Next time, I’ll be doing my research and upping test code to a real server early in a project.

What I learned

This was my first browser-based project (first multiplayer project, in fact), so I learned volumes about web technology, web page interface design, database manipulation, and HTML. I learned that you should open as many avenues of communication between you and your players as possible, because they will take advantage and you will benefit. Finally, write down every idea you have for a game! Keep a binder or something and just jot down notes, you never know which of them will mature.