Four months ago a few friends and I launched a game, a fun game, a game called Hack Wars. Since this time:

• We have had 2164 people create accounts.
• We have grown our community to 800 return visitors a week (this includes people who login from more than one computer, mind you)
• We have had generally positive responses from the many friendly people who have helped us with the beta testing process.
• We have written about 40,000 lines of code.
• And, maybe most importantly, we have learned a lot about the pitfalls and challenges that are involved in creating an MMO.

The launch of our new website, we hope, heralds in the dawn of a new era for Hack Wars. We feel the proof of concept phase is pretty much over. It's a fun game, people seem to like it, and we've added a ton of features since launch (and will continue to do so). We can now concentrate, in a more formal manner, on promoting Hack Wars, finding ways to make money off of the game (right now running the servers is putting a pretty big dent on my wallet, not to mention that a little bit of income wouldn't be horrible), and on fostering and encouraging our online-community in a more active manner -- something which can be hard when you're madly running around fixing security problems or some major piece of game functionality that exploded with your last major update. To celebrate this illustrious new epoch for Hack Wars, I thought I would write a blog entry on our fancy new CMS retrospectively describing some of the game development process to this point -- Oh, and this is a blog entry so I figure I'll do it as a top ten list.

I think some screen shots are in order, to illustrate how far Hack Wars has come in these past four months.

Hack Wars, January 2008.

Hack Wars, March 2008.

Top 10 Challenges Facing the Development of an Indie MMO

Without further adieu, in ascending order, here are the top ten challenges that faced our development of Hack Wars up to this point -- based on the scientific procedure of popular vote between Cameron and I.

10. Spelling

Face it, computer scientists have terrible spelling (their might exist one computer scientist with pristine spelling... I've yet to meet them). When developing a large scale application like Hack Wars -- pushing 40,000 lines of code -- this can occasionally cause some issues. Many of the function calls in Hack Wars are invoked via strings, little typos have lead to us wasting good chunks of our time... I point you towards exhibit A: the function peakAtCode(). When dividing programming up between a group of individuals, realize your strengths, i.e., make sure someone spell checks Alex's everything.

9. Sickness

For a few months of our game development cycle, one of our key developers was extremely ill -- I think he may have been technically dead at one point. While on the mend his doctors put him on psychotropic drugs, which also didn't help his coding prowess. Until they invent super-human coding cyborgs, it seems prudent to plan for sickness (dog attacks, bus accidents, etc.) when developing a big software project... luckily our co-developer got better, and everything worked out nicely.

8. Friendship

An independent game project like Hack Wars starts with a group of friends -- presumably we'll eventually be a ruthless corporate powerhouse. Realize you will spend a lot of time with said friends, and will occasionally want to kill them. If you can handle this prospect, and are slightly sadistic, then maybe you and your friends are an ideal group of individuals to undertake making a game together -- just don't actually kill each other, that's against the law. It should also be noted that we have found, while working on this project, that we spend a lot less time with our other friends -- "the uninitiated" as we call them.

7. Synchronization

An MMO is not your grandma's serial gaming development project. The server-side design for a game like Hack Wars involves juggling a lot of concurrent processes. Designing for this parallel paradigm can lead to frustrating synchronization errors. These types of errors, when they arise, can be hard to debug, since they often involve a series of conditions that is hard to reproduce. Furthermore, your game might work great when you're testing it with three or four people but, as we found, when you go live and have many more people connecting, unforeseen circumstances can arise -- during the first month or so after launching Hack Wars, there were several frantic coding sessions to correct this frustrating variety of errors.

6. Life

Alexander and I are Master's students in Computer Science, Stephen is finishing up his degree -- Cameron is a Physics graduate who has a lifestyle closely resembling a cat's. School has a nasty habit of interfering with game development. Jobs, family, religion, and life in general, are other categories of things that grossly interfere with an indy game development project. If you are planning on developing a large game, try to avoid these nuisances at all cost but, alas, sometimes they can't be completely avoided. In some ways, a big project like this begins to become a major part of your life (at least we have found this in the initial stages). Launching Hack Wars has not been anything like pushing a fledgling out of a nest and watching it fly away; it has been more analogous to trying to roll a baby hippopotamus up a hill -- for some reason.

5. Swing

Swing is Java's recommended, and officially supported GUI toolkit. Theoretically it works well, but in general it exhibits bizarre behavior and sometimes programing with a hammer is necessary to get it to do exactly what you want. Granted, some of our problems relate to deficiencies in the thread-safe nature of our front-end; Swing, however, is a beast to make completely thread safe. In any future game development projects, we will likely move towards an OpenGL-based graphics engine -- Java is getting better at supporting OpenGL. If you're undertaking making a game in Java, save yourself a headache and plan to use this from the start.

4. Server

Hack Wars was initially developed on our personal computers. We quickly learned, upon buying our fancy-pants high-performance server, that things don't necessarily behave the same on a significantly different architecture -- even if it is running all the same software. Specifically Tomcat (the Java based web-server we run mainly for XML-RPC) ran poorly, even though it had been tested thoroughly on our computers. No matter how thoroughly tested your code is on a traditional consumer architecture, expect to do some re-coding when porting to a high-performance server environment.

3. Money

So far, I have been bankrolling Hack Wars with some initial money I received from selling stock -- I will stress here that I did not sell very much stock, and that we're all students (or unemployed physicists). Hack Wars is running on a fairly shoe-string budget. The main cost running an online game comes from network bandwidth -- unlike other website projects I have partaken in, I can't easily run it on a jury-rigged server I set up at home. Server costs are currently running us about $150 a month. This amount will likely grow as we get more users -- a project like Hack Wars eats up a lot more bandwidth than, for instance, a PHP-based browser game. We're working on several schemes to monetize Hack Wars, however. In our first several months, much more time has been spent fixing bugs and building a community than trying to make money -- this, we hope, will magically happen in time.

2. Security

About one month after the launch of Hack Wars, all the money in my in-game bank account disappeared. After an incredibly obnoxious conversation with a script-kiddie, we were introduced to the joys of an ARP poisoning attack. Three frantic days of little sleep later, we introduced public-private key encryption to our packets, and several other security fixes. It wasn't that we hadn't planned on securing our communication in this manner, but we hadn't expected that an individual would so rapidly reverse engineer our system in such a detailed manner -- in the future we will expect this.

1. Sleep

Many of the previous issues that we have outlined were exacerbated by one underlying issue, an incredible lack of sleep. This has been motivated by the frantic pace that we have undertaken after launching Hack Wars. There were a few times we stayed up way too late, implementing some great new game feature, only to find some key feature of the game broken when we wake up several hours later after passing out -- we, probably not quite quickly enough, learned to avoid doing this. There have, however, been times where a frantic pace has been unavoidable -- I don't think I've ever slept less than the frantic days after Hack Wars' critical security flaws were revealed. It felt, at that time, that our six-months of work might be invalidated by our security oversights. The moral of the story is, if you plan on creating an indie-MMO, plan on giving up, for the most part, sleeping.

Conclusion

So there you have it, a bit of a reflection on our MMO game-development experience to this point, a process that we are, very much, still learning about as we go along.