Adult Blog

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.

Read more from the original source:
Early stages of MMO development

Tags: design, design-lessons, development, feature, feature-complete, game, games, games-business, games-design, information, live, project, psychochild, technology, time, tools, view-the-original-post-, walk-and-talk, weekend-design

Leave a Reply

You must be logged in to post a comment.