Psychochild's Blog

A developer's musings on game development and writing.

22 May, 2008

Early stages of MMO development

I’ve found myself working at the beginning of yet another new project. I can’t say too much about it right now, other than experienced people will probably say they want to work on a similar project. The project aims to be fun (obviously), accessible, interesting, small-scale, able to take some risks, and not a watered down game intended to appeal to the “casual market.” We’ll see if I can actually pull something like this off.

However, one of the things I’ve done repeatedly in the past has been to consider the stages of MMO development, particularly the early stages. I figured I’ve been through this enough to write a little post about it to help others. Prepare to be educated!

To know what to do, the first step is often to understand what not to do. This great post over at Elder Game talks about all the lovely things that can go wrong in many stages of development. Eric is right, this happens all to often. Note that this isn’t just because developers are dumb, but because the situation changes little by little over time. It takes a surprisingly strong manager to keep things going smoothly, so sometimes the team hesitates to bring up what appears to be an obvious flaw. Of course, some managers get so overwhelmed that even if someone did bring up a topic, they might get shooed away because there are a million other things to take care of. And, sometimes other people play a role that helps set things slightly off track. If your lead programmer, for example, refuses to work with a technology or tool that would otherwise be a perfect fit for the project, it’s seen as easier to find another tool than to replace the lead. This event might not set the whole project off course, but a dozen or so of these instances and suddenly nobody’s happy because of all the political maneuvering that had to take place to get the project going at all.

Also note that some of these problems arise because there rarely is one “right answer” that fits all situations. I’m going to discuss some things that have worked well enough in my experiences, but this doesn’t mean I think that everyone needs to follow this to the letter to ensure success.

Let’s consider the work first. I think that there are four general areas that development work for an MMO falls under:

  • Technology – This includes basic work on client/server stuff as well as tools for developing the game. This is what you hire your programmers and technical designers/artists for.
  • Content – his includes gameplay documentation, implementation, data, and system evaluation. This is often called “design” in development terms, but I think this term captures the essence more.
  • Art – The visual parts of the game.
  • Support – The non-game parts necessary to support the game: billing, CS system, website, network administration, etc.

Now, these are just handy categories to help relate tasks to. Not every tasks falls into a neat category. What about a tool that allows content designers to do data mining, is that technical or content? Probably both, so you should make sure people who understand both areas are on this team. Also note that on a really small team, these distinctions will blur. I’ve done Technology, Content, and Support on Meridian 59 by necessity.

So, now let’s talk milestones in the project. Here are the general milestones most games have:

  1. Pre-production – At the end of this, you want to have a good idea of the game, including gameplay elements, audience, etc. First pass of at the design document and other elements should have primary approval by the decision makers. Technical design is also important, so that you know what technologies you will use and the specifications for the tools you will use.
  2. Walk and Talk – The first stage for the technology. Can you walk a character around in the game and talk/chat with other players in the game? By this time the tools should be ready to go for people to start implementing content, too. Of course, things may change on the tools side depending on how the technology develops.
  3. Alpha – The first stage in getting the game online as an actual game. Sometimes measured as when you can show it to other sympathetic people and have them comment on the implementation (keeping in mind it’s not a finished product).
  4. Feature Complete – All game features have been implemented, even if they’re really buggy. Ideally, no more feature should be implemented into the game at this point, otherwise your schedule will suffer from feature creep. Of course, this is an MMO, so that’s really hard to do.
  5. Closed Beta – When you can invite select people in to play the game as a game. Most support stuff (billing, CS tools, etc.) should be established by this time as well.
  6. Open Beta – When you can invite pretty much anyone into the game to get feedback.
  7. Launch – When the real work starts. And the crying. And the drinking.
  8. Live Development – Patches, updates, expansion packs, etc. In the initial design, you should have some ideas of what content will be developed soon after launch. You might be too busy fixing bugs to worry about developing new content, but having a plan is better than getting done then dealing with the blank look on the team’s face.

Just like other areas, these milestones aren’t well-defined. Especially “Alpha” tends to have a lot of different definitions, but can be useful for general planning.

A few other things to note:

  • Flexibility is important, but often hard to maintain. It’s easier to adjust to realities in development if you can remain flexible, but the more you change things the more your previous planning becomes potentially irrelevant. On the other hand, flexibility allows you to incorporate feedback easier.
  • Between “Walk and Talk” and “Alpha” there should be a lot more steps, obviously. Good project management means that one has to define specific tasks based on the design and have them implemented on a reasonable schedule. The trick is not to go too fine or too coarse in the time scale to get an accurate estimate.
  • Tools are important and often overlooked. Same with support stuff. Don’t forget to include these in the plan, because people always do.
  • There’s not much room for feedback in this system, but that’s not an easy issue to handle. The classic problem is that everything seems fine, until you go to open Beta then people start complaining about some aspect of the game. The reality of it all is that you don’t have time to rip out and replace a whole system, so you usually have to ship anyway, even though “everyone” told you that the system sucked. Bringing on people too early, though, makes them fatigued about the project once you finally do launch. Plus, people that play the game early start to accept the flaws after a while.

There’s some of the basics. I welcome anyone with experience in the development cycle of online games to contribute your thoughts. Or, if anyone has questions, I’ll do what I can to answer them.


  1. Stages of MMO development with no experience…

    Psychochild has an interesting post on stages of MMO development. While reading this, I realize that MMO development is not really different from any other web or desktop application….

    Trackback by Over00 - Mini-MMORPG Game Development Diary — 23 May, 2008 @ 6:23 AM

  2. Would you like to *make* a game?

    [...] Early stages of MMO development, by Brian “Psychochild” Green [...]

    Pingback by Grimwell’s Blog — 23 May, 2008 @ 7:29 PM

  3. The challenges of early-stage MMO development

    [...] “Psychochild” Green has up a post to his personal site discussing some of the steps massively multiplayer games take on their way to market. His article was based partially on a post to Elder Game we discussed here on the site early this [...]

    Pingback by Massively — 24 May, 2008 @ 3:31 PM

  4. I dislike the inclusion of “Feature Complete”. Especially with the “no matter how buggy” component included.

    While it is true that there is a minimum amount of stuff needed to bootstrap the game-as-a-game (essentially walk-and-talk), it seems inane to talk about “feature complete” when your target is an MMORPG.

    MMORPGs are not static beasts complete the day the ship. They have (or should have) live teams. The features of UO today are not those of whatever point was listed as “feature complete”.

    My take is thus somewhat different. Rather than a feature-complete target, which encourages buggy implementations and a “fix it later” thought process, one should instead have a “bug-free” mandate. The idea of having a finished game in Beta that you then just bug fix is very dangerous. Bugs are orders of magnitude cheaper to fix when they are introduced than a year later.

    My personal design theory would be thus:
    1) Walk and Talk phase
    2) Build regression test suite based on walk-and-talk phase.
    3) Automate the running of the tests on daily period.
    4) Add in features. Each feature is to be bug free (Obviously not balanced properly, as that is somewhat a global function! But things like crashes, memory leaks, server side lag, are to have no-known issues) Each feature should also increase the regression test suite to hammer on that new feature.
    5) Continue to add features forever.

    The idea is people should treat the early walk-and-talk phase as the live-server and act more like a live team than the traditional raze-and-burn game developers. This also means when you do transition to live implementation, you are all set for dealing with the features there.

    Sometimes I think the danger of programming is that it is too easy to write lots of code quickly. Code should be written slowly and one should aim to minimize the amount of code written for the given functionality. A way to do this is to ensure the cost of writing code is born by the writers.

    Comment by Brask Mumei — 24 May, 2008 @ 4:54 PM

  5. You’re misunderstanding the purpose of “feature complete”. Perhaps a more accurate name is “feature complete for launch”. The goal here is that you have completed the basic implementation of the features required for launch and that no new features should be incorporated past this date. The rest of the time between “feature complete” and “launch” should be dedicated to fixing bugs and tweaking gameplay balance.

    The problematic launches of a lot of games come from two sources, in my observations: 1) not testing the technology to see if it will handle likely first-day loads, and 2) adding of under-tested features too close to launch. By setting a “feature complete” date, the goal is to set a period of time dedicated to fixing the bugs that often plague launches.

    After launch, you need a process in place to keep adding to an MMO. You’ll notice the title of this post, however, is “Early stages of MMO development.” What to do after launch is a completely separate issue. You should do some planning for after launch, if only to make sure you don’t paint yourself into a corner during development.

    As I mentioned, however, this cycle doesn’t leave as much room for adjusting to feedback. However, you do need periods of relative stability so that you can launch, post updated, do expansions, etc. That’s what the purpose of “feature complete” in this context is for.

    Some further thoughts.

    Comment by Psychochild — 24 May, 2008 @ 5:10 PM

  6. I’m afraid I do understand your point with feature complete, I just disagree about it being a worthwhile goal.

    Practically speaking, features will be cut. Features will be added. It is best to build a structure that can withstand these insults rather than plan to not encounter them. Especially as the live game will face the same challenges anyways. MMORPGs launching with poorly tested features is not because they added them at the last minute. It is because they had no way to keep those poorly tested features on a test server where they belonged.

    From a very early stage the game should be considered “live” with no more bugs than you expect from a live game. Periods of relative quiet punctuated by expansions seems like the waterfall development model to me. Waterfall development of an MMORPG which, practically speaking, you may be forced to launch six months early, seems dangerous. An evolutionary approach which requires the MMORPG to be “releasable” from a very early date – and kept that way – means that in case of an ill-timed launch all that you suffer are features, not stability.

    To put it succinctly. Features are easy to add later. Stability isn’t.

    Comment by Brask Mumei — 25 May, 2008 @ 6:14 PM

  7. MMORPGs launching with poorly tested features is not because they added them at the last minute.

    Actually, there are quite a few cases where adding an untested feature right before launch or patch was the cause of a lot of problems. Some of these were literally finished hours before the patch and included by a coder, for whatever reason. Proper procedures do help take care of this, but it’s also the motivation for the “feature complete” stage in a game’s development.

    From a very early stage the game should be considered “live” with no more bugs than you expect from a live game.

    How is this accomplished? Two ways:
    1) Have your coders and content creators write bug-free code and content. If you know how to do this, stop reading my blog and go make millions of dollars and then fund a game for me to make. :)
    2) Testing, testing, testing.

    However, testing is no good if you are testing on a moving target. If coders and content developers are adding features on a regular basis, this makes it much harder, if not impossible, to do complete testing. The priority should be on finding and fixing bugs in the time between feature complete and launch.

    Further, most bugs in games, especially MMOs, don’t come from a single system, rather from a combination of systems. Even if a new feature is put in place and tested, it means that there must be additional testing with every other existing system in the game in order to ensure it’s bug-free. And, this only considers simple combinations; some bugs arrive because you have multiple systems working together. The number of tests you have to do start growing at an alarming rate when you add even one more feature late in the process. Again, this is the main reason why bugs are shipped, because the addition of features after the specified time happened and wrecked the QA schedule.

    Is this the best possible system? Maybe not. But, some companies have done well with it. Turbine figured out how to crank out monthly content for Asheron’s Call using a highly efficient system that included a full QA testing cycle. But, as I said, it may not be the best system for getting real feedback on issues like “how fun is the game?” So, if you have a suggestion for a better system, let’s hear it. “Keep adding content, QA be damned!” isn’t a solution I could get behind, though. ;)

    Now, to be fair, I think one of your biggest issues was with the “no matter how buggy” statement I said about “feature complete.” The reason why this is in place is to require that people put in the systems and not add them later. If a system isn’t quite done yet by the time feature complete arrives, you have two choices: include the feature or wait until after launch. Given how people expect a lot of features in games these days, most people think it’s better to include a buggy version of the feature by the feature complete date rather than waiting until after launch or, worse, adding the feature after the “feature complete” date and opening the door to other people wanting to include their features (and overworking the poor QA staff). But, this solution does require that you allow enough time for testing and fixing bugs that are almost guaranteed to show up. No perfect solution here, I fear.

    More thoughts,

    Comment by Psychochild — 25 May, 2008 @ 9:04 PM

  8. As a designer I see one of my primary responsibilities is to increase the value of the product from the perspective of the end user. A major part of this is to go with the Lean notion of optimizing the process of bringing an idea to market.

    In part the process of optimizing value goes with evaluating the current state of the product. Compare this with managing an Opera, the composer writes the score to devliver a certain message but when its tested you are likely to find optimization of the score done by the conductor as he rides the performance as it is being delivered. The same thing goes with games and as the development evolves its really hard to understand where your actual value lies unless each feature implemented is testable to its full value potential.

    The composer might rewrite the score if the actual performance merits, but this is almost impossible if there are buggy notes in the performance.

    However for practical and bussiness reasons following the industry standards of “Feature Complete”, buggy as hell and almost impossible to evaluate will be easier for most developers. I just think the ideals of agile development will given the same resources deliver a more valuable product.

    (Defects have severe and almost unmeasuable negative impact on the product value, so I’d go to great lengths to eliminate them asap over almost any other development priortization.)

    Comment by Wolfe — 28 May, 2008 @ 8:34 AM

  9. MMOs on Consoles: Epic Fail?

    [...] utrzymania olbrzymiej ilo?ci serwerów i osprz?tu, sam ‘developmen’t jest bardzo kosztowny i trwa d?u?ej, ni? cykl tworzenia np. kolejnej cz??ci Call of Duty ;) Wydawcy nie mog? liczy? na szybki [...]

    Pingback by 2UPgames | Your daily games blog! — 11 February, 2009 @ 6:34 AM

Leave a comment

I value your comment and think the discussions are the best part of this blog. However, there's this scourge called comment spam, so I choose to moderate comments rather than giving filthy spammers any advantage.

If this is your first comment, it will be held for moderation and therefore will not show up immediately. I will approve your comment when I can, usually within a day. Comments should eventually be approved if not spam. If your comment doesn't show up and it wasn't spam, send me an email as the spam catchers might have caught it by accident.

Line and paragraph breaks automatic, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Email Subscription

Get posts by email:

Recent Comments


Search the Blog


July 2020
« Aug    



Standard Disclaimer

I speak only for myself, not for any company.

My Book


Around the Internet

Game and Online Developers

Game News Sites

Game Ranters and Discussion

Help for Businesses

Other Fun Stuff

Quiet (aka Dead) Sites

Posts Copyright Brian Green, aka Psychochild. Comments belong to their authors.

Support me and my work on