Design Documents don’t have to follow a formula, just write your ideas. The important element of the Design Document is that you write the design document. If you don’t, then you will forget features and ideas that you have for the game. If you have ever forgotten a feature, then you know that feeling where you know you had a really awesome feature that would knock the socks off the gamers.

License

The license is going to be GNU Affero General Public License, version 3. This means that you can extend and do whatever you want with it, sell, build modules, make money, and whatever. The restrictions are mostly that you don’t say that you wrote the application and make the source available. It also means that if you change something, then I will get that change.

Front-End

The front-end will include the average features that allows you to see the game before you play it and register and authenticate in to the game. It might not seem like much, but the front end will probably take at least two weeks and I’m going to allocate up to four weeks towards the completion of the front end.

The features are going to be:

1. Pages – The administration will allow for any amount of pages to be added and the navigation will automatically be built to include those pages.
2. News – Kind of newbie-ish, but I think it is neat to give your players and potential players updates about what features are added to the game and what is happening. Leaving people in the dark isn’t very exciting and giving players tastes of what is to come and what has been implemented can be interesting.
3. User Module – Registering, signing in (logging in), forgot password, and demo are going to be parts of the game. I believe this is going to be the majority of the time spent for the implementation on the game.

Administration (Back-End)

The goal for the administration is to allow for every aspect of the game to be managed without having to access phpMyAdmin. It is really insecure and doesn’t give very good reports and information having to do custom queries. Also things tend to screw up when you have human interaction and repetition. The administration is going to have to be developed along side the front-end, because the entire front-end is going to be dynamic.

Something that has been of interest to me lately has been reports, so I want to have graphs of usage, graphs of active vs inactive members. I want to have graphs for paid members vs free members. I want to try to have as many opportunities to let the administrators and moderators to see visual what is happening as well as manage the game. Managing isn’t very “fun,” but graphs, graphs can be fun depending on what they are for.

Something else, I’ve experimented in the past has been cheating detection, but the algorithms are slightly tricky. I want to try it again, but it will most likely be a stage 3 feature. I’m going to try to apply as many hooks as possible to allow others to add it once I release the source.

As for everything else, the main features here, will be managing what items are available in the game, the price, and what everyone has. There will also be permissions, so that not everyone will be able to change someone’s info.

I also like playing my own games, but I think there is a disconnect with having an administrator play the game, because some one is going to feel that the administrator is cheating. Therefore, I’m thinking of preventing the administrators from playing the game and forcing them to create a new account. There will also be logging as to what administrators do and when they did it, so that if someone does question the administrator actions, there will be a log backing the action up.

Game Interface

To be honest, it has been a while since I have played the game, so I’m sort of going to make this up as I develop the game. My main focus will be on the front-end and the back-end. I’m also going to attempt to implement as many current features as possible in to the new foundation.

The game is a robot wars type of game, so you build a robot or many robots and then fight them against other player’s robot(s). The goal, I think is to add more JavaScript and interactivity to the game. I suppose the problem I’m going to have, is that I’m going to be limited in the terms of graphics. However, if the game takes off, then I plan on finding someone who can develop the graphics for me.

Therefore, these features are going to be the main starting point for the game aside from the games past features:

1. Modular User Interface

   The navigation will be at the left side, of course, but there will be other “modules” that the player will be able to open (show) and close (hide). For instance, there will be an AJAX chat system, which will allow the player to chat with their team and with other players. This can be locked and kept open going to page to page or it can be closed and open per page. I want to allow the user interface to allow this.

   The game will not be completely AJAX, because I want to allow those who don’t have JavaScript enabled to still play the game. It is just that the game will be a lot more interactive, if JavaScript is enabled. I also don’t see that many players without JavaScript, so I’m not going to limit the game for those 1%-2% that don’t have JavaScript.

2. Store

   The player will be able to build, upgrade, or sell their robot(s) here. Most likely there will be a table (at the start) with the different areas on the robot and allow the player to pick and choose the part they want to buy for that area.

   At the start, the player will be given a set amount of money and allow them to create their first robot. This should allow for customization, but also be fair for every player. So if the player starts out with an awesome body, they might not have enough for any weapons, so the player is going to have to make sure they customize correctly to allow for the best stats for the robot.

3. Battle Arena

   The game is slightly different per other games I have built in the past. Different robots are going to have different stats, therefore, it only makes sense to allow any player to attack another player. The other player will be allowed to decline or accept and then pick the robot they want to battle against the other. After that, the attacking player has to confirm. The battle will then start and the results will be instant.

   In future versions, I want to allow for real-time battling, if both players are online. In terms of getting the game out the door, I am not going to focus on this feature and just implement the basics.

   The winner will receive money for winning and the loser will lose money. Also given, how long it can be before battles will be fought, it might allow for other players to bet on the winner and then pool that out to the winners of the bet as well.

4. Training

   The player will be allowed to pit their robot against a computerized opponent with random, but with attributes close to that of the players. This will allow the player to see how they will fare against opponents of like systems. Also it should help with developing their robots and guessing what the outcome will be against like enemies. I’m unsure at this point whether the training will also include missions, which will allow the player to make money.

   I also have ideas on creating AI opponents for while the game doesn’t have many human enemies to make the game interesting. AI is difficult and always time consuming, so I’m unsure at this point whether I’ll be able to get around to implementing it. If I do, then it will be a stage 3 feature.

5. Teams

   The focal point of any robot war game is a team going against another team. This will be fought much like the battle arena, but the team leaders will make the decisions with the players accepting them. I always want to add as many features as possible to this, but I’m going to keep this simple. The teams will have registration, description (team and player), site link, chat, and battle logs. I plan on extending the team features as the game is developed, but at this point, I only plan on the game taking two months, so while this is a stage 2 feature, I plan on implementing it before the game is released.

User Management

The user has to be able to change their password, see their stats, etc. They will do it here, separate from the game interface. I don’t want to implement the interfaces to where they are cluttered with different details. I want players to focus on the game and those who want to edit their user info to focus on that on only display links that go along with their user info.

You could say the different areas are much like a forum, except that instead of a big forum with posts and replies, you have a game.

Game Engine

The game will be built using Yii (PHP framework), QGL (PBBG class library), and jQuery (JavaScript library). It will be developed completely for Battle Machines, with foundations in set to have the game part stripped out and the game engine used as a foundation for other games. It is just that the game engine and the game will be developed side by side and built for each other.

Stages – Roadmap

I usually develop full game projects in three months. That was when I didn’t have a 40+ hour a week job, so I’m unsure how that is going to translate to how long it is going to take to finish this project. Most likely I’m going to cut back features and just stop after the time has past. I’m expecting the project to be done within the three month time frame. If not, then I’ll return it to later. The most important part, for me, is the game part, which is the second stage, so I’ll have a chance to go back to the user features and administration later.

1. Stage 1 – 2 weeks (+1 week for Yii Framework)

   Stage 1 is building the front end and the back-end to allow for managing the front end. I suspect this will take around two weeks to fully implement. I’m allow allowing one week to get the foundation with Yii up and running before the first stage even starts. I haven’t used Yii before and I will need to get familiar with it. I think one week should be enough time and I’m expecting that it will only take a few days before I can start implementing the main features.

2. Stage 2 – 6 weeks

   The game features will take most of the time and I’m going to focus on the above features as well as taking the current features and porting them to the new framework. I’m going to be using a lot of JavaScript, but I have been using jQuery for a while and I’m fairly proficient with it. I’m thinking I’ll be able to prototype the features fairly quickly and get the features fully developed quickly. I’m going to estimate a week for each above feature and an week (or any time left) on any current game feature that isn’t implemented above.

3. Stage 3

   This will be the stage to pack as many features as possible before release. If there are still incomplete features from the first two stages, then they will be completed or polished during this stage. The main point is not to add many features as possible, but to add features that the player isn’t really going to use all that often. If the player is going to be using it, every time they play, then the feature belongs in stage 2, so that it gets as much time as possible to be developed, tested, and polished before release.

   I have already stated several features that will hopefully be in stage 3. The other features are allowing for desktop applications to interface with the browser game, so that you can have a 2D or 3D playing experience on top of the current browser implementation. Well, actually that is the only other feature I can think of, besides porting the rest of the current game features to the new system for this stage.

I like to do rapid develop as much as possible. That is just how I roll. I also like using old code (that doesn’t suck), so I intend to build upon this version’s code base when developing the second version some time next year. It really depends on how well this game takes off. I want to get at least three games out by the end of this year. Hopefully, I’ll be able to bring the previous developer back to further develop his game. This will allow the game to be worked on after I’m “finished” with the current set of features.

The other two games are Farmer Sim and Mecha Asylum, which will be built off of this game foundation (game engine), which should hopefully shorten the time for those games and enhance this game with better front end and administration features. I’m going to be writing design documents for those games after I finish this game.

Plant Wars Logo

This is Jon from Plant Wars, which is yet another PBBG (what else would I be doing here?). I started the game around 9 months ago as I was searching for a job after graduating with a bachelor’s in Computer Science. I had only learned a minimal amount of PHP for a class project earlier in the year, so I definitely have used the process as a learning experience. Still, I’m pretty sure I can tell you more about what not to do than what to do. As with any web-based game, we are constantly developing and are far from being done.

First of all, set up a test site with its own test database. Keep it up to date so that you’re not tempted to cheat and just make this tiny change on the live site first. I cheated when I implemented the password change feature. The query it used when someone changed his password was “UPDATE Users SET Password=md5($newpassword)”. Notice something missing? That “WHERE Id=$_SESSION["Id"]” clause is just so easy to forget. That was a mess that would have been worth any level of inconvenience in maintaining the test site to avoid.

Secondly, I’d recommend using a framework, such as the Zend Framework for PHP. This is because I didn’t and still don’t. I don’t even have data access objects. Sure, I store some commonly used methods in files that I include on every page. Alas, I’m still in the habit of embedding queries in the pages directly. Separation of logic and presentation? Yeah, that’d be nice.. At my day job, I use the Struts framework with Java – and while it does make the initial development take somewhat longer in the case of Struts, it is definitely worth it. The maintainability is increased incredibly by the proper separation of concerns. Once you learn a framework, you should generally find that your productivity increases. The initial learning curve is worth the sacrifice at the beginning for the long term benefit.

Perhaps the most important thing I did right was to have my friend Daniel help me out whenever possible. Going at such an endless project alone is intimidating, and having someone else to shoulder some of the burden is essential. Coming home and seeing a new feature implemented that you didn’t have to lift a finger for is exhilarating. Plus, then you have someone to brainstorm with and to just talk with about the game. Your girlfriend (or mom, if that’s the case) may pretend to care, but she’s probably tired of hearing about it.

In the same vein, it’s essential to have some trustworthy staff members. Grant these people moderation powers on your game’s forum and give them the ability to check the logs for cheaters. Write a nice administration panel for them (and yourself) that will streamline the process of checking for cheaters. For example, one button click to see all users who have shared an IP address. Examining log files may be your thing, but it’s time that you should be spending developing. Ensure that your staff is – once again for emphasis – trustworthy, as well as good role models for your community.

If you have staff that you don’t know personally help on the site’s development, don’t give them access to the live database. Restrict them to the test site – another good reason for its existence. Merge their code yourself. I made the mistake of granting access to the live database to my first staff member. I got off easy when he just made a page to bump his stats up artificially.

My final recommendation is regarding monetization: if you would like to at least make enough cash to pay for your hosting costs (which we usually manage – if barely), ensure that people can donate for some advantage in your game. For example, with Plant Wars, donors gain fertilizer (which is spent to train, fight, etc) at twice the rate of non-donors. I charge a low price of $2/month, and I’m not sure if I would recommend going that low. My initial price was $5 and that received lots of complaints and no donors, but now that the game has progressed, I’m more inclined to believe that anyone who donates currently would be inclined to do so even if it were a couple bucks more expensive. Use your best judgment. Also, I allow anything that can be bought with real money to be sold player-to-player so that a) there is more motivation for people to give me real money and b) people who can’t give real money still have the opportunity to gain the same benefits with increased activity.

People hate clicking on ads. It is worth the minimal time investment necessary to sign up with some sort of pay-per-action network, such as CPALead (disclosure: referral link). This allows players to fill out an obnoxious survey for an in-game reward, while you get some money.

Come check out the Plant Wars blog and you can also follow us on Twitter! (As a related, post-final recommendation, open up communications from your game as much as possible. It increases the likelihood that someone will find you from a social networking site or a search engine.)

“It’ll all be real-time, and we’ll need at least six database servers just to handle the sheer amount of awesome!”

..The reality is, especially if it’s your first game, you won’t be able to build something quite that large(and most of the sites you visit on the internet don’t even use two database servers, anyway). However, that doesn’t mean that you can’t start taking the first steps, by getting something out there.

But what if you’re attached to your design, and that is what you want to build?

The simplest answer is trimming – take your entire design, and start stripping things away. Generally, I find that it’s helpful to make two lists – “things that have to be there”, and “things I want to have be there”. Then, you take all of your design notes and figure out what goes onto which list.

One of the easiest ways to do that is to start by putting everything onto the “things I want to have be there” list. Then, move pieces of your game over, one-by-one. Generally, things that are worth moving over are:

• Self-contained

  The feature shouldn’t rely on any other features to work. You’re getting your game up and running so that you can add more to it, not so that it will fulfill your design perfectly from day one.

• Small

  If one piece of your game will take two months to build, and each other piece averages a few days to a week, that feature isn’t a very good candidate(no matter how cool it is). Especially when you’re building your first game, motivating is hard – the more easy wins you have while you’re building it, the less likely you are to get discouraged and stop. One of the easiest ways to get easy wins is to focus on easy features in your first version.

• Low-resource

  Most of the developers that I have seen starting to build their own games have been working in a shared hosting environment, paying $5/month. And while your game is in it’s fledgling stages, that’s fine – but if a feature on your list calls for six database servers, you may want to keep it on the “I want” list instead of the “I need” list until you can actually justify the resources.

• Playable

  The last, and probably most important point, is that your feature needs to be playable. If that feature you’re considering moving over is really super-cool but isn’t something the players can interact with, it shouldn’t be in your first version. Building features that no one can see is a bit of a gamble even when your game is established; what are your players going to care if they can’t see it?

Once you’ve gone over your list and moved the bare minimum of features over to your “things that have to be there” list, you’re ready to start working on your game. Keep both lists somewhere that you’ll see them often, and while you’re building your game periodically review them – a lot of the time, features that you’ve built into your game will make it so that other features you wanted to have(but kept off your list) are now possible – and even easy.

Codestryke, who owns and runs a handful of games, spoke about one of his games – which uses the ‘players buy turns’ system with an unusual twist: when one player buys turns, all the players get them. Turns are also kept in a ’stockpile’ of sorts – there are so many turns available for purchase each day, and once all the turns for the day have been bought players will have to wait for the next day to buy more.

I got in touch with Codestryke to ask him about why he went with this system as opposed to something a little more common, and this was his explanation:

In a turn based game everyone should get the same amount of turns as turns are actions so if someone gets more then another player then of course they will be able to dominate more. The only way to make the game fair yet earn income is to allow everyone to get them and the player who uses them in the best manner is the winner.

We do this on Cypher and did it on another game we ran called BordelloBattles where the idea came from originally. It’s worked out extremely well for both balance, a way to earn income and to bring a community effort into supporting the game.

While this business model seems to have worked out fine for Codestryke, I am sure that there are more out there – what sort of interesting business models have you seen in browsergames lately?

We started to develop OB for a school project, 7 years ago. Soon after we launched the game and kept it as a hobby for about 5 years. All that time we learned that we didn’t had a scalable game, and we had many difficulties to maintain the game.  But the experience running the game was very valuable, because we learned several useful things:

• Technical skills aren’t important – no one cares about the site being made on tech X or Y, they just want it running and bug free
• Having a pretty website is very important for converting new visitors…
• …but good game play is what keeps them around
• Having a quality website, and an excellent game play is worthless, if you don’t get people to see it!

This last point was our biggest problem! We only targeted the Portuguese market, and in about five years, we got ~5000 registrations. That is a very small quantity! One thing is a player registering, playing, doesn’t liking, and moving on. That is normal, there will always be people that doesn’t like the game. But they should at least try it, to know about it.

After realizing the problem, we searched for solutions. How to property promote a browser game? That is, with a limited budget of course. We are still working on that, but now that we learned that our biggest problem was distribution, we’ll be less likely to fall on the same problem again. At least we hope so.

All that time running the first version of OB, we had a great community supporting us, and that made us go on. A couple of years ago our current employer found us and he liked our work and and project so much that he decided to fund a new version, without any of the problems of the previous one. We have been spending the last six months working full time on OB, and getting paid for it! It’s like a dream come true, after a lot of hard work. And now we have a marketing department to assist us on promoting the game.

So, if you’re starting or running a small browser game, don’t give up, focus and work hard. There’s a huge market and we all have a place on it. Also, network like hell and share ideas with other developers.

You know how board games always have something on the side of them that says, “For 2-5 players,” or something like that to indicate how many people the game is sized for? It’s partially a practical thing, they can’t include enough cards or tokens or a board large enough for a group of 30, but it’s also a factor in the game itself. It was never tested for 30 people, for that matter it may just not work very well when scaled to 30, 300, or 3000. There are PBBGs out there with 30,000 people on a single server, how do you even design a game like that?

I have no idea. Literally, no idea whether the game I’m working on now will be fun when I throw lots of people at it. It could suck. It will suck, the creator of BattleMaster virtually guarantees it, and you know what? He’s probably right.

My current hope is that I’ve got a good idea for a game and I’ve taken the same path a lot of games take by giving every player basically the same starting conditions so they’re left to their own devices in competing with other players. But is just starting with a level playing field enough? Is there a way other than playtesting and adjusting, playtesting and adjusting to have a better idea of how to make a game interesting when you don’t even know how many people are going to play it?

One possibility I’ve considered is the idea of forcing division into groups upon the players. Creating a game and really balancing it well for say 25 and then as players join they automatically get assigned to a group until it hits the magic size and the game gets going in earnest. So a single server might be running hundreds of games at the same time rather than one game with thousands of players. Short of sites that let you play real board games online (e.g. http://gametableonline.com/) , I’ve not seen anything like this though and as with all these questions, I’m not very sure how well it would work short of building a complete game and testing it.

I know it does offer some possible advantages because you can actually have certain people fill certain roles. There will be only three people who can be doctors, two police officers, 12 zombies, etc. The roles are set and they play them out till the end of the game. Cooperative games are all the rage in the board game world right now and often they work on this very principal (e.g. Battlestar Galactica). I’m so-and-so and here’s what I can do. I have in-game abilities that maybe nobody else in the game has and vice versa. You can even have traitors who are working against the group but nobody knows who they are or perhaps even if there are any.

But then what do you do when one of them leaves?

Problem #2: Someone Comes To Town, Someone Leaves Town

In addition to being the title of a book by Cory Doctorow that I really enjoyed, this is how I describe a problem that I see as one of the worst ones a persistent online game may face. People come, try it, and then leave never to come back. Or they join it to stay but only a couple of days before it is scheduled to end or after all the empires are all built up and the game experience is completely different from players who started the game together.

Board game players don’t face this problem nearly as much. Sure, people get called away for emergencies on occasion, but the social convention is that if you’re coming to play that you’ll stick with it until the end of the game. Board games tend to have fairly short lifespans compared to PBBGs though. With timeframes of weeks or months their games are much more likely to have people quit because of something coming up or losing interest. What happens to those players? Are they a zombie that sits there unresponsive while the player is gone? Do they become a computer controled character when the player is away? Do they fade away as though they never existed?

New players are more easily dealt with. They can be shunted off to a newly opened game in order to keep them from joining too late. Or, if you design an open-ended game then perhaps it won’t matter when they join. Most MMORPGs are constrained to their world needing to exist in a kind of weird stasis. Yes you obliterated that dungeon full of bad guys yesterday. Today, it’s all put back together so someone else can go do the same thing. You’re living in WestWorld and Yul Brenner’s gunslinger will be just fine as soon as we repair him.

Problem #3: Numbers, Complexity, and the Digging of Holes

The last of three big problems that I see PBBGs having to deal with is the problem of numbers and complexity. It’s not that board games don’t have to deal with lots of variables and complexity too, they do. The introduction of a lot of different elements is what keeps a game from being something easily analyzed and “solved” to the point where it’s no longer fun to play. The problem is again one of scale.

Any board game designer has to deal with complexity by saying, “What can my players manage in their head with a few additional play aids I might give them?” Scoring, number of pieces, number of cards, size and complexity of the board are all constrained by what real people can really hold in their hands/calculate/see. But as soon as you get a computer involved the temptation is to throw out all of that. I don’t have to have only four kinds of armor, I can have 40! I can have 150 different weapons, all with subtly different values for attack and defense. I can even have each one keep track of how sharp it is. It can get worn down over time…

But then that complexity comes home to roost when it’s time to actually playtest that game. How do you adjust a game with four thousand variables without getting your own version of the butterfly effect. One little tweak here makes a huge difference over there, or perhaps even worse, a huge change here has almost no effect because of the unforseen influence of some other things you can’t seen working in the background. The more complexity you put in, the richer your game seems. But at the same time you’re digging your own grave deeper and deeper.

This is probably the most solvable of the three big problems; just scale back. But scale back to what? Unless you’re willing to lock the number of players per game at a fairly small number, what are the effects of a small tweak when it may change things for hundreds or thousands of players? Is it going to completely upset the economy in your game?

In Conclusion

What do you think are the biggest design problems PBBGs face? Have you seen solutions to these problems in existing games or have ideas for solutions that no one has tried yet? I know I’m looking forward to hearing from others interested in PBBG game design on these and other problems.

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.

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.

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.