How to Make Virtual Worlds
Theory and Practice
Virtual worlds are implemented using complicated pieces of software, but, contrary to what many developers would like to believe, they are by no means the most sophisticated programs in existence. Modern operating systems comfortably beat them, and they're dwarfed by major projects, such as air traffic control networks. When you read the following, therefore, remember that it could all be much, much worse.
This book is written from the perspective of a virtual world designer. The fun part of design is the creativity; the boring part is what you have to learn to inform the creative process. It's not surprising that many designers therefore omit this step. This is a Bad Thing. It is not enough to have played or even coded other virtual worlds; to do a good job, you have to understand how they work. For example, a college student putting together a textual virtual world might try out different codebases to see which is the most appropriate. Well yes, that sounds only sensible. However, it would be like someone who knows how to drive taking a selection of cars for a spin before deciding which to use as the basis for designing a car of their own. There is more to designing cars than finding something that suits your driving style; there is more to designing virtual worlds than finding something that suits your playing style. Before you can make a start you need to be aware of how virtual worlds function, what the components are, how they fit together, what can go wrong, and a whole host of other things.
A student building a virtual world from a kit has the excuse that in doing so they might actually learn some of the important design principles involved. The student's next world will consequently be much improved. Professional virtual world designers can fall back on no such justification. There are some things that they simply ought to know beforehand, whether they want to or not.
It's this background knowledge that this chapter is intended to impart.
Design is just one part of creating a virtual world. Designers like to think it's the most important part, but is it?
Designers have wild, airy-fairy imaginings.
Programmers do the actual work of building the virtual world.
Artists are the magicians who imbue it with form.
Sound engineers determine the moods and emotions.
Operations staffs are the engineers who keep it running.
Producers provide the resources.
Anyone can have wild imaginings. Only people with specialist skills can program, or draw, or compose, or run networks, or manage a project. Why are designers so important?
Because, if a designer screws up, the consequences for the virtual world can be devastating.
A piece of code that doesn't work may be hard to track down, but once discovered it's usually easy to correct. An odd-looking yet crucial texture may need to be painstakingly redrawn, but it's still only a single bitmap. However, if a designer makes a seemingly minor misjudgment, the effects could be so pervasive that they might paralyze a world for weeks.
If you find that hard to believe, consider a virtual world in which non-player shopkeepers sell goods at fixed prices. What happens if there is inflation in this virtual economy? Pretty soon, you can have whatever you want for peanuts. What happens if there's deflation? Even trivial items cost so much that only the very rich can afford them. What factors affect inflation/deflation? Oh, just about all of themin hideously intertwined ways as determined by the actions of the designer.
Broken economies are not pretty. At one point, Asheron's Call's currency became so worthless that players had to barter if they wanted to acquire goods from one another. This went on for months before it was finally brought under control; the debacle cost AC dearly.
So, that's why design is the most important thing about creating virtual worldsit has the highest price of failure.
Design might be the most important cog in the machine that creates virtual worlds, but that isn't to say the other components are unimportant. Some are absolutely critical: If a server crashes, for example, every minute it stays down will be paid for in cancelled accounts. Designers have to know about these things, so they can account for them in their virtual world design.
Designers should have not only a realistic idea of their own place in the system, but also a sound knowledge of the roles of the other people involved in the creation process. Composers don't have to know how to play every instrument in an orchestra, but it's essential that they know how all the instruments sound; designers can't be expected to know how programmers or artists do what they do, but they must be aware of any limitations. If you want every wall of your virtual palace to have a stunning, original fresco on it, you can think again.
To create a virtual world is to create a piece of software. That's not all it is, of courseit's creating a community, a service, a placebut these count for little if there isn't an engine to run the world.
A typical software engineering company is organized along functional lines that cover the following areas:
Sales and marketing
Finance and accounting
Software development, support, and quality assurance (QA)
Operations and information technology (IT)
Human resources (HR)
Some of these may be split into separate sections, for example sales might be distinct from marketing; on the whole, though, the preceding list is fairly uncontentious. Note that normally there is no specific group responsible solely for product specification; the task falls to whoever sources the software, which in many cases could well be the customer.
A typical computer games development company is organized in much the same way, but with some games-specific differences:
An art and animation section is added.
An audio (music, sound effects) section is added (unless outsourced).
QA is expanded, and is formally separated from actual software development.
A (usually small) design group is added; its members will be paid less, but get more fan kudos, than their coworkers.
For developers of massively multiplayer, graphical virtual worlds, the games development model is used except:
The design group is expanded.
The operations group (which maintains and supports the hardware on which the system will run) is expanded.
The support group (which deals with players, both inside and outside the virtual world) is greatly expanded, and is formally separated from actual software development. It will usually reabsorb the QA section.
Designers are only occasionally bothered by the company leadership, HR, IT, and finance/accounting people. They have a dialogue with sales/marketing that may be in balance or lopsided ("This is the kind of world we want you to design" versus "This is the kind of world we want you to sell"1). They tell the operations, artwork, and audio experts what needs to be done, but generally leave them to it. They interact mostly with
The programmers (because designers are never specific enough about what they want, except when they're so enthusiastic that they try to tell the programmers how to program2).
QA (because testers spot more design flaws than they do programming bugs and operations problems).
Support (because players spot more design flaws than QA people).
Each other (because although this book keeps referring to "the designer" of a virtual world, there's usually a design team, led by a lead designer).
When work on a new virtual world begins, a core team is assembled. For a small world, this could be a single individual performing multiple tasks; indeed, it might never get any bigger. For a large-scale world, though, it is merely the nucleus about which a full-blown development effort will form. A core team consists of the
Lead programmer(s) (server, client)
Lead artist(s) (environment, inhabitants/characters)
There may be two lead programmers because client programming is something best done by people with a background in computer games development, whereas server programming is best done by people with a background in software engineering. Programming is becoming a progressively more specialized field, and programmers expert in one area may need training to work in another.
There may be two lead artists because of the sheer quantity of artwork involved in a graphical virtual world (albeit not when development first starts). Strictly speaking, the "environment artist" is in charge of the concept artdefining the look of the virtual world. The "characters artist" is in charge of the technical sideinterfacing with the programmers. Because this usually comes down to issues of animation, that's why they wind up being responsible for characters.
Increasingly, operations and customer service leads are being brought in to the core team, but because their work cannot begin until some time into the development process it's unusual if this occurs in a start-up company.
The Development Process
There are many steps to the development of a virtual world. For smaller worlds with fewer players and different functionality, some steps can be skipped or done in tandem with other steps. To highlight every aspect of the process, however, the description in this chapter is for a large, graphical world. Luckily, designers don't need to know every detail of thisthat's the job of the producerbut they do need to have an idea of how it breaks down. Therefore, you'll be relieved to learn that only an overview will be presented here, rather than a how-to guide. If you want to find out more (and to understand why it is that producers are paid twice as much as designers), consult Developing Online Games: An Insider's Guide3 by Bridgette Patrovsky and Jessica Mulligan (for virtual worlds) or Game Architecture and Design4 by Andrew Rollings and Dave Morris (for games in general).
The development of online games has four distinct phases:
Let's look at these in turn.
Pre-production can last as long as six months. The aim is to do all the concept evaluation and project planning necessary to reduce risk in the later stages of development. It's undertaken by members of the core team, in close consultation with one another. In many ways, it's the most exciting part of the project, but it's usually done under time pressure with inadequate resources available, which rather dulls the edge. In particular, a number of important deliverables will have been prepared by the end, all of which will almost certainly have needed more work on them than they actually received.
These deliverables are
A visualization document. This is produced first, by the lead designer. Although only a few pages long, it sets the tone for the entire endeavor, asserting the project's mission statement, its philosophy, its goals, its main features, and its look and feel.
A design document. Because the designer(s) creates this, I spend much of Chapters 3 through 5 of this book addressing the kind of material that goes into it. For the moment, though, suffice to say it defines things such as the world's background, its architecture, its mechanics (including gameplay), its control mechanisms (how players interact with it), and its integral community support systems5. Specifics will be added constantly as development continues.
A technical design review, assessing hardware and software requirements. What technologies are needed? What tools (both bespoke and middleware)? The technical design review is often folded into the design document.
An art bible, describing the stylistic conventions to be used along with examples illustrating the range of material required. This is so that artists can produce work that is consistent with a single overall look6.
A production management assessment, which uses the other deliverables to gauge the project's demands. It will include a schedule (with milestones), resource requirement details and some risk assessment. The schedule will be continually updated in the light of how things actually proceed, as opposed to how they're supposed to proceed.
Prototypes to provide proof of concept and to show that potential technical difficulties can be overcome.
Pre-production is primarily a planning phase, therefore the construction of (limited) prototypes might seem to be out of place. Prototypes are necessary partly for commercial reasonsthey demonstrate to investors that the team can produce the goodsbut they also benefit the team itself. They ensure standards for design, programming, and art have been set, and that source control works. They show that the basic principles will work, and (hopefully) can be integrated. For companies that produce a steady stream of material for different projects, assembly line style, the basic pathways for communicating with the various production centers will also have been tested.
The technical design review addresses basic issues, such as how the server code will be modularized, what network transport layer protocols will be used (TCP/IP versus UDP), how background content will be trickled to clients, and how multiple access options will be incorporated (PC/console, web browser, mobile phone). Additionally, it has to consider topics not directly related to the virtual world at all, primarily back-end systems for login, billing, and so on. The necessary software development tools (including ones for system testing and debugging) must be acquired at this stage, in addition to as many pieces of middleware as are suitable. In particular, even with the typically huge license fees involved, it is usually more cost-effective for a company to buy a database, 3D engine, and billing system than to write its own from first principles7.
Whether or not you can acquire useful middleware for world creation and AI scripting is project-dependent, however, because it requires great flexibility. Developers usually like to have their own tame programmers available to make any necessary changes expediently, rather than having to rely on someone else's people to do so at short notice.
The production management assessment covers a wider brief than its name might suggest. The term comes from the computer games industry, where typical products don't need a great deal of support after they hit the stores; their management assessment therefore only needs to cover production. Virtual worlds (whether or not games) do, however, need to be managed after launchimmensely so! The production management assessment for them must also extend through the rollout and into the operation phase. This means it has to consider things such as quality assurance, live team management, community maintenance, content creation, and patching. It's also the place where the battle with the Marketing department starts over the handling of the product's launch.
The production phase8, which lasts between two and three years9 for a large, commercial virtual world, is when the bulk of the programming and data creation takes place. Code must be produced for the client, the server, and for tools. It all has to be done in order, according to a production schedule10 set by the producer. Tools are usually written first, because other activities are dependent on them and because some of the code can usually be re-used for the server or client. Tools are required for things such as world generation, artificial intelligence (AI) scripting, and customer service support. It's also a good idea to build some analysis tools, too, so that once the world is running it will be possible to determine what the players, the software, and the hardware are doing without having to ask.
The amount of server-side code needed depends on the chosen architecture. It includes driver functionality at the level of LAN networking (to connect the server to its peers) and communications modules (to connect the server cluster to the Internet). It usually includes a mudlib layer, to support the world physics and AI system. Whether it includes a world model layer depends on what the scripting tools produce. If it is to run in multiple incarnations, it will not include any instantiation-specific detail (it would be too hard to make general updates otherwise).
The client-side code will be the home of a major 3D engine plus support for music and audio effects. Communications protocols to connect with the server are obviously necessary, as are software update mechanisms for when the client needs patching (which is an inevitability).
While the programmers are busy programming, the artists are busy creating object models (static and animated) and texture maps, along with other miscellaneous images (for example, for manuals, intro movies, and web sites). The volume of artwork required is so high that it will normally be stored in its own database so that the artists can keep track of it all. Scalability and maintainability issues also arise for graphics11.
The world itself is constructed using the building tools that the programmers have created, to the specifications of the design document. There is a fair degree of creative freedom involved in this activity12, which is why specialist designers usually undertake it rather than programmers; it's analogous to the way that animation is generally done by artists, even though programmers created the necessary tools.
Roll out is the most critical phase of development, when all the technologies and assets created are brought together to form a virtual world experience. It formally begins with the open beta (test), but has its roots much earlier in the development process.
Testing takes place all the way through development, of course. Programmers will test individual pieces of code, animators will test animations, even designers will run data through models to ensure that what they think will happen has a good chance of being what will happen after players are let loose in their handsome creation.
When enough of a virtual world is available as an integral environment, a test server can be set up and alpha testing can begin. This is undertaken by the designers, programmers, and artists themselves, looking for bugs mainly in their own areas of responsibility but also reporting anything else they discover that seems Somehow Wrong. Around now, enlightened developers might invite independent design consultants to take a look, but most aren't enlightened and don't. Folks, the opinions of knowledgeable people from outside the team who haven't been living and breathing it for two years are worth having, and worth paying to have. Of course, this does also assume that you'll listen to what they say rather than simply check the "hire consultant" box on the production schedule then move on.
Alpha testing is also the stage at which trained customer support staff can begin their learning process, subjecting the virtual world to the kind of punishment that real players are likely to mete out as they do so.
QA specialists may be brought in (externally or from elsewhere in the company) to perform platform testingseeing whether the client runs on a representative variety of home computer configurationsbut they won't hang around afterwards as virtual worlds are typically much greater in scope than regular computer games and take longer to play through. Given that customer service representatives need to have an in-depth knowledge of the virtual world anyway, it makes sense to provide them with enough QA training that they can perform this task instead, while building their playing skills.
During alpha testing, anything and everything goes as bugs are found, fixed, and their solutions reintegrated into the whole. Eventually, however (hopefully at a point previously scheduled by the producer), the world is stable enough to allow people into it who are not directly involved in the development process. In other words, players.
Initially, only a few outsiders are allowed into the virtual world. The first ones will be those the developers specifically ask to play, either because they are friends13 or because they are influential yet responsible (or sounded that way on the community message boards). A few others will be signed up from a general call for play-testers, so as to disguise the fact that most of their peers get in through the back door. Thus begins beta testing.
At this stage, it's a closed beta, because the world is invitation-only. As stability increases, player numbers can be gradually increased by letting in more wannabes from the general call (a technique known as ramping). When the barriers are lifted high enough that the testers begin acting like real players, the world is said to be in live beta; this may or may not coincide with the moment the world is officially opened up to all-comers for stress-testingthat is, when it enters open beta. Because this final stage of testing marks the point of no return, this is when the roll out truly begins.
Usually, computer games go into beta testing as late as possible. Virtual worlds, not really being computer games (despite what many of their developers seem to think), go into beta testing as early as possible. This allows for bugs and exploits to be discovered well before paying customers can leave over them, all the while forging strong community bonds between the beta testers. Some of these people may even come up with decent ideas for improvements14.
Roll out ends after the launch, when its legacy is passed to the marketing department (which will have had considerable involvement in it already). Later expansion modules may have their own roll outs, of course, as they do the other phases of development.
To summarize, the aim of the roll out period is to launch a virtual world with
A seeded community
A primed market
All but the last of these are possible.
The operation phase15 begins when people start paying to enter the virtual world. It ends when people stop paying, or when the resources needed to support them would be better employed (that is, make more money) elsewhere.
During the operation phase, the original design and development team (the dev team) typically hands over control to a new set of developers (the live team). The rationale is that the battle-hardened dev team can move on to other projects (say, creating the next expansion), leaving the less experienced live team responsible for the maintenance and long-term improvement of the virtual world. This is not always the case, however; Dark Age of Camelot, for example, retained its dev team for the operation phase, rather than putting the very people who knew the project best to work elsewhere.
So what exactly does a live team do? Its tasks include the following:
Customer and community support.
Network and technical support.
Feature development and enhancement.
Maintaining overall quality of gameplay in response to player cunning.
Keeping in step with technology (for example, new platforms, new video cards).
Occasionally, marketing (the virtual world and its intellectual properties).
The size of the development team for a commercial virtual world varies; generally speaking, the further into the project, the more people are involved. Although some companies may claim that they can produce a world capable of handling 100,000 players with only a designer, a programmer, and a clip art package, the reality is somewhat different. As a rough idea, a year or so into the production phase there will typically be around 30 people in the dev team split 5:10:15 for designers, programmers, and artists/animators.
Why mention this now? Because the live team will be three to four times larger than the dev team! It'll have similar numbers of designers and programmers (maybe fewer artists16), but add a hundred or more people in customer and community support.
For virtual worlds, the work only really begins at the operation phase. Time and time again, this is something that developers fail to understandespecially if they have long-time exposure to the fire-and-forget approach of the regular computer games industry. Virtual worlds, despite their origins, are not regular computer gamesor necessarily any kind of game at all (what they are instead is discussed in Chapter 6, "It's Not a Game, It's a...").