Part II: Design and Development Considerations
Chapter 6. Basic Design and Development Issues
"These worlds are complex, revolve around communities, and require a lot of forethought. It's no longer about, 'Wow, wouldn't it be cool if…' but rather, 'So if we put this feature in, how would it affect long-term balance? Could players abuse it?' and so on. A good, experienced development team will know where the common pitfalls lie, and what precautions to take early on in the development process. Something as simple as having adequate
bandwidth and hardware on launch day is often overlooked by first-time developers."
—Daniel Manachi, The Themis Group
KEY TOPICS
Practicalities and Advice Design
Online game development teams are weird. Not disturbing weird, like some guy standing on a street corner arguing macro-economics with a fire hydrant. No, it's more like the weirdness of a lovable but dotty old aunt who can immediately take over and manage the extended family when her sister has been in an accident, but has trouble in the morning remembering how to tie her shoes.
The weirdness in development teams comes from the fact that they are pie-in-the-sky creatively and down-to-earth technologically. This tends to produce an effect not dissimilar to multiple personality disorder in an individual: Personality A is the fun, creative one who can design the most complicated, elegant game ever, while Personality B is pretty no-nonsense, task-oriented, and has the nuts and bolts of coding and hardware down to a tee. The problems come in when they fight for control of the body; most times, the fun, creative personality wins out, even if the matter is something Personality B should have control over. It is the age-old conflict between the theoretical and the practical.
This conflict is not readily apparent to outside observers, but it affects everything the team does throughout the development process.
Most developers, be they designers, coders, artists, or network specialists, enter the industry because making games is supposed to be a fun, creative activity. Like everything else in life, however, the nuts-and-bolts issues have to be attended to as well; as an industry, we just haven't been good enough Type-B personalities.
One of the common themes throughout this chapter is keeping the two personalities in harmony. Someone has to act as a rudder for the enormous creative energies of the team and must know when to steer them away from the theoretical and toward the practical. These energies are enormous; you'll rarely meet a visionless, incompetent online game development team. Often, though, you will meet teams poorly steered and constantly making emergency course corrections because they forgot to plot the sandbars on the navigation chart.
Someone has to keep things in balance between what co-author Bridgette Patrovsky calls the "esoteric, dream-state BS" that teams can get lost in and the need to actually get things planned, tasked, coded, drawn, and tested. The ultimate responsibility for that falls to both the producer and project manager, the former to keep the team balanced and the latter to keep the producer informed of just what state the development is in. We discussed the project manager in previous chapters; you'll learn more about the producer later on in this chapter.
This chapter will have two focuses: the theoretical (design) and the practical (development). There is plenty of room for movement and opinion in each. Technology discussions, especially, have a tendency to appear cut and dried, and there is always the temptation for an author to lay down what appears to be hard and fast recommendations for development tools, specific languages, operating
environments, and so forth. The plain fact is, this industry is still young, and while some good solutions for everyday problems do exist, every new game is different and probably will require a different solution set, especially persistent worlds (PWs).
So, to mangle an old saw, instead of trying to teach developers how to chew technical cheese, what we seek to do in this chapter is give some guidelines and let the reader know what has worked in the past with tools, design issues, and development processes, as well as what hasn't worked.
This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks.
[ Team LiB ]
[ Team LiB ]
Practicalities and Advice
"Most good products are designed around the person, not the technology."
—Donald A. Norman, author of The Invisible Computer, quoted in a Technology Review magazine article[1]
[1] See "Handhelds of Tomorrow" by Claire Tristram, Technology Review, April 2002.
For an industry with over 30 years of history and populated by some of the brightest people you'll ever meet, we sure seem to be unable to learn from the mistakes of others. There seems to be an almost emotional, arrogant need to reprise those mistakes, sometimes by the same teams on subsequent projects. A commonly heard refrain from developers is "<Insert feature here> hasn't worked yet because no one has done it right." So, even though non-consensual PvP combat (the player being attacked has no choice in the matter) has been shown in any number of games since 1988 to be extremely unpopular with over 80% of the player base of subscription-based online games, many new development teams plan it into their game on the theory that it just hasn't been done right in the past.
Considering that concept, we thought it would be useful to include advice from other people who have been there too, in the hopes that the information would sink in institutionally. We asked several experienced executives and developers the following question: In your experience, what mistakes do development teams make during the online game development process? The answers we received offered some excellent practical advice for anyone starting an online games project.
Richard A. Garriott, creator of the Ultima series and currently a principal at NCSoft in Austin, Texas:
Teams regularly bite off more than they can chew. An MMP can easily become an impossible-to-complete reality simulator.
Teams regularly hire on-paper game designers and/or solo player gamemakers, but MMPs need unique skills not found in other arenas.
Teams often cut corners in code expandability or general quality to try to make schedule. This usually haunts them later.
Companies often hire people too soon. A great deal of groundwork can be done before you need the majority of the staff.
Gordon Walton, executive producer for The Sims Online for EA/Maxis:
They don't build for the long term, that is, they don't make the code extensible and maintainable. The live team pays for this for years and the game's financial potential is reduced.
They don't focus enough on quality of service, especially mean time between failure (MTBF) metrics. Failures in the servers deny service to thousands of people, and failures in the client irritate players, raising churn.
They underestimate the complexity of the task. More moving parts drive complexity nonlinearly, and MMP games have a lot of moving parts. Rule of thumb: An MMP game is three times bigger than a standalone game, but 10 times harder to complete.
They underestimate the testing and scaling challenges and end up with a fire drill when their service scales up.
They overestimate the value of the initial game content and overestimate how long it will take the players to consume it.
They forget that some design ideas don't work well within the MMP arena, particularly static puzzles and fixed-content discovery elements. These elements end up on player web sites within days of launch, reducing the value of that part of the game for most other players.
They spend more time on game mechanics than social mechanics. This makes it harder for players to find and play with each other, which doesn't help retention and churn at all.
This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks.
They forget to bring customer service (CS) in as an equal partner in design and development. Thus, customer satisfaction is lower, and the game is much more expensive to run.
They think they are just building a game (rather than a social venue with gaming elements).
Thomas Howalt, project manager of Funcom's Anarchy Online (AO):
Confidence is good, but control is better.
As stated earlier, an online game is a huge task, and it is very easy to lose track. Check everything thoroughly again and again. Do not accept promises; you have to keep track of everything.
Problems don't solve themselves.
Personnel conflicts have to be dealt with quick and clean. Do not accept discrepancies to pester the atmosphere. Conflict can be valuable if managed well; tension can be fruitful if managed well. It all depends on how mature your team is. Remember:
Moss does not grow on rolling stones! Make 'em rock 'n roll!
Everything moves.
Everything in the game may have to change. Be careful what you hard-code.
Repeat after me, please: "Tools! Tools! And more Tools."
You will need tools for everything! Hire lots of tools and library coders. Use money to develop brilliant tools. Make decent and efficient graphical user interfaces, or GUIs. And, force the coders to work with their own tools before they ask anyone else to work with them.
Mountain high, river deep.
Be aware when the "stars" appear. The closer you get to launch, the more need Marketing will have for someone who knows the game and is good at talking marketing-type talk. To all you "stars": Fame is very addictive, but keep your feet on the ground and stay humble! Tomorrow you will be forgotten; that's the way fame works—it does not last. And remember: It is a team effort!
Alex Macris, CEO of The Themis Group and designer of Spearhead:
They focus too much on excitement (gameplay) and too little on involvement (the community). Within six months of playing 20 hours per week, any player will find your gameplay boring, period. There is nothing you can do that can make your gameplay more interesting than that of a brand new AAA title coming out six months or a year or two years after your title. But if you have him in the thrall of your community, he'll stay.
Everyone talks about the addictiveness of EverQuest's gameplay, likening it to a slot machine, but they lose sight of the meta-game that overlays EQ and that makes the achievements meaningful. And I think future games will have a difficult time in succeeding with an EQ-style approach because they won't enjoy the network effects that come from being the biggest game.
They focus too much on content and too little on features. Content can be successfully added over time (as Asheron's Call proved). Features are far harder to add. The number of game mechanics is a lot more interesting than the number of dungeons.
Andre Backen, former president of Funcom:
The single biggest mistake we make is to overestimate what we are able to get done in a certain amount of time.
Jeff Anderson, CEO, Turbine Entertainment:
The worst thing I have seen repeatedly is a lack of focus. The teams feel compelled to engage in what I like to call
"competitivism." Before I was making online games, I worked for a company that made combat flight sims. I noticed that the focus of those games changed from what was "fun" for the general audience to what they have to have on the back of the box "to be competitive." So instead of spending their precious development time innovating, they worried about the physics on the F-22, or making sure they had the latest laser-guided bombs. Maybe it made for an easy marketing angle ("We've got
that!"), but it made lousy gameplay. You see a lot of that in the online space already; fervor to make sure that my game hits some kind of feature list—even before there is an idea of what makes the game fun.
Damion Schubert, founder of Ninjaneering and former lead designer of UO2 and M59:
A mistake that I've seen a lot of in the MMP space is a concept I call "ant farming." This is when developers start to envision cool experiments that would be fun to observe from the heavens—but may not be terribly fun for the player base. Usually, these experiments involve ways that players can take advantage of other players' lack of knowledge, experience, or common sense. Developers usually have great defenses for these features, such as "interesting emergent behavior," "case studies in trust," or "fascinating guild tactics," but frequently what they really turn out to be are support nightmares and retention killers.
[ Team LiB ]
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.
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.