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.)

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.

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.

The cycle was prototype-develop-test, which allowed for a somewhat rapid prototype to finished product. The issues with this style will be addressed later. When you are one person, developing a complex game, any sort of direction helps.

This iteration was the third of the Mecha Asylum rewrites. Well, that isn’t completely accurate, the first two iterations were unusable and early PBBG research projects. The first two working and completed iterations of Mecha Asylum did allow for specifying the direction of the current one.

What Went Right

1. Separation of presentation from business logic.

   Well, the earlier incarnations also separated the presentation from the business logic, but this was the first time I used an actual template technique. While it worked, it allowed for better focus on the view, and followed more of the MVC pattern. Not strictly, but MVC tends to be cleaner, because the majority of the logic is outside of the template.

   It allowed for focusing on the code, where it should be and added needed organization for easier debugging later.

2. Game was completed on time and well was actually completed.

   The other versions weren’t so lucky. With the other permutations, it felt as if the flow of the game was disjointed midway through development. Even though the final product in this iteration ended with the same result, it wasn’t apparent until development was over.

3. Basic attempt at achieving intelligent money

   The concept, I believe, was noble in that the player would be based on a more random calculation. So instead of being able to easily predict what they had to do to quickly advance in the game, it would require more time and effort.

   Well, in theory, and if it had worked. Players like a bit of unpredictability, but it is hard to say whether players would have enjoyed this feature. When it comes to cash pay out, unpredictability makes sense in the case of a stock market like feature, but it might have been very annoying in retrospect.

   It is easy to take the theory of unpredictability = fun to the extremes, but players know what is fun and what isn’t, so it is better to let them decide. It is also better to also remember that while new ways of doing old tasks can be better, it isn’t always the case.

   I thought the concept was a success and the game never had any active players to find out if it actually was a success or failure.

4. Left out the kitchen sink.

   The very early iterations tried to include the kitchen sink and shifted the direction of the game to where none of the features were completed. I tried to focus on the features that were planned and left out the features that would be nice for future versions.

   It is too easy to put down this feature or that feature and when you try to include team features, it can become time consuming. Although, in all of the iterations I’ve never reached the stage when team features could even be considered.

What Went Wrong

1. Template technique failed to work on later versions of PHP.

   The template system worked well with version of PHP that I tested the site at the time. When I visited the site 6 months after development was completed, I found the site no longer was functioning. It appears that either a bug was introduced to break the site or a bug was fixed that the template system was dependent on and I didn’t notice it.

2. Early attempt at primitive artificial intelligence for calculating money was flawed.

   I thought it was call that the system in place for calculating how much money the player made was based off of a generic sequence. If it had worked, it would of made the game somewhat more unpredictable and I would have hoped more fun because of it. In which case, the only reason the player still had anything was, because there were checks to ensure that the player never passed the minimum threshold.

   In hindsight, it probably would have been easier and better to just not rely on such a complex system for calculating something as important as the payouts for players. At least, not with an incomplete AI system.

3. Game was far too complex.

   The game was so complex, that playing the game after it was completed left even me confused on what to do. The game lacked focus, and that is partially what makes a game fun. It lacked the fun factor, because it made the player think and do too much.

   Some people like complexity, but to better define it, it would be to say, they like to micro-manage their game details. There wasn’t any micro-managing, there was barely anything except forms for doing things without any apparent purpose.

4. The game lacked a seamless flow.

   Along with #3, the game lacked an inherent seamless flow from task A to task B. In games that I’ve enjoyed, you knew or didn’t have to go far to figure out how to perform the needed tasks to advance in the game. That is difficult to achieve in game design and development, but it would have been worth investing another month or two of polish to pound it into the game.

What I Learned

I learned that playability and fun factors aren’t decided by me. When you develop a game for yourself, then only you are going to be playing it. A game must combine elements that will be fun for other people. In that you must design and develop for the entertainment of others.

Whether a player will find the game entertaining or a flop is ultimately to be decided, but thinking about them is the first step. The next step, would be to allow a select group of players to test the game and give feedback on what they honestly think of the game. If you have your friends do it, then they might tell you what you want to hear, instead of what you need to hear.

It is important to have a group test the site for playability as well as beta test the site. When you beta test, your concern is whether or not the site functions as you intended. When you test for playability, you are testing whether or not the game is fun. If those playing the game don’t think so, then it is not.

Simple is better, in the early stages of the game and early versions. When the game advances and players start demanding certain features, then go in that direction. Too much time was spent on features that I liked, but not necessarily what the players would like. When I do it over, I’m going to develop a subset, do those features very well and then go where the players take me.

While this iteration of the game worked out better than all of the previous permutations before, it was still a failure. The next iteration will build off the failures and successes of this one. If all goes well, I’ll have another postmortem before the end of 2009.

My name is Ron Rejwan, and I’ve created a relatively small game called WarGames 2.0, which at the time of this document being written has approximately 45,000 registered users.

WarGames is the very classical definition of a browser-game – it runs on your browser, requires no downloads, supports all the major browsers and – the most important part – doesn’t have all the amazing graphics that are being made for all of the new juggernaut game projects.

In a nutshell – as soon as you sign up, a virtual nation is created and from that moment on you run every possible aspect in it; from setting taxes and the national budget, to conquering land, conducting espionage operations and run a huge alliance.

I have gotten the essence of WarGames from Earth 2025, which was a favorite of mine a long time ago. I’ve decided to take it, put it on steroids and give it a professional look and feel.

The soul of the game – The players:

No matter how good your game is, how pretty, how much functionality or innovativeness you’ll implement in it – if you won’t have players or players won’t stick around for more than a short while, your game will be stuck at the ground floor forever.

As I’ve mentioned before, WarGames lacks the impressive eye-catching graphics of corporate games, and that’s where attracting new players is a problem.

The game itself is highly addictive – you can ask any of the hundreds of players who are playing for 6+ months now (Around 2-3 hours a day) – including myself!

GUI:

Do yourself a favor, spend a couple of hundred bucks and pay a graphic designer to design your GUI. Usually that’s the only graphical aspect of this type of games, so invest in it. It’s worth it.

The Community:

Devote as much time and effort as you do on improving your game as in growing the game’s community – this is a big one!
Give your players as much of freedom of creativity and communication as possible. Here’s a list from my game, you can “borrow” these ideas if you want to (I don’t mind, really):

• Organized and moderated forums – Critical to any game
• Wikipedia (Or WarPedia in WG2) – Not critical, but very helpful
• Global chat
• Alliance forums – These are automatically managed by the game’s engine and add a nice communicative tool for my players
• Instant messenger – Personally I’ve taken this idea from FaceBook’s IM. You can always see when all your allies and friends are online and immediately chat with them.
• In game message system – Vital for any online game.
• In game alliance messaging system – Very important to keep alliances organized.
• I keep posting contests and important announcements in the forums, and then publish them in the game’s admin announcement page, to get newer players into the forums as well.
• Country and alliance flags – each player can design his country’s flag in a small editor I’ve given all players. Also once in an alliance, the leader can design a flag for the entire alliance.

New players:

New players are hard to attract. Especially in non-graphical games like WG2.

I’ve decided to make WG2 newbie friendly as possible by doing the following:

• I’ve written an automatic tour that fires up as soon as a new player registers (And can always be viewed later in the game)
• AQHS (Auto Quick Help System – Also a part of my terminology ) – This nifty little JavaScript code has a dictionary of certain words in the game and automatically marks them. As soon as a player moves his mouse over one of these marked words, a small pop-up with a short explanation shows up on screen.
I’ve obviously left an option to turn this feature off – as it can be quite frustrating for more experienced players.
• Since the beginning of the game I’ve designed it so that every single piece of text is loaded from a formatted XML language file.
Later when I reached around 20,000 users, I’ve asked for their help, and the game has been translated to Hebrew, French, Chinese, Arabic, Romanian and Spanish.
• Since WG2 is a free-to-play, no ads, no spam – donation based game. I don’t have endless amounts of funds to throw away on publishing the game to get more players. So instead I’ve given players an automated system to bring in new players. Once a player signs up and plays for a while, both the player who signed up and the player who brought him in get a bonus.
• Give away free bonuses in the game for players to vote for your site daily on 10-20 game listing sites. It brings a lot of traffic.
• In the forums I’m giving away bonuses to all players who post a link to the game. Obviously, there are certain rules to keep away senseless spamming which will do more harm than good to your game.
Only allow established forum users (on the published forum) to post a link to the game, and ask them to post both a referral and non-referral link – as most people are automatically deterred by referral links.
• New players are protected from attacking or being attacked until they play 300 turns. This is to prevent new countries from being eradicated the moment they are established.
• New players have an option of creating their nation in “Tutorial mode”. This allows them to play, and as soon as they reach 200 turns, their nation is automatically restarted into the game – allowing them to play around the game before actually making horrible mistakes of their own).
• Power protection – protect lower leveled players from higher leveled ones. In WG2 you can attack other players that are in your 75%-200% power range.

Ease of use:

Besides the initial game tutorial, help files for each page, Wikipedia and the help forums I’ve also taken several steps to make the game less frightening to new players:

• Quick menus jump whenever you put your mouse over another player’s name, allowing quick access for some very common commands (Send message, send aid, attack, spy, etc).
• Country levels – In order not to scare all new players by all the options of the game, I’ve locked some of the more advanced screens (Which are usually only needed later in the game when you have a more advanced nation).
I’ve given specific criteria for advancing through the levels, which teach the new players how to play the game, while exposing them to the game’s options slowly.
• If your game is HTML based (Or ASP.NET based in my part – which is basically the same) – use a style sheet (CSS file) to keep certain things consistent in the game. Green colored messages are always good, while red colored ones are bad. This way a player can very easily spot something’s wrong with his country and fix it.
• Notifications – In WG2, sometimes you have to react quickly to attacks by other players. In order to help my players know when they need to act, I’ve put a very basic email notification system (Which doesn’t send over 1 message over 2 hours, and can be turned off) and a small pop-up screen if the player is currently online and playing.
• Important variables are always visible and updated.
At the top of the GUI there’s a special spot for how much turns, money & food you have. At the bottom right there’s a small box that shows how much money, food and oil you’re making every turn (And some more advanced stats that I won’t go into here).
• Allow players to restart. Although you should put restrictions on this to prevent abuse.
• I hate it that games show you that something happened at 12:45am. 12:45 where? Is it US east time or is it Australia time?
Instead show how long ago something happened: 
“X attacked you 3 days, 2 hours and 53 minutes ago.” – Much better.
• Technology – WarGames 2.0 is completely AJAXy (I know it’s not a real word). This also makes the playing experience much better and smoother, and also lowers the traffic amazingly!

Bugs and errors:

How many games have I seen that simply shatter their professional look and feel the moment a bug occurs.
A hideous page, spewing non-sense code and errors at me, and causes me to hastily close the browser.
First of all, add a “report bug page”, which players can quickly and easily report errors directly to you.

And regarding those hideous error pages, always catch them and present the user a nice, “we’re sorry, it happens” page.

Innovation:

I personally play my game all the time.

It’s an amazing way of finding bugs or ways to improve the game.

I think the best changes I’ve made were because one night I’ve tried doing something and thought to myself “Hey, it would be pretty cool if you could do this and that..” – And so a new change is added.

Always encourage players to add suggestions to the game. If I’d had to guess, I’d say WarGames is 50% my ideas, 50% it’s community.

It’s also very important to remember that not all player requests are for the good of the game. In the end, you are the lead designer, and what you decide will happen. Sometimes they’ll love you, sometimes they’ll hate you (They’ll usually hate you) – but they’ll love the game, and that’s what important.

Bug abuse and cheating:

I can’t stress how important it is to protect yourself of these kinds of things. They can really throw your game off-balance and require you to restart the entire game.

You wouldn’t believe how much time and effort some players will invest in trying to overcome all your protections and abuse every bit they can find.

Some issues off the top of my head:

• SQL Injection – If you use a SQL database, protect yourself from this!! It’s coding 101, but it’s worth mentioning (For more on this Google it).
• Buffer overflows and integer overflows – In .NET buffer overflows are no longer an issue, however integer overflows are. Make sure your user’s input is within range of all your variables.
• Input check – In WG2 some inputs are numeric only and some are English only – Simply build 2 controls, one that only accepts numeric input and one that accepts only English input. Problem solved.
• Try to keep as much of your validations in one place. To protect from SQL injection, all of my SQL commands go through one class, which automatically protects from SQL injection.
• If you notice someone who’s cheating, swiftly punish them and publish their punishment on the forums. If it’s later found out that someone cheated and you’ve silenced it for your own reasons – it will seriously backfire on you.

Reward your players:

Let them show off their accomplishments.

I’ve placed a hall of fame with some basic statistics and more importantly, players automatically get medals once they pass a certain criteria (Launched more than 100 nukes). Those same medals later show up on their player profile page and on an automated signature I’ve supplied them with.

I’ve even sent one player a trophy (http://www.wargames2.net/Main/Beta_images/ScreenShots/trophy.jpg) – I planned on making this a tradition, but it was too time consuming.

Summary:

Choose something you love, and stick to it. Don’t try to do something you don’t understand or know enough about. That’s what I did and it worked.

Listen to your players, but develop a thick skin to ignore some of the less polite ones.

Make the best game you can, put your heart and soul into it – and it will be the best game you can make.

Be very communicative with your player base:

You are definitely not going to get everything right the first time. It is frustrating when the simulation that you run in your head about how fun something is going to be is not how the users end up using it. Make sure they have channels to tell you what they don’t like. In my case I wrote a form that goes on the bottom of all of my pages so the user can post a comment to me. Their comment is stored in my database with their identifier so that I can talk to them in game. I also made a built in reward system so that I could give people things for pointing out my mistakes. A complaining user is so much more valuable than a quitting user. Treat them like a valuable member of your project.

Listen to your players frustrations but remember that you are the game’s architect. Don’t implement a feature just because a user wants it. One of the most valuable lessons I learned in a class about Quality was that the end user, most likely, will not tell you what THE problem is, they will tell you what THEIR problem is. You are the expert of your game and you need to make sure that you are alleviating the pain of the end user while not throwing off the game or compromising what the experience is supposed to be about. A great example of this is that when people started playing the game they were confused about what to do or how to do things and they would ask me specific questions. “Do I need a surveyor to survey a planet before I build? How do I get units from my highliner to the planet?” I asked if the tutorial that I force everyone to go through did not explain it well and usually they just said that they skipped through it and tried to start playing. Throwing up my hands and saying “well it is your fault for not reading the tutorial” is actually not the correct answer. Instead I made a series of video tutorials for the game.

Another way I made communication easier was to include a forum in the game. I am using phpBB, but I integrated it directly into the game by creating the forum account when the user’s game account is created.

Games are interesting when they make sense:

One of the things I strived for when building TerraTanks was that if something happened to you that was unexpected, it would at least make sense. The simple visual presentation belies the depth of cause and effect that goes on in the game. Here are some examples of what I am most proud of:

• In order to find out about enemy locations to attack them you have to use your spies. To keep with the global management theme, you just have one ’spy level’ that is used for your character. When you spy on someone the game compares your spy level with their spy level and you are given spy report based on how you compare. The spy level is only based on how much you are willing to pay in gold every day so while larger players should have a better spy level, they need to play it correctly to do so.
  When you get your spy report on a player, you will find out about all buildings that exist a set distance away from your closest base for every week the building has been around. So if the distance is 25 for every week I will see buildings that are 50 distance if they are 2 weeks old.
  While this system seems complicated, it expands the strategy of the game. New players are harder to find and attack giving them natural setup protection. Building a base in enemy territory becomes a good strategy for scouting. It gives you a reason to keep expanding in new places. It balances old big players with new small players. It makes sense that it would take a while for your spy network to find a newly populated planet.
• Combat is designed to play out more realistically. There are bonuses for different combinations of units that you use. For instance, the APC (armored personnel carrier) will make your foot soldiers and sappers harder to kill. If you have Scout tanks and Behemoth tanks, the scouts will act as spotters and you will destroy more tanks during that attack. Also, battles go more quickly if the forces are lopsided. If you go in with an even number of troops, you will have to slog out several attacks with fewer troops dying on each side. The attacker is charged action points for each attack and he would probably want to use those points on other things. Lopsided battles are over quickly and produce many more casualties on both sides.
• Actions in game frequently require the use of action points. You acquire one action point after some set period of time. It makes sense that as your empire expands it would take longer for you to do things. The refresh rate goes from 15 minutes when you have nothing to 1 hour when your empire is very sizable. This helps new players get set up more quickly.
• Bases are the central hub of your civilization. You put a base on a planet and you can have things up and running very rapidly. As you build on planets further from the base things cost more and take longer to build. This is a common strategy in games but it made sense to the story of the game.
• Moving your ships around in system takes 10 minutes of real time. Systems are spaced 1 hour apart from each other. When thinking about space, solar systems are pretty densely packed when compared to distance from one system to the next.

Thanks for reading all the way to the end of this post-mortem. I would love for you to come and try out my game and let me know what you think!

www.terratanks.com

I want to focus on 2 things that I think need talking about (and one of them is not web page layout). One is something games in general suffer from. The other is something my game uniquely suffers from.

Thing 1: Scope, scope, scope, scope, scope.
Something I have difficulty with is wrapping my brain around just how big something is going to be. While being big is not necessarily a bad thing, being big and empty is a horrible thing. When you create a space, that space needs to be filled out completely. The first game I made (Atlas: The Gift of Aramai) suffered from this. The driving principal of the game was “we want to make it big”. The fallout of this was 5 years creating content to still have the game seem desolate and empty as you character walked for 7 minuets to the next town.

It is amazing how the power of squares can effect the amount of content you have to generate. Filling area is literally X times more time consuming than filling a linear map where X is the length of that map.

When starting a game, think small. When you think of most browser games they occur on one screen. Depth is so much more valuable than breadth. Depth displays the designer’s creativity. Depth in a small game means that you can actually release your game in a time span that doesn’t drive you crazy.

Far be it from me to follow my own advice. TerraTanks is a very large game. I believe it is also a very deep game. It certainly is a complicated game that evaluates actions in a sophisticated way. It took me 2 months to finish the breadth of the game and an additional 8 months to add depth to a state where I am satisfied with my work. (2 months of that was under the public beta). I have a very long list of things to do to add more depth to the game. It is playable and fun as it is, but the oportunity to add depth seems to be expanding and not getting smaller as I create features.

Thing 2: I created an odd way of displaying the map.
This can be prefaced by saying that compared to many of my peers, I think sideways. It is fun to be unique in my problem solving but it is sometimes difficult for me to relate my ideas to the general audience.

This is what I mean. Most people when they want to create a map they will go about creating a cartesian coordinate system grid. People understand the incrementing value and it is easy to calculate distance using the pythagorian theorem. When I went about creating the map I originally thought of how space looked in my head. You have a universe with nested galaxies. Each galaxy had nested stars. Most stars are solar systems with nested planets. The idea of nesting is what stuck with me. What I did from that was to create a system of nested areas which defined my space. My galaxy was a square divided into 4 square quadrants like this:

0 | 1
----
2 | 3

Please note how like any good programmer I start with 0. Each square quadrant was divided into 16 square sectors so in quadrant 0 it would look like:

00 | 01 | 02 | 03
-------------
04 | 05 | 06 | 07
-------------
08 | 09 | 0a | 0b
-------------
0c | 0d | 0e | 0f

Now note that since I have 16 squares I am using hexidecimal notation.

What I end up with is planets that have identifiers that look like 0b23c5 which accurately descirbes the location of the planet in a nested notation. While it makes complete sense, this is really difficult to explain. Most people don’t have a computer science background and even if you do, people don’t view maps as a series of nested grids. While this way of making maps simplified programming in many respects, but it is not good to make your end users learn something like that to understand your game. The other problem is the effort to convert the game to a cartesian map is difficult and pretty much impossible now that people are already playing the game.

Game makers often fall for the old trap of either trying to show how smart they are or treating their audience with contempt for not knowing the minutea of their own passion. Really smart game makers can present difficult concepts in a way that everyone can pick up and understand. You don’t need to spell things out for your audience at every moment, but don’t make them figure you out either.

Most of the remaining issues with my game involve how to efficiently display large amounts of information. This is something I work on every day so I don’t think of it as something that I did wrong in hindsight, but something that is still in progress.