Design

"The most important issue for me would be fun. How will this system hold up to countless hours of use? How many times can I do X before it gets boring? Online games are built with longevity in mind ”no longer are you expecting to just sell the box and move on to the next title, but to keep people entertained for months and even years with a single game. It's not easy."

” Daniel Manachi , The Themis Group

One would think that, with millions of dollars on the line, the process of designing and developing an online game would be a detailed, exact, and excruciatingly careful one. Dream on. Here's how most online game projects are developed today:

• A small team pitches a project to the publisher.

• The publisher looks at some basic spreadsheets and development timelines and approves the project.

• The small team begins the design document.

• While the design document is still unfinished , the team begins staffing up and coding the game.

• The design document still isn't finished, but programmers get way ahead of the designers, so the designers have to go back and change some things in the document.

• About a year into the project, the design document still isn't finished, but the programmers have a workable pre-Alpha version of the world-building tools and database finished, so everyone jumps in and starts building, because this is a lot more fun than actually designing the project.

• At about month 18, someone realizes that most of the game mechanics haven't been spec'ed out yet and starts building them directly into the game. The design document still isn't finished, but this is explained as, "Hey, it's a living document." The team does, however, have some very cool screenshots and a basic "walk and talk" demo version to show senior management.

• At about month 21 into a 30-month development schedule and with the first Beta version due in three months, the team realizes that it is in a complete shambles. People are still designing combat mechanics (or magic, flight, siege, trade skills, the economy, you name it), even though most of the play field has been laid out in the world-builder tool and most of the art is still "programmer graphics." The data for thousands of objects, such as terrain pieces, buildings , weapons, and armor , are in the database. The team panics and decides to tell management there will be delays. They demand 10 more artists and three more programmers to help rush development to a close at month 36.

• At month 36, the new release date, the team realizes that trying to design and retrofit game mechanics into a world for which development was well underway was a huge mistake. To make the mechanics work, they are going to have to strip out most of the existing mechanics and start over, including scrapping the database. Management is not pleased, but with $6 “$8 million invested, they okay another delay.

• At month 48, after having spent almost $10 million and having stripped out about half the features they promised players, the company makes the team launch the game, even though there are over 1,000 known bugs in the game and the technology isn't stable for more than an hour at a time.

This example isn't an exaggeration; it comes directly from the experience of one of the authors, who was called in as a consultant to help clean up this same game after launch. Most game teams and almost all online game teams really have no concept of proper software design practices. What are completed game and technical design documents? Hah! Those things just limit creativity. What about a change control process (CCP)? Don't sweat it; when we think of it, we just change the code and move on. Should we comment the code? Nah, that takes too much time!

In hindsight, the problems with the games shipped to date aren't the surprising aspect. The level of success we've enjoyed in spite of the serious problems is the big surprise!

The Process: Design Twice, Build Once

As we mention more than once in this book, one of the online game industry's peculiar idiosyncrasies (read: "stupidities") is that programming often starts long before the game design document is finished. More than any other single factor, this is why online games in general ”and PWs especially ”tend to be launch disasters.

How many times have you picked up a hybrid at the software store on release day and then had to sit through a multi-megabyte patch just to get online with it? It is not unusual for hybrids to have a 4 “8MB patch waiting for the player on launch day.

At that, PWs in 2001 out-did hybrid patches in a major way. Two games, AO and World War II Online , each had 75MB patches waiting for subscribers on opening day.

For the purposes of this book, it is generally assumed that an in-house team will be building the online game. We've also split the game design and technical design documents into separate sections. As noted elsewhere, it is not unusual for these two to be combined into one document at some point, if not at the beginning, then at the end of the process.

The Design Treatment

Variously called a proposal, treatment, or game outline, think of this as a "sell" document; you are trying to convince the people with the checkbooks that you and your team know how to build this game and that it will be popular enough when finished and launched to make some money.

The treatment should be relatively short, between 5 and 10 pages. The content will vary depending on whether you are proposing a PW or hybrid, but any treatment should contain the following as a minimum:

• Genre ” Is this a fantasy medieval PW, such as Ultima Online ( UO ) , or a sci-fi shooter, such as Half-Life ?

• Graphic look and requirements ” Will this be a full 3D interface and require a graphic accelerator card? Will there be a software rendering option? Is the "look" photorealistic, anime, what?

• Interface style ” This is the view the player will see. An interface description for Asheron's Call ( AC ) might read: "A player-configurable first- or third-person perspective using keyboard and/or mouse," while UO 's might read: "An isolinear screen, ¾-raked view, with full keyboard and mouse control."

• Engine ” Are you reusing a current engine, licensing an outside engine, or building from scratch?

• Database ” If you're building a PW, will you be using a commercial database, such as Oracle or SQL Server, or building your own?

• Target audience ” Who will this game appeal to? Is it designed for the hard- core , moderate, or mass-market audience? Will the game tap into multiple markets?

• Client platform ” This item includes the development platform and subsequent port platforms, if any. Is this designed strictly for the PC online audience, or will the game also be ported to one or more consoles? With both the Xbox and PlayStation 2 consoles now in the online game market in a big way, this can be a critical consideration, especially for a hybrid.

• Host platform ” What hardware and software will be used on the server side of the equation, including factors such as the physical machine configuration to be used, operating system and programming environment, database, anticipated peak simultaneous user load, number of server clusters/sets required, and anticipated bandwidth consumption per user and per server cluster?

• Licensed or original world ” Will the background of the game be a licensed world, as with Star Wars Galaxies , or an original concept, such as AC or Dark Age of Camelot ?

• Gameplay ” This is a description of the player's gameplay experience. Describe the key gameplay and player interface elements and what will differentiate your game from the competition.

• New player experience ” For a PW, a new player experience that makes the game's basic chat and game mechanics functions clear is absolutely critical. What will this game feature in the new player experience that will help train and hook players in the first few minutes of gameplay?

• Competition ” Are there similar projects on the market already or in the development stage? How will this game compete effectively against those other products? How much money are these other games making, and why will your game do as well or better?

• Staffing and qualifications ” How many people will the team need at the beginning, middle, and end of the development process, and in what specialties? What are the basic job descriptions and qualifications needed for each position?

• Core team ” Who are the producer/project manager, lead client programmer, lead server/network engineer, lead database designer/administrator, art director, and lead designer? Why are they qualified to develop this project?

• Schedule ” This is a preliminary estimate of the development and testing schedule. This will probably be completely bogus ; we've yet to see any kind of online game launch within six months of the proposed delivery date with even 80% of the feature set intact. However, executives want to be able to run preliminary figures on when they'll get a return on the investment, so you have to at least try. If you're a smart project manager/producer, you'll pad whatever estimate you make by at least six months.

• Budget ” This is a preliminary estimate of the total dollar cost to build this game and launch it. This should include at the least personnel salaries, software and hardware costs from start through testing to launch, and for a PW, the launch costs in terms of server hardware, bandwidth requirements, and network operations costs. If you can make a reasonable estimate of the CS/player relations costs, do it; far too many publishers have been taken by surprise here. It is rumored in the industry that the reason Take-Two dropped Wolfpack's Shadowbane in 2000/2001 was because management didn't realize until late in the process just how expensive it is to launch and host a PW game. You don't have to include marketing funds in here; the folks in executive row will do that. They should already know what it costs to market a Class AAA game.

While it will only take about two days to actually write the treatment, it will probably require between 50 and 100 hours to research it, especially the technology and competition portions. This document then goes to the executives in charge of approving or disapproving projects for development. If they are smart, they'll have a sanity check performed by knowledgeable people not connected with the project. This generally happens, but it makes one wonder why so many obvious non-starters get the go-ahead for a preliminary design document.

In case you're wondering: Yes, the treatment is often used to begin coding a prototype. Yes, this is a huge mistake. Development teams like to have a prototype running at the end of the design process to impress the executives, but this is just a waste of time and resources. So much is going to change during the preliminary design phase that a prototype doesn't make much sense, except to appease leads who would rather be coding than finishing a design.

The Preliminary Game Design

While this is called a "preliminary design," don't let that lull you into complacency; it should be approached in practice as driving toward a complete design document. Remember, the mantra is "design twice; build once." That means you actually have to finish what you think will be the final design, pass it around for comment, and then dig back into the document and make necessary changes, including rewriting the whole document, if necessary.

That sounds like a lot of work, and it is; designs for online games are hideously more complicated than standard retail solo-play home games. Solo games might involve 50 or 60 hours of gameplay, with some limited replay value; online games have to plan on keeping the player occupied for hundreds of hours (hybrids) to thousands of hours (PWs). ^[2] This means there has to be quite a bit of content in the game at release, plus plans to allow for content additions over time, post-launch .

^[2] Both Sony Online and EA claim the average weekly play hours of their subscribers for EQ and UO is approximately 12 “20. This amounts to a part-time job of 1,000 hours a year for the average player; the hard-core player in such games can easily rack up 40, 50, or even 60 hours per week.

If the core design team (producer/project manager, lead client programmer, lead server/network engineer, lead database designer/administrator, art director, CS manager, lead designer, and perhaps as many as two other designers at various points in the design process) doesn't spend at least three months on the preliminary design document, you can pretty much predict that there will be problems and delays during development, as elements missed in the short design phase become apparent and require fixing or rethinking. Experienced designers plan on at least a six-month design period to allow for two passes ("design twice") before development begins ("build once").

Why so much time? It has been proven by experience and any number of studies that spending more time on the design to finish a complete thought actually reduces development time. Go back to your experience with essay questions. If you took the time to do an outline, no matter how simple, you spent less time erasing and rewriting. The more detailed the outline, the more time saved. If you skipped school whenever there was an essay test given, go back and think about any product you have assembled . Maybe you could assemble it without the manual, diagram, schematic, list of instructions, and so forth, but you could always do it faster with the manual.

No one seriously disputes this as fact, so why do online game projects typically run 20 “25% over their development time? The two main culprits are inexperience and game developer culture, which don't generally include best-of-breed development practices, including concepts such as TQM or CCPs. Publishers are not without some responsibility either, of course. So far, they have underwritten a staggering amount of development costs. The more they learn, whether motivated by an interest in gaming and/or an aversion to losing money, the more they will insist on better development practices. In poker parlance, the publishers that learn sooner and better will not only collect more from their winning hands, but they will also fold their losing hands earlier.

If you've been involved in game development before, you know what a game design document is supposed to look like and you also know that such documents rarely get halfway done. At a minimum, this document should include the following:

• The background story ” The history of the world and why the player is supposed to be here

• Player interface design

• Character races and/or classes, with detailed notes on the differences between them, special abilities , or advantages

• Character creation and growth processes

• World locations and environments, including all natural and "man-made" types of terrain

• Full game mechanics, including magic, combat, trade skills, and any other appropriate mechanic

• Graphics style guide (the art bible)

• Full list of items and artifacts

• Non-player character (NPC) types and a list of NPCs and spawn points (if any) to be in the game

• Monster types and a list of monsters to be in the game

• Static quests (if any), detailed out

• Task lists ” All the tasks needed to build the game and how long each task should take, from the smallest piece of art to the largest script to be written by a designer

• Personnel lists ” The number of designers and artists that will be needed, and when they'll be needed

• First cut at the milestones, the deliverables for those milestones, and when they are to be delivered

• First cut of the overall development and launch budgets

This looks like a fairly short list, but there is a lot of detailed work involved. In fact, this list will (or should) generate a PW design document at least 200 pages in length, including the lists of objects, NPCs and monsters, buildings, and other artifacts. If the team has been thorough, the document will be in the neighborhood of 350 “400 pages in length. They'll still probably miss some things, but that's what the review process is for.

The Preliminary Technical Design

In conjunction with the design, your technology leads will be writing the technical design document. This can be either a completely separate document from the game design or included as part of it; it is done both ways in the industry and there seems to be no particular advantage to doing it one way or the other. The important thing is that it be complete.

Also note that this does not take place in a vacuum , apart from the game design; after all, this is a small team and the technology folks have to know what the designers want to do, to be able to tell them if it is even possible. The technical designers will spend a lot of time talking to the game designers before they put even one word on paper.

When technical designers do start writing, their portions of the documents should minimally include the following:

• Software ” The operating systems environment for both the client and server, programming and scripting languages, database program to be used (bought or built, and if built, what they'll start with), and graphics and modeling software to be used.

• Tools ” What tools are needed and whether they will be built, bought off-the-shelf, or repurposed from existing software. Tools include everything from world-building utilities to CS and in-game gamemaster (GM) powers.

• Game server, host farm configuration, and requirements ” This should include the number of physical machines per server cluster, memory and hard drive requirements per machine, how many subscribers each server cluster will be required to host, and the space needed to physically host the machines (if you're building your own network operations center [NOC] for the game).

• Bandwidth requirements ” How many bits per second will each player transmit, and the resulting bandwidth required by each server cluster.

• Task lists ” Every coding assignment in detail and how long each should take.

• Features list ” All interface and game mechanic features, listed in priority order.

• Personnel lists ” How many programmers, engineers , and database administrators will be needed, and at what times during the project.

• First cuts ” Rough estimates of the milestones, the deliverables for those milestones, and when they are to be delivered. Also, you need a first cut at the overall technical budget for development and launch.

• Prototype lists ” What elements will be included in the prototype and what is expected to be demonstrated in the proof of concept?

• Technical risks list ” What elements of the hardware or software could end up being blocks to development and cause delays and slips?

• The CCP ” How changes in the final game and technical design will be submitted, reviewed, approved, and implemented.

By the time the preliminary technical design is finished, it may end up being larger than the game design document. There are thousands of separate tasks to be tracked in a timeline/baseline document. These tasks can easily take up hundreds of pages in a project management chart constructed , for example, in Microsoft Project software. One Project document we recently looked at for art tasks for a role-playing game, for example, was over 200 pages by itself.

The Design Document Review

Now that you have the preliminary documents, what's next?

Most publishers have a design document review (DDR) team to perform a sanity check on projects. DDR team members are pulled from every department in the company to allow every department that will eventually be involved in the project (the stakeholders) to have some input and advance warning. Minimally, the DDR team should include an experienced producer or executive producer, a senior management executive such as the VP of Development, an experienced designer not assigned to the project, experienced client and server programmers, someone from Marketing and/or Press Relations, and representatives from Technical Support (both telephone and email), Player Relations, and Community Relations. Some publishers have separate teams for the game design and technical design reviews.

Once the design team has finished the preliminary design, copies go out to each member of the DDR team for review and comment. Members of the design team then meet with the various DDR team members to get clarification on any question or comment that is not clear. After that, there is also generally an all-day meeting between the DDR team and the game design team to go over the comments and allow the DDR team to ask more questions and get a clearer understanding of the scope and anticipated final outcome of the project.

The relationship between the design team and DDR team is often contentious, and DDR meetings have been known to grow hot. However, it is also a necessary process because teams not only often miss issues ”both subtle and obvious ”that heavily affect the other departments in the company, but they also sometimes miss gaping holes in their own game's mechanics, technology, or scheduling. You have to remember that design teams are close to their own work, and these games are some of the most complex software products in existence, so it can be easy for these issues to completely escape them. That doesn't mean design teams won't get mad at you when you point out flaws; designers get emotionally attached to their "babies." It comes with the territory.

This is also where you'll start to get an idea of what items on the features list may have to be trimmed to ensure the product ships in a reasonable time period. This is never easy for a design team; after a while, every feature becomes important and integral to the whole experience of the game. In truth, some features can't and shouldn't be trimmed , but design teams also have a nasty habit of letting "feature creep" take over. The whole reason for a prioritized features list is to make the design team complete their thoughts and, as a final option, to allow a producer or executive producer to mandate feature cuts, if he or she feels they are necessary.

For those teams working independently from a publisher, it makes sense to contract with experienced people to go over the design with a fine-toothed comb to isolate just these sorts of issues.

The "Final" Game and Technical Designs

Once the DDR process is complete, the design team holds a series of meetings to go over every comment and every page of the documents, line by line, deciding what changes need to be made and how each will affect the budget, task list, development baselines, and milestone deliverables. There will be meetings with individual stakeholders to discuss the questions and comments from the DDR in more depth and to do some horse-trading to reach a consensus.

It is easy to rush through this part of the process; developers want to get to developing, after all. It is important not to be impatient; take all comments into account and take the time to really put a final polish on the designs. If done correctly, this is the last time you'll have to do a major review of either; rush through it and your chances of ending up in the same boat as the products that experienced poor launches in 2001 are high. The team doesn't have to accept every recommended change, but it does need to give serious consideration to them and be able to adequately defend their decisions.

The other key element of the final design document process is honesty. No matter how emotionally attached to the work a team becomes, each individual on the team knows what concepts and features are truly do-able in the time allotted, which are innovative and worth a risk, and which simply are "neat stuff" everyone has always wanted to try. In a free multi-user dungeon (or MUD, which is usually a text-based Internet adventure game that may also have a hypertext markup language [HTML] or Java graphical component), massive experimentation is allowable ; in a for-pay game, innovation and risk have to be balanced with building a game the subscribers will pay for. No one really likes this tradeoff ; we'd all like to spend our days in constant experimentation because we want to push the genre forward faster. But with millions of dollars at stake, the people writing the checks expect a reasonable chance of getting their money back someday, and successes pay for further research and development.

So be honest about the tradeoffs. If you're a producer or executive producer, you must constantly remind the team of this and make the hard choices early.

The Second Design Review

Once the team has what it believes are the final versions of the documents, there is a second review process, similar to the first, but shorter in duration. If everyone did his or her job in the first review and asked the hard questions up-front and the design team was honest and patient about the tradeoffs and effective in consensus-building, the second review should go much more smoothly than the first one. There will be last-minute questions and some flaws will be found, but they should be handled easily.

The whole purpose of the second review, in fact, is to just make sure nothing important slipped past the first review and second design phase, and to reach a final consensus between the design team and the stakeholders that, yes, this is the game we're going to build.

The Final Polish

The final polish is simply that: fixing any last-minute flaws that were found in the second review process, making sure that any changes they caused in the budget, timeline, and task lists have been taken into account, and then sending the final documents around to the stakeholders for final sign-off.

For the design team, it is important that you get signatures from the stakeholders. It is not uncommon for questions or comments to pop up at this stage, regardless of whether a consensus was reached in previous stages. Just as you're willing to commit to building the game in the documents within the time and budget noted, you want the stakeholders to commit that, yes, they've read the document, made comments, and understand that this is the game that will be built. Not only is this an important part of the consensus-building process, you don't want stakeholders bothering you later on with questions that should have been raised during the design process.

For stakeholders, it is important to thoroughly read the design documents, understand the implications for your department, and commit to the work if you accept what those implications mean, in terms of work and resources for you and your people. Nothing ticks off developers more than to be submarined 18 months into development by a stakeholder who starts raising basic design feasibility questions.