Introduction to Virtual Worlds

What are virtual worlds? In this context, a world is an environment that its inhabitants regard as being self-contained. It doesn’t have to mean an entire planet: It’s used in the same sense as “the Roman world” or “the world of high finance.”

So what about the virtual part? Not to get too philosophical about it:

• Real: That which is.

• Imaginary: That which isn’t.

• Virtual: That which isn’t, having the form or effect of that which is.

Virtual worlds are places where the imaginary meets the real.

Some Definitions

A computer implements virtual worlds (or network of computers) that simulate an environment. Some—but not all—the entities in this environment act under the direct control of individual people. Because several such people can affect the same environment simultaneously, the world is said to be shared or multi-user. The environment continues to exist and develop internally (at least to some degree) even when there are no people interacting with it; this means it is persistent.

Although virtual worlds now have many applications beyond that of being mere entertainment products, they began as computer games; furthermore—perhaps because of the large sums of money involved in their creation and the guaranteed huge monthly incomes they can generate—computer games remain at the cutting edge of virtual world development.

For these reasons, much of the vocabulary commonly used to describe virtual worlds is games-based. Thus, the human beings who interact with the simulated environment are known as players rather than users; the means by which the environment introduces goals for the players is called gameplay; the activity of interacting with the environment is referred to as playing.

Specialists may adopt a different vocabulary that is formal for their particular area of expertise, for example a cultural anthropologist might prefer to talk of “individuals” exhibiting “behaviors” in response to “pressures;” however, for any broader discussion of the subject the dominance of game-oriented terminology is impossible to resist, and it is therefore the one that shall be used here.

The exception is the very term “virtual world” itself. Over the years, a number of words, phrases, and contrived acronyms have been used to describe these projected milieus, none of which have been entirely successful. For reasons that will be explained shortly, virtual worlds were originally known as Multi-User Dungeons (MUDs).

Although this term is still in common currency to the extent that it has made it into several regular dictionaries, it is not universally accepted. In particular, many players of certain of its subcategories see it as implying some kind of combat-oriented world view, and prefer the term MU* instead (MU for Multi-User and * for anything that could conceivably follow).

This would be analogous to calling dinosaurs *saurs on the grounds that “dinosaurs” vaguely implies ¹ that they were all pea-brained carnivorous monsters, whereas in fact many were pea-brained herbivorous monsters—and hey, there are pterosaurs and plesiosaurs, too.

The first virtual worlds were text-based, in that their environments and the events occurring within them were described using words rather than images. Confusingly, although the term MUD applies to virtual worlds in general, the term MU* does not—it’s used strictly for text-based worlds. The introduction of computer graphics into the mix therefore caused a second spate of naming, in order to make a distinction between graphical MUDs and text MUDs. At first the new games were called persistent worlds, but when the enormous numbers of simultaneous players they were attracting became their defining feature this changed to MMORPGs (Massively-Multiplayer Online Role-Playing Games). Said acronym dominates at present, but it is rarely used with enthusiasm (not least because it’s unpronounceable) and it is therefore likely to be abandoned the instant some viable alternative emerges.

Although, properly, all these persistent, shared, computer-moderated environments can and should be referred to as MUDs, the term is sufficiently loaded that outside the cognoscenti it is unlikely to be universally interpreted this way. Enough people think that MUDs are a mere category of MU*s (rather than the reverse) for it to be confusing. Therefore, this book prefers the more descriptive and less emotive “virtual worlds” as an alternative.

It is important to note that virtual worlds are not the same as virtual reality (VR), which has a much more specific meaning. Virtual reality is primarily concerned with the mechanisms by which human beings can interact with computer simulations; it is not especially bothered by the nature of the simulations themselves. People who visit virtual worlds may some day benefit from research into visors, data gloves, and beyond, but the fundamental attraction for them is what awaits when they enter a virtual world, not the means by which they do so.

What They Are and Whence They Came

Although more abstract versions can, and do, exist, most virtual worlds adhere to certain conventions that distinguish them from related non-real spaces. The most important of these are:

• The world has underlying, automated rules that enable players to effect changes to it (although not to the rules that grant them this ability). This is the world’s physics.

• Players represent individuals “in” the world. They may wield partial or total influence over an army, crew or party, but there is only one game entity that represents them in the world and with which they strongly identify. This is their character. All interaction with the world and other players is channeled through characters.

• Interaction with the world takes place in real time. When you do something in the world, you can expect feedback almost immediately.

• The world is shared.

• The world is (at least to some degree) persistent.

A chat room would not be a virtual world because it has no physics; a strategic wargame doesn’t map the player onto a single character through which that player acts; a play-by-email game doesn’t run in real time; a single-player game is not shared; a first-person shooter isn’t persistent.

For some examples, the case is not so clear-cut. Are tabletop role-playing games virtual worlds, for example? No, because they’re not automated, but it’s a close call. Would a two-player educational MUD be a virtual world? Probably. Would a 500-player game with a world so vast that the players could never find each other? Yes, but under protest.

In practice, it’s fairly easy to determine what is or isn’t a virtual world simply by looking at its heritage. If its design draws heavily from the design of an existing virtual world, it almost certainly is one; if it doesn’t, it almost certainly isn’t.

The First Age: 1978–1985

Virtual worlds are often called MUDs because MUD was the name of the first one to prosper. Although earlier games had been written that might today be described as virtual worlds, they were seeds that fell on stony ground. MUD, by contrast, grew to produce seeds of its own.

MUD was programmed in MACRO-10 assembler on a DecSystem-10 mainframe at Essex University, England, in the fall of 1978. Its author was a talented Computer Science undergraduate, Roy Trubshaw. Version I was a simple test program to establish the basic principles by which a shared world could be maintained. When it worked, Roy immediately started on version II, a text-based virtual world that would be instantly recognizable as such even today. It was also written in MACRO-10, a decision that led to its becoming increasingly unwieldy as more and more features were added. Because of this, in the fall of 1979 Roy made the decision to begin work on version III of the game. He split it in two: The game engine was written in BCPL (the fore-runner of C); the game world was written in a language of his own devising, MUDDL (Multi-User Dungeon Definition Language). The idea was that multiple worlds could be constructed in MUDDL but would run on the same, unmodified engine (which was effectively an interpreter).

Roy had a basic working program by Easter 1980, but it only amounted to a fraction of what he envisaged. This being the final year of his degree, he realized that he did not have time to complete the project. Someone else would have to do it.

From the beginning, Roy had been open to suggestions from his friends as to how MUD could be extended and improved. Most of these ideas came from fellow undergraduates Richard Bartle (that’s me) and Nigel Roberts. Unlike Nigel, I was younger than Roy and did not have to leave the university for another year (in fact, I was to stay until 1989; first as a postgraduate and then as a lecturer). Luckily, I was also a first-class programmer and had a strong background in gaming. Roy therefore passed MUD on to me, and I subsequently wrote the remainder of the engine and nearly all the world to produce what became the paradigm for the entire genre. That’s enough blowing my own trumpet, you’ll be relieved to know.

Roy had two motivations to write MUD. First, he had enjoyed single-player adventure games (Crowther and Woods’ ADVENT; Anderson, Blank, Daniels, and Lebling’s ZORK; Laird’s HAUNT) and liked the idea of creating a multiplayer game along those lines. Secondly, he had a strong academic interest in writing programming language parsers and interpreters. The two came together when he discovered a means of sharing write-enabled areas of memory on the DEC-10 mainframe and mused on its potential uses.

The “D” in MUD stands for “Dungeon.” Contrary to what many people assume, this has nothing to do with the role-playing game Dungeons & Dragons and does not mean that the game world had a dungeon setting ¹. Instead, it is due to the fact that the version of ZORK Roy played was a Fortran port called DUNGEN ². Roy wanted something that was like a multi-user DUNGE (o) N, and the acronym MUD immediately presented itself.

Essex University is a mere 45 minutes by road from the main (what was then the Post Office, but is now) British Telecom research facility, located at Martlesham Heath near Ipswich. This caused the university to be selected to pilot a new, experimental packet-switching service called EPSS. Among other things, EPSS allowed contact to and from the ARPA (Advanced Research Project Agency) net in the United States. Roy could therefore tell people in the U.S. about MUD, and some of them came to try it out ³. The ARPA net eventually evolved to become what is known today as the Internet.

Nevertheless, MUD remained a mainly Essex University phenomenon in its formative years, existing primarily because of the largesse of the Computer Services team and their manager, Charles Bowman. In the teeth of complaints about wasted resources, members of the university’s Computer Society were allowed to spend off-peak time doing anything non-academic they liked. Many of them chose to play MUD.

Some, however, were inspired to write their own games in MUDDL for use with the MUD engine. There were a number of these, of which the pre-eminent were ROCK (based on TV’s Fraggle Rock Muppet show), MIST (original and anarchic), BLUD (original and bloody), and UNI (the Computer Science Department as a sword-and-sorcery virtual world).

Besides its EPSS connections, Essex University also had a number of modems for dial-up use. News of MUD reached the UK’s small community of BBS (bulletin board system) users, and they obtained permission to play the game by direct dial—just as long as they did so at times when any sane person would have been in bed for two hours. This they did, and demand grew so much that that they clubbed together and bought the university some extra modems so it could cope!

Network uptake increased, and eventually all UK universities were connected to a system called JANet (Joint Academic Network). EPSS ceased to be experimental and became PSS, which enabled people with access to either company PSS accounts or substantial amounts of money to connect to the university’s computer systems in yet greater numbers. In 1984–85, there were articles on MUD in practically all the specialist computer games magazines in the UK. The floodgates opened.

The MUD engine had its limits. It could hold a maximum of 36 players at once ⁴, and if more wanted to play, a second game would have to be cranked up to supersede the first. Furthermore, it only ran on a DEC-10, and although copies were sent to other institutions in the UK, Sweden, and Norway, only two of these allowed outsiders access (Dundee Technical College and Oslo University).

While Roy was still working on version II of MUD, another student at Essex University, Stephen Murrell, had written from scratch his own virtual world using a different means of handling inter-player communication (that of assigning devices). His game, PIGG, was also written in MACRO-10 and eventually ran into the same maintainability problems as MUD. Nevertheless, the precedent was set. A number of external players of MUD became inspired, or frustrated enough by it, to set about writing their own games.

The Second Age: 1985–1989

The first such virtual worlds to appear were Neil Newell’s Shades, Ben Laurie’s Gods, and AMP ¹. They were followed shortly by Pip Cordrey, et al’s very active MirrorWorld. As these games were all derived from MUD, they became collectively referred to as “MUDs” or, occasionally, “MUGs” (Multi-User Games). The original MUD was dubbed MUD1 (even though it was in its third version) to disambiguate it from the class of MUDs. This marked the beginning of the second age of virtual worlds.

The possibility of making money from these games arose, so MUD1 went live both on the dominant U.S. online service of the time, CompuServe, and a UK look-alike, CompuNet. A programmer at CompuNet, Alan Lenton, was moved to write his own virtual world, Federation II, which has the distinction of being the first MUD to have a non-Fantasy setting (it was Science Fiction).

MUD1, Federation II, Shades (on the Prestel Micronet teletext system), and Gods (in a German translation) went on to achieve commercial success. Scores of other MUDs were created in the UK, written mainly by players of the Big Four. It was a time of great experimentation in both game world and game engine design, with much original work coming from the MirrorWorld group on their IOWA (Input/Output World of Adventure) system ².

Around this time, the decision was made to rewrite MUD1 from scratch as MUD2 (although it was actually version IV). The original architecture and its DEC-10 platform had proved too limiting, and MUDDL (which owed much to the database definition scheme employed by ADVENT) was not sufficiently powerful to handle advanced concepts. A new language, MUDDLE (Multi-User Dungeon Definition LanguagE), was developed from first principles specifically for writing MUDs. It turned out to be expressive enough to stand the test of time, and this was therefore the last occasion on which the game MUD was to be rewritten in its entirety.

Virtually all the key issues of virtual world design were identified in the first and second ages. By 1987, for example, all the protocols and in-game tools for dealing with player problems were in place and reasonably well codified, thanks to the pioneering efforts of people like Mark Longley (MUD1), Michael Lawrie (MIST), and Pip Cordrey (MirrorWorld). Sadly, however, this kind of knowledge was not passed on in its entirety. Developers of descendant games usually knew what they ought to have, but not necessarily why they ought to have it, with the result that after several generations a number of important concepts had been forgotten.

Games that were launched 10 years later, therefore, had to rediscover some of the fundamentals the hard way.

Most of the MUDs that were written in the second age were programmed by enthusiasts at home ³. At this time (but not for much longer), single-player text adventures were a very important part of the computer game market, so there were plenty of people who understood the principles. Because few academic institutions in the UK were as liberal with their computer resources as Essex University, those MUDs that were written at such places tended to achieve only local success.

The exception was AberMUD, so called because it was written at the University of Wales at Aberystwyth. Its programmer, Alan Cox, wrote it in B (another fore-runner of C) for a Honeywell L66 mainframe under GCOS3/TSS in 1987. A year later, it was ported to C. This was a turning point in virtual world history. The game wasn’t particularly advanced either technologically or in terms of content (it was very combat-oriented), but it was great fun. More importantly, in C it was positioned to make a huge advance: It could run under Unix.

The Third Age: 1989–1995

AberMUD spread across university computer science departments like a virus. Identical copies (or incarnations) appeared on thousands of Unix machines. It went through four versions in rapid succession, spawning several imitators. The three most important of these were TinyMUD, LPMUD, and DikuMUD.

TinyMUD, by Jim Aspnes at Carnegie Mellon University, arrived in 1989. It had two main ancestors: AberMUD, and a VAX VMS game called Monster that had been released a year earlier. Monster (by Rich Skrenta at Northwestern University) was unusual in that it was written independently of the general MUD1 hierarchy. Its main innovation was the facility to create elements of the virtual world from within the world itself. This was something that had been removed from MUD1 in the switch from version II to version III.

TinyMUD was basically a stripped-down version of Monster. Although still a virtual world, it had practically no “game” aspect to it at all. Players could create new locations and objects (but not much functionality) almost with impunity. Whereas MUD1 and AberMUD had boasted around 400–500 discrete locations, a popular 1990 incarnation of TinyMUD called Islandia racked up over 14,000 of them in the few months of its existence.

The lack of game in TinyMUD meant that players spent most of their time creating things and talking about their creations.

Although not the first primarily “social” virtual world (Clive Lindus’ cleverly conceived Void ¹ beat it by a few months), it was the one from which virtually all subsequent such worlds sprang. TinyMUD was deliberately intended to be distanced from the prevailing hack-and-slay AberMUD style, and the “D” in its name was said to stand for “Dimension” (or, occasionally, “Domain”) rather than “Dungeon;” this is the ultimate cause of the MUD/MU* distinction that was to arise some years later.

LPMUD was named after its author, Lars Pensjö of the University of Gothenburg, Sweden. Having played both AberMUD and TinyMUD, he decided he wanted to write his own game with the adventure of the former and the user-extensibility of the latter. Whereas most early MUD designers were of the haughty opinion that players weren’t as good at world creation as they, Lars believed the opposite, that players could build a better world than he could himself. To this end, he developed an in-game programming language called LPC that allowed players of sufficient experience to add not only objects, but also powerful functionality to the game as it ran.

This was a major advance, and introduced many people to the wonders of programming without frying their brains in the manner that conventional academic learn-to-program courses tend to do. LPC was sufficiently well designed and is still very much in use today.

DikuMUD was created at the Department of Computer Science at the University of Copenhagen (Datalogisk Institutved Københavns Universitet), Denmark. Released in 1990, its authors were a group of student friends: Katja Nyboe, Tom Madsen, Hans Henrik Staerfeldt, Michael Seifert, and Sebastian Hammer. It was designed purely as a better AberMUD, and made no reference to either TinyMUD or LPMUD. Whereas these other two games had moved toward allowing on-the-fly changes to be made to the virtual world, DikuMUD’s designers went in the opposite direction and hard-coded everything they could.

However, they hard-coded it very well: DikuMUD ran “out of the box” and was organized very well internally. A reasonable C programmer could easily modify the original DikuMUD code and produce a new world of their own, or change the data files to create a differently-appearing one. Many did.

As a result, several major codebases (standalone MUD program suites) were created from the basic DikuMUD original, the main ones being Circle, Silly, and Merc. Merc spawned ROM (Rivers of MUD) and Envy, among others, and these in turn had their own spinoffs. All appeared—and continue to appear—in a dizzying number of sub-versions.

LPMUD did not inspire quite so many offshoots, because LPC was flexible enough to allow people to write their own games without writing their own game engines. Although most LPMUDs are combat-oriented, critically (and unlike DikuMUDs) they don’t have to be ².

The TinyMUD family tree is perhaps the most interesting of the three main AberMUD- inspired branches. TinyMUD itself was little more than a mere proof of concept. Incarnations of the game would appear on some long-forgotten university Unix machine, enjoy a few short months of brilliant existence, and then collapse under the weight of acrimony, apathy, and full disk packs that they caused. Those players who weren’t put off virtual worlds for life would then migrate ³ to another nascent TinyMUD and the cycle would repeat, slash-and-burn style.

The problem was that players couldn’t actually do much in TinyMUDs except invite one another to admire their latest piece of what might as well have been wallpaper. One player, Stephen White, decided in 1990 to extend the functionality of TinyMUD and wrote TinyMUCK (muck being a kind of mud). Using this as his template, he then produced MOO (MUD, Object Oriented). MOO introduced a fully functional scripting language (as such in-world programming languages ⁴ are called) and thus brought LPC-like capabilities to social-oriented virtual worlds. MOO had two important offspring: Pavel Curtis’ LambdaMOO (which was to become a favorite of journalists, academics, and social misfits) and, via CoolMUD, ColdMUD (an attempt to create a software-engineering quality virtual world authoring system).

MOO’s descendants have found a niche in the educational world, as they are easy to use and (like LPMUDs) can demonstrate the principles of programming to youngsters without scaring the wits out of them. They were not, however, the only important codebase family to come out of TinyMUCK.

Larry Foard released TinyMUSH later in 1990. The “MUSH” part originally didn’t mean anything special, but was later retrofitted as “Multi-User Shared Hallucination.” The TinyMUSH codebase introduced several advanced features, such as event triggering and software automatons (known as puppets), which together facilitated role-playing. Consequently, most of the derivatives of TinyMUSH (known as MUSHes) are role-playing in nature: What you do defines what you are, rather than the reverse.

From a non-historical perspective, the significant property of MOOs, MUSHes, and other descendants of TinyMUCK (known as MUCKs) is that they don’t have computer-controlled monsters for players to seek out and, within the context of the virtual world, kill. Players of these classes of virtual worlds are the ones most likely to use the term MU*, reserving MUD to mean those games that do have computer-controlled monsters for players to seek out and kill ⁵.

The third age of virtual worlds was thus a period of huge expansion. More people sampled virtual worlds than ever before. Indeed, a study of traffic on the NSFnet backbone in 1993 showed that just over 10% of the bits belonged to MUDs; in other words, before the advent of the World Wide Web (WWW) MUDs constituted some 10% of the Internet!

There were fewer positive consequences, however. Whereas in earlier times anyone who wanted to run a virtual world would have to write one from first principles, the sudden preponderance of codebases meant that this was no longer the case. If you wanted to run a virtual world, you simply downloaded an off-the-shelf one and voila!—one virtual world! Although in theory developers could change any aspect of what they had downloaded (particularly for LPMUDs and TinyMUD derivatives), in practice most people simply built on what they already had. This meant that two worlds using the same codebase would probably have the same basic geography and physics, with multiple extensions. Although some old-timers have complained that this leads to homogeneity and thereby stifles creativity, that’s not the main bugbear. Rather, it’s that if designers don’t understand why the partial design they begin with does what it does (and doesn’t do what it doesn’t do), how can they be sure their changes are for the best? Come to that, how can they be sure the template they begin with isn’t itself flawed in some way?

Were only undergraduates and amateur enthusiasts considered, the third age of virtual worlds is still very much upon us. Several thousand LPMUDs, DikuMUDs, MOOs, MUSHes, and MUCKs exist, some of them with impressive numbers of players. However, the torch of innovation was soon to be picked up by a different bearer—business.

The Fourth Age: 1995–1997

MUDs might very well have been called SOGs had things turned out differently.

Around the same time that Roy Trubshaw began work on what was to become MUD1, Alan Klietz wrote Sceptre of Goth on the CDC Cyber run by MECC (the Minnesota Educational Computer Consortium). The game (also known as Empire and The Phoenix) was based on an earlier MECC game called Milieu. It was developed completely independently; its mechanics owed more to Dungeons & Dragons than did MUD1’s, particularly in its use of character classes.

Sensing the commercial possibilities, Klietz ported it to run on a PC and ran it as a dial-up game. It met with local success, so incarnations were set up in several major U.S. cities. Klietz’s company (GamBits) then sold the software to another company. Unfortunately, this second company ran into severe legal problems and ran out of money. Sceptre of Goth passed to a creditor, and was never released again. Thus, through bad luck, the first commercial virtual world did not have the impact that it might have had, although it did make enough of a mark to influence the design of some later codebases, in particular Mordor.

In the UK, offshoots of the MUD1 family tree had done well, but were stymied by the system of high telephone charges that were then in place in that part of the world. When it costs more to connect to a game than it does to play it, there will inevitably be problems. People were running up phone bills of £2,000 to £3,000 a quarter—this at a time when the average salary was under £9,000 for an entire year.

The situation was little better in the rest of Europe; Gods did well in Germany, but couldn’t really be said to have cracked the market. Shades, released in a French translation for the Minitel teletext system, made nowhere near the £70,000 or more a year it had been clearing in the UK.

The picture was different in the U.S., where local phone calls were basically free. CompuServe recruited over a million subscribers to its system, charging them at premium rates to access data. Games formed a big part of its profit: Whereas it takes only two minutes to check how your stocks are performing, you might spend two hours playing a game. However, CompuServe did not promote its games, fearing that to do so would discourage parents from signing up to the service lest it corrupt their children.

Rivals to CompuServe were not so coy. GEnie was launched in 1985 by the former head of games at CompuServe, Bill Louden. Naturally, it put games to the fore, as did another 1985 start-up called QuantumLink. Although QuantumLink carried a very influential precursor to graphical virtual worlds (Lucasfilm’s Habitat, designed by F. Randall Farmer and Chip Morningstar) and was destined to become the mighty America Online (AOL), at the time it was GEnie that drew all the attention. Genie’s games-first strategy worked well, in that by the early 1990s hard-core gamers accounted for nearly 70% of GEnie’s revenue {Erratum: it was closer to 40%.}. However, GEnie suffered from lack of investment (most of its profits went back to parent company General Electric) and the fact that CompuServe’s concerns about the side effects of promoting games were not entirely unfounded. At this time, people still needed “noble content” such as news or educational products as an excuse to sign up for a service, even if they were only intending to play games when they got there.

Much of GEnie’s flowering at this time was due to the efforts of its Games Product Manager, Jessica Mulligan {Erratum: the legacy of Bill Louden’s early deals were a more significant factor}. Jessica had worked for QuantumLink, where she had recommended acquiring the Advanced Dungeons & Dragons license for an online game (which was eventually to become NeverWinter Nights). When QuantumLink began to de-emphasize games, she moved to GEnie. There, she assembled an impressive stable of some of the finest games of the day. Because of her, GEnie was the launch point for many classic online games, including two very important virtual worlds: Gemstone II {Errata: all these references to Gemstone should be GemStone, and GemStone II’s official name was Gemstone ][, with square brackets rather than Roman numerals. Also, it was Jess’s predecessor, Jay Saur, who was primarily responsible for bringing Gemstone ][ to Genie.} in 1988 and Dragon’s Gate in 1990 (a year in which earlier UK favorite Federation II also made it to GEnie).

Gemstone had been created by David Whatley and his company, Simutronics {Erratum: Simutronics was not incorporated at the time and was then known as Crystal Blade.}, in 1987; the II was added when it went live on GEnie. Simutronics’ expertise grew from BBS technology, and Gemstone II was a descendant of neither MUD1 nor Sceptre of Goth {Erratum: following Sceptre of Goth’s demise, five of the people who worked on it went on to create content for GemStone ][, so it’s unfair to say it wasn’t influenced by SoG. Furthermore, David had also heard of Island of Kesmai when he wrote GemStone.}.

In 1989, Darrin Hyrup, the lead programmer on another Simutronics game (Orb Wars), left to join a company called Adventures Unlimited Software, Inc. (AUSI). AUSI was started in 1984 by entrepreneurial programmer Mark Jacobs to run a text-based virtual world named Aradath he had written independently. Like Sceptre of Goth, Aradath ran on a home computer dial-up system, but unlike all other virtual worlds, for the next decade it charged its users a flat fee to play. Although it was turned down by QuantumLink, its promise was enough to tempt Darrin to join Mark to write Dragon’s Gate. This was a smart move.

At the end of the pre-WWW era in 1993, five U.S. services dominated the online market: CompuServe, Prodigy, AOL, Delphi, and GEnie. Smaller, games-specific services, such as MPG-Net and the ImagiNation Network, were also players in the games market (or tried to be). These services had a stranglehold on virtual world development: If you couldn’t get your game on one of them, you were in for a hard time. At this point, third-age virtual worlds were still the biggest and most important.

The WWW changed it all. People were suddenly excited by the concept of “online.” They flocked in droves to those services that offered Internet connection (which had previously been mainly the preserve of colleges). Some, such as AOL, embraced it. Others, particularly the ever-conservative CompuServe, tried to weather the storm and failed. A price war in 1993 among the major services had made Internet access affordable for all. Come 1995, hordes of inexpert computer users were knocking on the door, looking for interesting things. Some of them—rather a lot of them, in fact—wanted to play games.

Thus, the short but extraordinary fourth age of virtual worlds began. AOL went for the throat and signed up Gemstone III, Dragon’s Gate, and Federation II (it already had NeverWinter Nights). In common with other services, its business model was based on time spent connected to its system, a legacy of how computer bureaus used to charge for mainframe timeslices in the days when not every company had its own hardware. Also like everyone else, if its customers were accessing content provided externally, AOL paid a royalty. Unlike most of its competitors, however, it paid a fair royalty ¹. Unlike all its competitors, it picked up a vast user base ².

The consequence of this was that games like Gemstone III and Dragon’s Gate were making their authors over a million dollars a month {Erratum: they were being played for over a million hours a month, but weren’t making their authors a million dollars a month; GemStone ][ grossed around $10m for Simutronics in 1997.}. Even the “failing” NeverWinter Nights (NWN) took around $5,000,000 in 1996 {Erratum: it was more like $3m-$4m.}, despite being limited to 500 simultaneous players. It was an amazing time to be in the industry—if your game was on AOL. If not, it was hugely frustrating.

Disaster struck when the business model suddenly changed.

Small companies that used to run local BBSs began setting themselves up as Internet Service Providers. Initially, they used the same, pay-per-hour tariffs as the big boys. Then, in response to customer pressure, they broke ranks and switched to flat rate charging. AOL followed suit in December 1996, so as not to lose customers to these upstarts.

Unfortunately, AOL’s contracts with external information providers assumed a per-hour charge, which AOL had to honor. They tried to persuade game developers to accept a flat fee or a much reduced per-hour royalty, and some indeed went along with it. Others, however, held their ground. It was their opinion that the reason their games were successful was because they were good games; it had nothing to do with standing directly in the flow of AOL’s newbie hose.

A compromise dual-pricing scheme was implemented similar to one introduced by GEnie some years earlier, whereby “premium” content (that is, games) was charged by the hour and everything else was flat rate. This was not a great success, though, and by mid-1997 the gravy train had stopped running.

Most of the virtual worlds that had been on the big services set themselves up as independent games on the (now easy-access) Internet. After all, if they were able to keep all the money that players paid, they could afford to shed 80% of their player base and still make a huge profit. Unfortunately, they had not anticipated three major obstacles that would humble them greatly:

1. Most of their players objected to paying for a game they had previously considered to be free. Only the hard core—around 5% to 10% of the total—ever made the move. 2. Attracting newbies is very, very difficult. As existing players gradually drift away, from where do their replacements come?

2. Over a thousand virtual worlds were already accessible via the Internet for free—the LPMUDs, DikuMUDs, MOOs, MUSHes, and MUCKs. Sure, they were “free, and worth every penny,” but hey, free is free!

These for-pay virtual worlds (and others) do still exist, and do still make money, but it’s nowhere near the amount they did in the halcyon days of 1995–1997. It would be nice to think that developers have learned from this the dangers of over-estimating the intrinsic value of their products; nice, but unlikely.

Off-the-shelf codebases are free to use and free to play, but they are not freeware. They come with strict licensing conditions that preclude their being used commercially. This means that there is still some innovation, as people who want to make money from virtual worlds must perforce write their own from scratch. The days when people would willingly pay more per hour to access a commercial virtual world than they would later pay per month ³ are long gone, however.

Yet all was not entirely lost. At its peak, Gemstone III on AOL was attracting 2,000–2,500 players simultaneously. In theory, if a product could attract players in sufficiently large numbers—say, 10 times this number in total—then it might be possible to levy an inexpensive monthly fee and still make a respectable profit.

In 1997, Origin Systems Inc. (OSI) launched Ultima Online.

The Fifth Age: 1997–Present

There had been graphical virtual worlds before.

The seminal PLATO (Programmed Logic for Automatic Teaching Operations) system went live at the University of Illinois way back in 1961, and many games were written to take advantage of both its network connectivity and graphics-capable plasma display units. Some of these laid down principles that would greatly influence the development of later computer games; some came close to being virtual worlds; some actually were virtual worlds.

Orthanc, by Paul Resch, Larry Kemp, and Eric Hagstrom, was an overhead-view graphical game that, although not implementing a shared world, nevertheless allowed communication between individual players. It was written as early as 1973. Jim Schwaiger’s 1977 game Oubliette (inspired by Dungeons & Dragons and Chuck Miller’s earlier multiplayer game, Mines of Moria) had a first-person point of view and used line graphics to render the scene ahead. It had persistent characters, but was not a persistent world. Also, the interaction it allowed between characters was very limited; it was almost there, but not quite.

In late 1979, the first ever fully-functional graphical virtual world was released: Avatar. Written by a group of students to out-do Oubliette, it was to become the most successful PLATO game ever—it accounted for 6% of all the hours spent on the system between September 1978 and May 1985 ¹. Again using a Fantasy setting, it introduced the concept of spawning to repopulate areas automatically after players killed all the monsters.

Despite the fact that PLATO was very important in the development of computer games in general, its virtual worlds had little external impact. This was almost certainly because the twin strengths of the PLATO system—its fast network and superior graphics—would not generally become available to home users for another 15 years. If your screen can only display text and your modem only runs at 300 baud, online pictures aren’t exactly a major priority. Insofar as the history of graphical virtual worlds is concerned, the second to fourth ages are pretty much dark ages.

Some of the second age virtual worlds almost went graphical. There were plans to produce Atari ST and Commodore Amiga clients for Bloodstone, a virtual world by Robert Muir that ran on Microlink, but they amounted to nothing. The co-ordinate-based Mosaic system (nothing to do with the browser of that name) pioneered by the MirrorWorld team was ideal material for conversion to graphics, but Pip Cordrey was vehemently anti-graphics and blocked the move. Others toyed with the idea, only to be put off by the expenses involved.

A graphical virtual world that did influence others was Island of Kesmai, (IOK) written by Kelton Flinn and John Taylor in 1981. It grew from a six-player game called Dungeons of Kesmai that the pair had completed a year earlier, and was independent of the other work on virtual worlds going on at the time (the pair hadn’t even heard of ADVENT, let alone MUD1!). IOK debuted on CompuServe in December, 1985.

The game did not have graphics as such. What it did have was a display that used individual letters and other ASCII characters to represent a bird’s-eye view of the immediate vicinity. Because of the ersatz graphics, the degree of interaction allowed between players wasn’t as high as in a purely text-oriented game (a state of affairs that continues to this day), but it was good enough to qualify IOK as a virtual world.

The graphics capabilities of home computers gradually improved, and it was therefore only a matter of time before someone wrote a game that coupled an IOK-style tessellated world with a hardware-specific means of displaying it. Indeed, by the early 1990s the Kesmai Corporation had already done it for their multiplayer flight simulator game, Air Warrior, which had clients for the PC, Atari ST, Commodore Amiga, and Apple Macintosh. The basic principle was for the virtual world software itself (the server) to send data to software running on the home user’s computer (the client), which it could use as the basis to construct an image ².

Although Kesmai eventually produced a (disappointing) graphical version of IOK called Legends of Kesmai, they were well beaten to the punch by NeverWinter Nights (1991 on AOL), Kingdom of Drakkar (1992 on MPG-net), and Shadows of Yserbius (1992 on ImagiNation Network). These games basically took the same approach: a bird’s-eye view of a 2D world built from squares, with flat sprites to represent players, objects, walls, and things to be fought. They maintained separate text areas for information, descriptions, and communications.

This is a very effective way to do it. The bandwidth and server load requirements are comparatively light, the design tools are cheap to develop, and you can create large, interesting worlds with a fair degree of interaction among the players. Such worlds can lack flexibility—you won’t see many circular buildings in them—but they pay for it by their ease of creation. The scale is usually an issue, in that there’s a conflict between the amounts of space in the virtual world that characters appear to occupy (because of the fidelity of the graphics) and the amount they seemingly ought to occupy (because they represent people), but it’s nothing too serious.

Note that although all tessellated worlds are essentially 2D, they don’t have to be shown in the same, boring, map-like way that a newspaper typically displays a chessboard. Instead, they can be shown isometrically. By fixing the camera (that is, the player’s viewpoint) at an angle other than directly overhead (say, at 60°), the impression of a 3D world can be given.

1 This is sometimes referred to as a 2 ⁄2D world. It was inevitable that as soon as computer video cards were up to the job, new games would appear in the more realistic-looking 2½D rather than plain old 2D ³.

At this point, the story changes continents.

In Europe and North America, individuals wanting to use the Internet for fun would generally do so from home. This was not necessarily the case in other countries. In particular, the trend in South Korea was to use Internet cafés, where people could share their online experiences in a friendly, social atmosphere (with broadband connections). Large chains of such establishments soon spread across the country. This presented Korean game developers with a business model not available in the West: licensing game access to the Internet cafés, rather than to the players.

Two companies took advantage of this: Nexon launched The Kingdom of the Winds in 1996, with NCSoft’s Lineage® following in 1997. Lineage was designed by Jake Song, who had previously worked on The Kingdom of the Winds (TKOW) and was later voted South Korea’s best game designer. Both TKOW and Lineage used a 2D perspective, but the latter had vastly superior graphics and almost immediately became the virtual world with the most real-world players anywhere. It opened in Taiwan and was a huge hit there, too. Attempts to repeat this success in the U.S. market failed, however; for some reason, the game did not appeal to American tastes. It was therefore almost completely ignored in the West, until something happened that forced developers to pay attention: Revenue figures for Lineage in the first quarter of 2000 were posted at 6,500 million Won, that is over five million dollars. Virtual worlds were becoming a global phenomenon, and Korea was a leading marketplace.

In terms of advances in game design, though, the plot returns to the U.S. in 1997.

Although The Kingdom of The Winds predated it, the product that truly proved virtual worlds had come of age was OSI’s Ultima Online (UO).

It is hard to understate the impact that this work had on the consciousness of developers and publishers. Prior to Ultima Online, virtual worlds had been regarded as all potential: It was clear from the devotion they inspired that they could probably make pots of money, but as no one had managed to do so outside of peculiar market conditions few companies were willing to invest in producing one. This was soon to change.

When Ultima Online garnered 50,000 subscribers within 3 months, people took notice. When it broke 100,000 within a year, jaws dropped. Never mind the substantial income from retail sales: 100,000 people were each paying $9.95 per month having already bought the game—and none of that money was going to retailers!

OSI was directly taking 12 million dollars a year from that one virtual world!

Ultima Online set the standard: 100,000 subscribers by the end of year one is the benchmark—anything less than that, and a graphical game-oriented virtual world can’t honestly call itself a success.

So how did Ultima Online manage to pick up so many subscribers so quickly? Part of it was being the right product at the right time, of course, but the Ultima name—one of the best loved and respected by role-playing gamers—was probably the main reason people were so keen to try it. The virtual world it promised really caught the game-playing public’s imagination.

Trying a game doesn’t mean that people will continue to play it, though. With ordinary boxed games, the publishers don’t particularly care whether anyone actually plays their products, so long as they buy them. Ultima Online had to be good enough that people would want to play—and would shell out nearly 10 bucks a month to do so.

That people did play is a tribute to the game’s design team, led by Raph Koster. Raph had a background in virtual world design, having worked on 1992’s Worlds of Carnage (the first DikuMUD to have an embedded scripting language) before moving on to found LegendMUD in 1994 with Kristen Koster (his wife), Rick Delashmit, and others. In 1995, Delashmit signed up as lead programmer for Ultima Online and recommended the Kosters to OSI.

LegendMUD was itself an innovative game, boasting a number of features to promote role-playing that had never been implemented before. For example, unlike other DikuMUD derivatives, LegendMUD was classless (players don’t elect to be fighters, magic-users, healers, thieves, or whatever); this concept was to shape the design of Ultima Online powerfully. The wide-ranging playing experience of the designers meant that they could draw on ideas from many other codebases, too.

Perhaps most importantly, however, Ultima Online was conceived from the start to be a richer and deeper virtual world than a typical MUD, with an emphasis on community building, player-driven action, and the ability to accommodate different playing styles. These were tremendously important insights; they had a powerful impact on the graphical virtual worlds that appeared in the two to three years following UO’s release, and are now regarded as absolute prerequisites in the designs for new virtual worlds. Although later games could take aspects of UO on board, their designers were not always aware of the reasoning that had led the UO team to include or exclude some concept or other ⁴. This led to balance issues (among others), and is one of the reasons why, in design terms, UO remained pre-eminent until the arrival of Star Wars Galaxies in 2002. It is no coincidence that the lead designer of Star Wars Galaxies (SWG) was also Raph Koster.

UO nevertheless did have its problems, the two principal ones being:

• It was at times too innovative. Some of the ideas it field-tested did not work as planned and had to be altered. Examples: The means by which players were punished for attacking each other’s characters wasn’t effective; the detailed ecological model employed broke down when players rapidly killed everything that moved; the economy collapsed after a bug led to hyper-inflation.

• It was a victim of its own success. Although OSI was expecting tens of thousands of players, they weren’t expecting hundreds of thousands of them. The sheer number of people involved meant that the pressure was on to correct any problems as soon after discovery as possible. This caused several management decisions to be made that, in retrospect, set precedents, which perhaps ought not to have been set. Customer service doesn’t scale well or rapidly.

All in all, UO was a game ahead of its time, but not so far ahead as to be regarded as a failure.

The same could not be said of Archetype Interactive’s Meridian 59.

Launched a year ahead of UO (after the company had been bought by 3DO), it was the first graphical virtual world since the days of Avatar to employ a first-person point of view (that is, where the screen shows what the player’s virtual character sees, rather than what someone sitting on a low cloud would see—if they could remove rooftops).

Because players could move around and view their surroundings from almost any angle, Meridian 59 gave a far greater sense of being a 3D virtual world than did UO or Lineage. Indeed, this is the kind of viewpoint people typically mean when they’re talking about a 3D world or viewpoint in respect of any computer game ⁵.

Meridian 59 (M59) was designed by Mike Sellers and Damion Schubert, the latter having been recommended by Raph Koster (who had accepted a job at OSI by then so was unavailable). It was intended to become the first “3D MUD,” and in this it succeeded.

However, it was not the huge success that it might have been (and that the designers of other in-development graphical virtual worlds feared it would become) mainly due to a lack of experience. The designers, the developers, and especially the publishers (3DO) made several mistakes that are classic to virtual worlds and therefore should have been easily avoided. To be fair, the designers did know their stuff, but they were working to a small budget and a short deadline.

Among the mistakes made were

• Allowing access permissions for certain features (for example, in-game shops) to be determined by the (soon-to-be-hacked) client software.

• Not fully testing the software. It was very stable, but one particular showstopping bug rendered the in-game currency completely worthless overnight.

• Community-alienating changes of business plan. Originally costing each player $10 per month, they switched to $2.49 per day (“but never more than $30 a month”) and lost a third of their players in the process ⁶.

• Self-defeating customer service work (due to a “no comment” policy).

Of course, these errors were also made by many of the virtual worlds that followed Meridian 59 (indeed, they’re still being made today). These other virtual worlds didn’t all fail, however, so why did M59?

M59’s problem was that it didn’t garner enough players early on to weather its storms. There are several reasons for this, but they all come down to the fact that it was launched too soon. M59 is remembered for being the first 3D virtual world; if it hadn’t gone to market prematurely, then it wouldn’t have been able to claim this title, but instead of being the pioneer it could well have become the paradigm.

What M59 did wrong that actually hurt it was

• It had poor marketing. Few people outside the online gaming community knew it existed. The computer games press didn’t care about it.

• Its graphics didn’t compare well to those of other 3D games around at the time (particularly Quake’s). This is probably why the computer press didn’t care about it.

• It had insufficient content. The world felt very small, and it lacked many features traditional to the Fantasy genre that potential players were surprised to find missing.

• There weren’t enough people with Internet connections when it launched. Ironically, if they hadn’t launched early to get the drop on Ultima Online then there almost certainly would have been.

In other words, it wasn’t the design that killed it but the business decisions made. Design is hugely important, but it can’t do everything.

Even so, Meridian 59 did a lot of things right. In particular, it released expansion sets to keep players interested and (until it changed its pricing scheme) it made the total number of players important, rather than the total number of hard-core players. It also ran multiple incarnations of its virtual world on different servers, some of which it licensed to other countries (which although it had been done commercially back in the days of Shades had by then gone out of fashion).

Although the M59 team was inexperienced to begin with, they soon learned. M59 graduates are now among the most sought-after personnel in the industry. Mike Sellers (who left before M59 shipped) went on to become lead designer of The Sims Online; Damion Schubert accepted the same position for Ultima Online 2 before setting up as an independent creative consultant and eventually winding up working on the much-anticipated Shadowbane ⁷; producer Rich Vogel took over from Starr Long at Ultima Online shortly before that game’s launch, later beating all opposition to land the plum position of producer for Star Wars Galaxies.

The main reason for M59’s only modest success was that it came to market a touch too soon. In 1996, few people had a graphics card in their PCs and their modems were 14400 baud. M59 therefore had to be written for this level of client hardware, or no one would have played it.

A year later, when UO launched, prospective players had upgraded and the OSI team was able to deliver a far more feature-rich product. UO had a somewhat bigger budget, too.

UO wounded M59, but not mortally. The fatal ⁸ blow was only to come in the spring of 1999, with the launch of 989 Studios, EverQuest. {Erratum: EQ was not responsible for M59’s decline, it was merely the last nail in the coffin.}

If ever there was a case of being in the right place at the right time, EverQuest (EQ) is it. It was basically a DikuMUD with a graphical client bolted on—the similarities are so close that under legal threat its server programmers were forced to sign sworn statements to the effect that they didn’t use any actual DikuMUD code in EverQuest ⁹.

Graphically, EverQuest took the same first-person 3D view as Meridian 59, but allowed the camera to roam instead of fixing it to the character’s eyes. If players wanted a bird’s-eye view or to see their own character from behind, they could do so. The graphics also occupied a good deal more of the screen, which greatly improved players’ feelings of being immersed in the environment.

In terms of gameplay, EverQuest wasn’t especially deep (although neither was it shallow). Had it been launched even a few months later, it would probably have had only moderate success; it was never exactly innovative, and there were other games in development which would have made it look inferior by comparison. However, it was launched at exactly the right moment. Its designers (Steve Clover, Brad McQuaid, and Bill Trost) had done a sound job.

It looked good, there were plenty of computer gamers actively seeking an online game to play, its DikuMUD heritage guaranteed a compelling experience, and Ultima Online was getting bad publicity because of its unpopular way of handling combat between players’ characters and its generally poor newbie experience.

EverQuest had no great publicity campaign, which is probably just as well: News of this beautiful virtual world spread by word of mouth so rapidly that it was only through good fortune that enough Internet bandwidth became available in San Diego (where the servers were located) to cope with the demand ¹⁰. EQ overtook UO in terms of subscriber numbers within six months and its usage figures were ordained to grow relentlessly, month after month, for years.

EQ’s developers were just as inexperienced as M59’s, and they also made a number of novice errors. Indeed, their customer relations department was so systematically bad that at times it seemed people were playing in spite of their efforts, not because of them. So why did EQ put the final nail in M59’s coffin, rather than suffering a similar experience itself?

Essentially, the answer is that EQ reached a critical mass of players.

Whatever the reasons people had for starting to play the game, they continued to play because of the other people they had met there. EQ was constructed to encourage players to form small groups and play regularly with one another; if the team was short a member, players would persuade their real-world friends to make up the numbers. This bonding was something M59 lacked, and in due course led to EQ’s all-conquering progress.

EQ’s impact on subsequent graphical virtual world design was profound. It became the de facto paradigm for the genre. This had three main consequences:

• Players who “grew up” on EverQuest viewed its user interface, gameplay, and feature set as standard. New games that did not conform to this were viewed as flawed. This is not a new phenomenon. Players of Shades who tried out other games were often disparaging about what were actually superior (but non- Shades) ways of doing things. Similarly, after AOL purchased the ImagiNation network and dropped NeverWinter Nights, Meridian 59 received a flood of refugees who then proceeded to demand every NWN feature that M59 didn’t already have, irrespective of how appropriate it was to the game.

• The sheer amount of money EverQuest generated caused developers considering writing a virtual world to jump on the bandwagon. Within two years of EverQuest’s launch, over a hundred graphical virtual worlds had been announced as being in development, of which the vast majority were EverQuest near-clones.

• EverQuest sucked in newbies who might otherwise have tried some other game, thereby depressing the market for the games that immediately followed it and forcing them to survive on their ability to attract the non-mainstream gamers.

One of the products to suffer was Turbine’s Asheron’s Call. Designed by Toby Ragaini (lead), Chris Foster, Eri Izawa, and Chris Pierson, it launched nine months after EverQuest (at least a year late, due to the inexperience of the production team ¹¹).

It broke new ground with a number of inventive ideas ¹², primary among which was the story arc: Structures, objects, and new functionality would be added to (and in some cases, removed from) the virtual world on a regular basis (monthly) to unfold an overall narrative.

Asheron’s Call (AC) also had some technical innovations that impacted virtual world design. One of the more irritating things about EQ was that it partitioned its world into zones. Rather than having a single, expensive computer to act as a server for the whole virtual world, each zone ran on its own computer as part of a cluster that comprised the server. Players moving from one zone to another would experience some delay while any initialization information concerning the new zone was transmitted to their PC. Once in the zone they were sharing its governing computer with only a fraction of the other players in the game, and therefore the response was good; however, moving between zones was a pain.

AC didn’t have zones, which meant it presented itself as a single, seamless world—a far more player-friendly proposition. It still used a cluster of computers to manage the world, but didn’t assign individual machines to specific zones. Instead, it used a technique called dynamic load balancing to determine which cluster member was in charge of which location set. If players congregated their characters in one area of the virtual world, the server responsible for it would offload part of that area (and the players associated with it) to another, less heavily loaded machine. Similar distributed server technology had been used by Nexon in 1999 (the year AC launched) to cram 12,263 users in a single incarnation of The Kingdom of the Winds, albeit with a 1 tessellated 2 ⁄2D world rather than a fully 3D one.

AC managed to build up a player base of around 80,000 by the end of its first year—20,000 short of the total needed for it to be considered an unqualified success. Had it launched before EQ, as originally planned, the story might have been rather different.

By the end of 2000, the state of play among the “big three” virtual worlds was as follows:

• Ultima Online (launched 1997) had 230,000+ subscribers from boxed unit sales of 380,000+ and expansion pack sales of 100,000+.

• EverQuest (launched early 1999) had 300,000+ subscribers from boxed unit sales of 600,000+ and expansion pack ¹³ sales of 300,000+.

• Asheron’s Call (launched late 1999) had 90,000+ subscribers from 200,000+ ¹⁴ boxed unit sales. It hadn’t released any expansion packs.

What is most interesting here is not so much that EQ had a staggering 300,000 subscribers, but that it had lost a staggering 300,000 players who originally purchased the boxed unit. UO’s retention rate, at 60% overall, was significantly better. Although continuing good word-of-mouth and large-scale advertising campaigns brought EQ yet more swathes of players in the coming years, its churn only got worse.

The next significant release of a graphical virtual world was Funcom’s Anarchy Online in June 2001. The first such world to be written by Europeans (a Norwegian/Irish team), it was a departure in that it took a Science Fiction theme rather than the traditional ¹⁵ Fantasy. To provide some context, lead designer Gaute Godager buttressed it with a story arc. Unfortunately, the game suffered a disastrous launch, from which it took some time to recover. Consequently, it also failed to accumulate 100,000 players within 12 months. This was a shame, because its overall design was quite attractive.

By contrast, the launch of Mythic Entertainment’s Dark Age of Camelot® in October 2001 was a model of how to do things right. This is perhaps not surprising, given that Mythic was a direct descendant of AUSI, the company responsible for Dragon’s Gate. The design team, under the guidance of Mark Jacobs, created a world that was both familiar (from the Camelot legends) and superficially compelling (because of its realm versus realm (RvR) approach to combat between players’ characters ¹⁶).

These factors made the game attractive to a large constituency, and well-targeted marketing let potential players know. Dark Age of Camelot (DAoC) racked up 200,000 subscribers by May 2002, easily supplanting Asheron’s Call as the third most popular virtual world in the West.

All these games are PC-based. It was not surprising, therefore, that console companies with their enormous installed user bases and tightly-regulated platforms would want to get in on the act. The SEGA Dreamcast was bold enough to take the first step (with Phantasy Star Online ¹⁷), but the company did not really understand the concept of Internet games and the venture was not a success.

Sony, as owners of EverQuest, did understand it, however, and in May 2002 launched Square’s Final Fantasy XI on the PlayStation 2. By the end of August, they had 120,000 users in Japan, each paying a monthly fee of ¥1,280 ($10.71 at the time). Although this qualified the game as a success, Sony’s overheads were such that 200,000 users were needed to break even. Their target was 400,000 users, but they could only envision reaching that number by releasing a PC client. This is not unreasonable: Consoles are secure development platforms, but not so secure that a developer would be foolish enough to trust a client not to be hacked. Therefore, there is no inherent technical reason why a virtual world targeted at console owners should not have a PC client too. It is likely that in the future, major virtual worlds will be expected to support a range of platforms; how this affects the design of the world itself depends on the nature of the lowest common denominator of those platforms ¹⁸.

And so we come to today ¹⁹.

The Sims Online (TSO), launched December 2002, has yet to break the 100,000 subscribers mark. Given the popularity of the Sims franchise, this has to be considered disappointing. My guess is that if the publishers hold their nerve, things will improve in the long term. At the moment, too many people are treating it as a game, then complaining that its only gameplay involves making pizzas for one another. The Sims is more a toy than a game, and the same is true of The Sims Online. Gamers are typically early adopters, but The Sims Online’s core players aren’t. If they come in sufficient numbers to replace those gamers who leave, all will be well. Nevertheless, TSO’s slow start could have some knock-on effects for virtual worlds in general, depending on how the marketers who used it for product placement assess its less than spectacular beginnings.

The Sims Online had over 100,000 beta-testers and has sold over 100,000 boxes. Large numbers of beta-testers are currently quite fashionable: Star Wars Galaxies hit 150,000 in August 2002, and even soon-to-launch EVE: The Second Genesis ²⁰—hardly a guaranteed hit—is claiming 140,000. Whether this trend will continue in the light of the experience of The Sims Online, remains to be seen. Skeptics might be forgiven for wondering how many of these beta-testers are beta-testing several virtual worlds simultaneously, and therefore whether the perceived marketing benefit of a large beta-test is as strong as is normally assumed.

There is further evidence from the experience of Asheron’s Call 2 ²¹ (AC2). This virtual world also launched December 2002; it has beautiful graphics, but again seems to be struggling to attract newbies. Original AC players have been reluctant to switch over to it, and its attempts to pander to popular player opinion by diluting anything inconvenient (character “death,” the economy) may have backfired—it reduces the challenge somewhat. As with The Sims Online, AC2 had over 100,000 beta-testers but has yet to pick up that many subscribers ²².

Wolfpack’s Shadowbane launches the day I write this. Long in development, it has been hyped relentlessly to some effect: There’s little doubt exactly what kind of virtual world it is (violent) and no danger that people who don’t consider this to be fun will even play it, let alone complain that it doesn’t address their needs. Other virtual worlds have been prematurely hyped more (Glitchless’s Dawn ²³ and Artifact Entertainment’s Horizons ²⁴ spring to mind), but Shadowbane seems to have got its act together first. It therefore starts with a relatively small but highly dedicated core player base upon which to build. Time will tell whether it succeeds or not.

It’s clear that the fifth age of virtual worlds will last for some years to come, but eventually its time will pass. Perhaps free 3D graphical engines will herald a new era of homegrown virtual worlds, or maybe advances in virtual reality interfaces or mobile telephony will have an impact. It could be any one of a number of things currently known and unknown that triggers the eventual paradigm shift.

What wonders will the sixth age of virtual worlds bring? That, perhaps, may be for you to determine.

The Past Affects the Future

Very few graphical virtual worlds that are announced as being in development actually wind up being played. This situation may change as the barriers to entry fall, but probably not significantly so.

Estimates vary, but at least a hundred graphical virtual worlds—perhaps up to two hundred—were announced in the two years following EverQuest’s launch in 1999. Some were down to wishful thinking on the part of talented (or otherwise) amateurs; some failed in preproduction because funding was not available; some failed when the money they did raise ran out; some built up a community and reached live testing before they went belly-up.

Some, however, were set to become bestsellers yet were inexplicably cancelled. Three of these were to have repercussions for the industry as a whole.

Missed Opportunities

OSI, which wrote Ultima Online, was part of Electronics Arts (EA). Given the positive effect of the Ultima name on sales, other brands from the EA stable were considered contenders for implementation as virtual worlds. Thus began the Privateer Online project. Raph Koster was installed as lead designer, with Rich Vogel as producer. Work was well advanced when the project was suddenly, bizarrely cancelled. Raph, Rich, and others were immediately snapped up by Sony Online Entertainment (SOE) to work on the Star Wars license they had recently acquired. SOE was the new name of Verant, a company spun off from 989 Studios to develop EverQuest. In other words, EA presented some of its best virtual world experts to one of its two major competitors. EA would shortly give most of its remaining experts to its other major competitor.

Ultima Online 2 was planned to be set in the same universe as UO, but to be fully 3D with an EQ-style moveable camera. Early screen shots showed it to be much superior in looks to EQ, and with Damion Schubert (of Meridian 59 fame) as lead designer and Starr Long (Rich Vogel’s predecessor at UO) as producer it was sure ¹ to be a hit. Also involved was Jeremy Gaffney, who was a founder of Turbine and had worked on Asheron’s Call.

Signs of strangeness appeared when the game was renamed as the unwieldy Ultima Worlds Online: Origin, but it wasn’t until 2001—three years into the project—that it was insanely canned.

Starr Long, Jeremy Gaffney, and most of the other talent involved left almost immediately to set up with the designer of the Ultima series itself, Richard Garriott. Their new company, Destination Games, was shortly thereafter acquired by NCSoft, developers of Lineage, who saw an opportunity to use their Korean profits to break into the American market. Jake Song moved from Korea to Austin, Texas, to work with them. Electronic Arts had done it again. They were not the only company capable of such monumental gaffes, however.

Venerable games publisher Sierra had dipped its toes in the online marketplace before, having set up The Sierra Network in 1991; they sold it in 1994 for around $50,000,000 to AT&T, who renamed it ImagiNation Network ². Sierra had maintained an interest in a virtual world called The Realm, designed by Steve Nichols, which was eventually launched early 1997. The Realm was graphical, but had separate, static 2D pictures for each location that acted as a stage across which animations of the players’ characters moved. It dated rapidly and failed to attract more than about 25,000 subscribers at its peak (late 1997). Nevertheless, it was proof of concept, and Sierra had an ace up its sleeve.

Some mainstream entertainment properties would make poor virtual worlds. The Harry Potter universe, for example, doesn’t really allow for more than one Harry Potter in it. There are three franchises, however, that are especially well suited to being embodied as graphical virtual worlds ³ and which would produce a guaranteed hit: Star Wars, Star Trek, and The Lord of the Rings. Sierra had a Lord of the Rings license.

In 1998, Steve Nichols signed up as lead designer of Middle Earth Online, along with Janus Anderson (also of The Realm), Daniel James (from a top-notch commercial text-based virtual world called Avalon), and Jay Esparza (already with Sierra). The designers were keen to discuss all aspects of the development with prospective players, and consequently generated a lot of buzz. They also generated a lot of friction with Sierra executives, who didn’t like some of what was being mooted—especially with regards to plans for the permanent death of player characters.

The project continued, however, until during a company-wide reorganization of Sierra in 1999 the opportunity was put on ice. The design team was removed. Sierra also decided to abandon The Realm because it didn’t look good against Ultima Online and it looked worse against EverQuest. The game was taken up by Codemasters and newly released Steve Nichols joined them.

The story does not quite end there, however. Sierra secretly hired a new design team to work on Middle Earth Online. This was perhaps not unrelated to the fact that the first of the Lord of the Rings movies was due to be released in 2001, which would generate massive, free publicity. Again, though, Sierra mystifyingly canned the project—although at least this time the developers, MM3D, sued.

Sierra had missed its chance. In December 2001, the movie The Lord of the Rings: The Fellowship of the Ring was released. It grossed $155,862,412 in its first two weeks ⁴.

That is how out-of-touch management decisions shape an industry.

Theory and Practice

It should be clear by now that virtual worlds have a long and varied history—much longer and more varied than many of the people who play and design them realize. But so what?

It’s not entirely the case that only by understanding the past can people understand the future. Virtual worlds have been “invented” at least seven times (MUD1, Sceptre of Goth, Avatar, Island of Kesmai, Aradath, Monster, and Gemstone were all developed autonomously), and the designers of these games had no sense of any “past” in what they were doing. Originality is entirely possible without rehashing other people’s ideas.

However, to ignore completely what has gone before would be extremely foolish. Time and time again, designers have made the same mistakes their predecessors made, either because they were simply not aware of the earlier work or they were too arrogant to believe it could possibly be relevant to their greatly superior product.

Conversely, some designers look too hard at what has gone before. To use some admired virtual world as a prototype is fine if you fully understand that world, but very limiting if you don’t. A designer whose major experience of virtual worlds is EverQuest might, for example, think “what character classes should we have in our new game?” rather than “should we have character classes in our new game at all?” Some of the more basic assumptions go right back to MUD1, with few designers even realizing that they are assumptions, let alone that they can be questioned. That can’t be right!

Nobody wants to repeat the mistakes of the past, but people don’t always realize that what they’re repeating is a mistake. That’s because they’re learning the wrong lessons. The past delivers facts—the practice. History delivers the understanding of those facts—the theory. It provides the causal links.

This is especially true for the design of virtual worlds. Each must be conceived as a complete entity. Each one can’t really be modularized: Every component affects every other. Sometimes newspapers put together composite pictures made of the best features of famous faces—Bette Davis’ eyes, Julia Roberts’ mouth, Doris Day’s, nose and so on. The result is usually more like Frankenstein’s monster than “the world’s most beautiful woman.” So it is with virtual worlds: It doesn’t matter how perfect the parts, it’s by the whole that they are judged.

Thus, designers who know not only the choices available to them but also the wider effects of those choices are better able to create a virtual world that works than those designers who don’t.

Whither Innovation?

The design of virtual worlds proceeds by a process of evolution rather than revolution. New virtual worlds usually draw heavily from one or more “parent” worlds, even to the extent that it’s possible to map out an entire family tree for all the various codebases ¹. This being so, it is becoming increasingly important that designers of new virtual worlds become aware of innovations arising in other branches of the tree. Not only does this ensure that the best ideas spread, but there is less danger of standards problems arising from the same concept being implemented differently in different virtual worlds.

Because graphical virtual worlds take so long to develop, their designers in particular must keep an eye on what’s happening elsewhere. These games (they do tend to be games) have their own strengths, of course: Their visual representation demands new levels of virtual world physics, and the huge number of players they have opens the door to all manner of interesting developments that would be impossible on a smaller scale. However, they are still several years behind text-based virtual worlds in nearly all other areas.

Furthermore, they’ll probably stay behind for some time. When it comes to implementing new ideas, text-based worlds are more:

• Responsive: Adding a new object doesn’t mean adding a new texture map.

• Enfranchising: Many more people can write well than can draw well.

• Adaptable: Program changes can quickly be made anywhere in the system.

• Experimental: The test/edit cycle is much shorter, so changes can be made almost on impulse to be later refined, retained or rejected.

• Open: Players give new ideas more of a chance.

• Pragmatic: Players accept crashes and other failures more readily if they’re not paying.

• Tunable: Minor changes don’t mean major down-time.

• Promising: More is possible with text than with graphics.

• Robust: Balance is less of an issue with fewer players.

Besides, the consequences of a failed programmed-in-your-spare-time virtual world are far less agonizing than they would be for a $15,000,000 graphical extravaganza.

So how does a designer keep up to date?

Anyone with time on their hands ² can check out a sample of the several thousand text-based virtual worlds that there are in existence ³ if they want to find out “the word on the street.” However, as I pointed out earlier, knowing what is available without knowing the theory behind it can be disastrous. It’s therefore in the best interests of all virtual world designers to discuss ideas with one another. It isn’t for sentimental reasons that luminaries such as Raph Koster, Damion Schubert, Brad McQuaid, and Jessica Mulligan not only subscribe to the MUD-DEV ⁴ mailing list, but are active posters to it. Neither is it surprising that the best informative and speculative articles about virtual world design are being written for—and made publicly available for free by—a company specializing in immersive text-based worlds, Skotos ⁵. There’s even a print magazine, The Mud Companion ⁶.

The future of virtual world design is therefore rosy, although obviously not as rosy as it would be if people richer than Skotos were to throw money at it.

The future is just that, however: the future. There’s little point in discussing what may happen to virtual worlds unless you understand what has happened and what is happening.

The timeline I’ve presented here has outlined how things came to be the way they are in the virtual worlds of today ⁷, but it has given few hints as to what actually comprises a virtual world, let alone the wider effects of including or excluding particular components in a design.

It is to this topic that the major part of the remainder of this book is concerned.

The Basics

People often want to categorize the various virtual worlds, to make it easier to discuss their particular interests or find a world that is most suited to their needs. Prospective players, for example, will want to know what a world looks like and its setting: If you want to role-play an interstellar pirate, you’re not going to have a lot of luck in a Fantasy environment. Marketers and investors are more concerned with a product’s longevity and its user demographics: They may not want to spend any time in a virtual world themselves, but they’re keen to know about those who do. Finally, designers have their own, theoretical issues to resolve, in addition to understanding what the players and marketers think.

Having looked at virtual worlds from a historical perspective, the categorizations typically used present themselves fairly readily:

• Appearance

• Genre

• Codebase

• Age

• Player base

• Degree to which they can be changed

• Degree of persistence

Let’s consider these in turn.

Appearance

Newbies tend to believe that the appearance of a virtual world is very important; oldbies are generally more concerned with other features.

Virtual worlds are typically characterized as being either text-based (textual) or graphics-based (graphical). The former use words to describe locations, objects, and other players, whereas the latter use pictures.

There is, however, quite a spectrum between the two extremes. To access a textual virtual world, a player needs some kind of software connection to it. This may be direct—for example, by running the game server from a console and typing at its prompts—or it may be indirect through use of a client. If a client is involved it may be dumb, intelligent, or custom.

Strictly speaking, a dumb client does nothing except input (which it passes to a server), and output (which it does to whatever the server sends back). However, few clients are actually that dumb—even telnet can handle minor editing functions such as backspacing. It’s deliberate that dumb clients don’t do a lot, because that way they can be used for a greater variety of purposes.

Even when dealing with a dumb client—or no client at all—a virtual world need not merely consist of lifeless text. Individual letters, words, sentences, and paragraphs can be colorized by the server (usually using the ANSI standard understood by most PCs) to make the resulting display more attractive and meaningful.

Intelligent clients are intended for use with specific application types; in this particular case, that means textual virtual worlds. Such clients provide additional input functionality (such as macros or triggering) and tools for managing output (such as local logging and word-wrapping). Although these features could still be implemented at the server end and used with a dumb client, most modern server authors don’t bother with this as they know there are now so many ¹ good clients about that people will almost certainly be using one anyway.

Custom clients work only for the small subset of virtual worlds that share its protocol (in practice, this usually means just one). The client sends packets of information to the server describing what has been input. The server sends packets back telling the client what to output. Although the input protocol is usually not all that sophisticated, the output can contain embedded codes that will cause the client to do things, such as switch fonts, play sound effects and music, or display pictures. For a textual virtual world, the pictures will by definition be static affairs, this being more akin to an illustrated book than a movie. However, it serves to show just how far a text-based world can go without being classified as graphical.

As a rule of thumb, first- and second-age virtual worlds used dumb clients, third-age used intelligent clients, and fourth-age used custom clients.

Fifth-age (graphical) virtual worlds also use custom clients, but display the information a different way. The packets received by the client contain information that can be used by the client to render a scene. This will be either 2D (tessellated) or 3D (first-person), although doubtless “true 3D” (using some stereoscopic device to give depth to a scene) leading to full-blown VR isn’t all that far away.

Thus, to a newbie who neither knows nor cares about the underlying mechanisms, the difference between a virtual world that has moving pictures and one that doesn’t is fairly clear; indeed, it’s probably what attracted the newbie to one rather than the other in the first place. To an oldbie, however, who understands that the fundamental machinery for implementing the virtual world itself (embodied by the server) is much the same whatever the client, the distinction between graphical and textual worlds is mainly an interface issue (albeit a not-insignificant one).

Genre

Another categorization that is important to newbie players but less so to designers is genre ¹.

A newbie will look at a set of virtual worlds and say that this one is medieval Fantasy, this one is Cyberpunk Science Fiction, this one is dark vampire Horror, this one is Greek Mythology, this one is asexual Japanese Anime, this one is stylized Gangsters, and so on.

Again, though, from a design perspective most of the way a virtual world works is independent of genre. Sure, you’re not going to need magic in a world based on Venice in the 16 th century, and you’re not going to need firearms in a world where all the players take on the role of fishes. However, most of the basic functionality isn’t going to change a lot across genres.

Sometimes, though, there are serious implications of genre. Why are there so few Wild West virtual worlds? Because it’s very hard to explain why Joe Newbie’s character can’t enter a shop, buy a loaded six-gun, and empty it into the back of a character that someone else has been playing for five years. They didn’t call those things “equalizers” for nothing ²! Fantasy, Science Fiction, and Horror worlds have fiction-preserving ways out of this, as do ones based another hundred years or more into the past. It’s not the only issue, though—there are plenty more. Following are some examples:

• Crime fiction doesn’t work well as a genre because players don’t want to divulge clues to one another. This means they’re discouraged from communicating; most designers would prefer to encourage them.

• Comedy flops as a genre. You laugh the first time something funny happens, but by the tenth time that same thing happens, it ceases to amuse you.

• Romance doesn’t work for virtual worlds. Sex does, but romance doesn’t. If you start out with the former, you rapidly end up with the latter.

• Lone heroes or heroines don’t translate well into virtual worlds. It doesn’t make sense to have 5,000 people running around who all act like Indiana Jones, Lara Croft, James Bond, or Dr Who. There wouldn’t be room for them in the real world, let alone a virtual one.

These may look obvious to you, but they don’t to everyone ³. Even so, why would any business person want to fund development of an unproven (in virtual world terms) genre anyway? Surely they would go with what they know can be implemented?

Well, the chief importance of genres lies in their ability to attract players. From this perspective, the choice of genre becomes a marketing issue, rather than a design issue (although designers should, perforce, understand their market). Someone behind a glass desk realizes that millions and millions of people have seen the Batman movies and that’s a good enough reason for them to press the issue—irrespective of whether Gotham City would make a good setting for a virtual world.

Fortunately, most designers can avoid the perils of a bad genre. There are plenty of perils of a good genre, too, of course, examples of which will become evident throughout this book. One in particular is the issue of licensing. Licensing is a big topic in the computer games industry as a whole. The arguments are

For:

• People know and trust the brand, so you will get more players.

• You gain the attention of the media and of your competitors.

• You receive free publicity from other license-related products.

• The design work for the overall concept has already been done.

Against:

• You have to pay an invariably large licensing fee and royalties, so your costs rise.

• The free publicity could be bad, or at least not helpful.

• Some accommodation may be needed by the license for gameplay purposes. These could annoy fans or (worse) license-holders.

• The overall concept is what designers like doing the most.

In terms of virtual worlds, the decision whether to license is generally made by someone other than the world’s would-be designers. This imposes creative constraints, because designers have to fit the franchise. Although many license owners are fairly hands-off, others are particularly precious about their worlds and will not consent to anything non-canon no matter how much this stresses the constraints of a different medium. This can pose great difficulties for a designer. Sometimes, even things that are part of the fictional world can be out of bounds, for example the license for The Lord of the Rings would not necessarily cover material mentioned only in The Hobbit, even though they’re set in the same Fantasy world.

Perversely, though, licenses can also be liberating—at least insofar as virtual worlds are concerned ⁴. A sure-fire hit such as Star Wars Galaxies or The Sims Online can take risks that unlicensed games might avoid simply because if they do screw up, it’s not going to kill the game. An innovation with a 75% chance of being a success could well be tried out by a licensed graphical virtual world when it would be left alone by an unlicensed one on the grounds that “There’s a one in four chance this is going to burn a fifteen-million dollar investment? Are you nuts?!”

For a competent design team, a world with a big enough license behind it isn’t going to fail unless they set out to make it fail (for the time being, at least).

Codebase

Related to the idea of genre is that of codebases. To explain how the two are connected requires a short introduction to some principles of virtual world server architecture.

Codebases came about because much of the work that needs to be done to create a virtual world can be re-used when creating other virtual worlds. How much, exactly, depends on the codebase. Codebases are mainly associated with the third age of virtual worlds, although the codebase principle was used as early as MUD1 and there are ongoing attempts to create similar solutions for graphical virtual worlds (Asheron’s Call was designed with this idea in mind ¹).

The most basic part of the software that runs a virtual world is its driver. This has all the usual routines that appear in any sophisticated interpreter, handling things like memory management, parsing, and data structures. Coupled with these are more operating systems-like material such as input/output queuing, time-outs, packet handling, and so on. The result is that the driver can make two foundation concepts available to higher levels of the program: the existence of entities from which the virtual world is to be constructed (for example, objects) and the association of input/output with some of those entities (for example, players).

Above this layer comes what (for historical reasons) is known as the mudlib ². The mudlib defines the physics of a virtual world, which will include things such as mass/weight, timers, movement, and communication, along with higher concepts such as (in a game context) magic and combat mechanisms.

The layer above the mudlib is the world definition. Using the model set up by the physics, world-specific concepts are added. New functionality is associated with these objects that is also consequent on the physics (although not necessarily defined directly by it). The world definition is fully descriptive: It can be used to create multiple incarnations of the world.

Finally, there is the particular instantiation of the world. Actual data items define this individual world, differentiating it from all the worlds that could possibly be defined.

Here’s an example to show how this all hangs together. Suppose we have a world in which (among many other things) a silver key opens a silver casket. The driver defines the concepts of: discrete objects; actions that manipulate such objects; actors (that is, players) that can affect such actions. The mudlib defines the concept of objects that can contain other objects and the conditions under which this can occur. The world defines the concept of caskets and keys, and how using the right one of the latter on one of the former can cause that casket to open. The world instantiation includes an explicit representation for object32 (a silver casket) and object19 (a silver key); the state of a silver casket in the instantiated world depends on whether anyone has opened or closed it with a silver key.

Okay, so these are the various parts of the server:

• Driver

• Mudlib (physics)

• World model

• Instantiation

All codebases must implement these layers, but they don’t have to do it all the same way. Typically, they use a combination of three techniques:

• Hard-code them using a real programming language such as C or C++.

• Soft-code them using a scripting language such as LPC or MUF (Multi-User Forth—used by MUCKs), which is interpreted by the hard code.

• Store them explicitly as data in files that are meaningful to the hard code, the soft code, or both.

How exactly they do this depends on the particular codebase.

Everything that is hard-coded constitutes the engine. For MUSHes and MOOs, the engine is just the driver; for LPMUDs it’s the driver and the mudlib; for DikuMUDs it’s the driver, the mudlib, and the world definition. The advantages of having an engine with higher-level functionality are ease of use and run-time efficiency; the disadvantages are inflexibility and a lack of expressiveness.

Everything that is stored to data files is the database (which may, or may not, be a third-party database with a formal query language and so on). This can be a little confusing, as there can be up to three completely different databases that make up the database:

• Scripting language code

• Templates

• Instantiations

Any or all of these could be used statically (for initialization only) or dynamically (consulted each use, on-the-fly).

Let’s look at these different database forms a little more closely.

A scripting language database consists of the script files that the virtual world needs. For MUSHes, these scripts themselves define the mudlib, the world model, and the world’s instantiation; for LPMUDs, they just define the world model.

A template database contains definitions for objects, from which a world can be constructed. With this kind of set-up, it’s possible to do things like change the behavior of one of the virtual world’s denizens by tinkering with the template from which it was stamped out—you don’t have to change/recompile any code. DikuMUDs use a template database.

An instantiation database (more widely known as a runtime database) stores the state of the instantiated world, specifically those values that persist across server shutdowns and which can’t be generated from either a scripting database or a template database. A good example is player character data, which is usually stowed in a database while the player is not present in the virtual world. Worlds that run continuously will periodically store their entire state in an instantiation database, so they can effect recovery in the event of catastrophic machine failure.

Note that it’s possible for a codebase to incorporate these three databases into one. The object-oriented implementation of MOOs, for example, means that dumping all the data objects (that is, creating a runtime database) automatically dumps all templates and scripts as well, because they are defined as such objects.

Table 1.1 summarizes these differences for a number of codebase families (and, for comparison, some individual virtual worlds). Each component level is described as being code (executed by the computer hardware), script (executed by the code ³), or data (non-executable).

Table 1.1 Codebase Differences

What does any of this have to do with genre?

Well, the way codebases are implemented has an impact on the virtual worlds that they themselves implement. Hard-coded functionality is less flexible but more powerful; soft-coded functionality is quicker to write but slower to run.

Thus, if you wanted a virtual world with a lot of action delivering an intense experience, you’d go for something that favored code (for example, a DikuMUD); if you wanted a virtual world where spontaneity and creativity were important, you’d go for something that favored scripting (for example, a MOO); if you wanted a codebase that had a detailed physics but in a nonstandard setting, you’d go for something that employed code for the mudlib and a scripting language for the world model (for example, an LPMUD).

Very generally, the major codebases ⁴ used for (textual) virtual worlds conform to the following stereotypes:

• DikuMUDs: Adventure-oriented, with a heavy emphasis on combat against computer-controlled foes. They are exciting experiences, but the worlds themselves tend not to change much over time. They mostly have a Fantasy setting, with Science Fiction in distant second place.

• LPMUDs: Also adventure-oriented, but with less emphasis on combat. They are often extended over time. Again, they’re mainly Fantasy, but across a wider range; there are numerous Science Fiction, Horror, and mythological worlds, too.

• MUCKs: Socially oriented, heavily focused on role-playing. These are usually based on some specific work of Fantasy, Science Fiction, or Horror. Those that aren’t often involve original, anthropomorphic animals (furries).

• MUSHes: Socially oriented, mostly focused on role-playing, but occasionally non-gaming in nature. MUSHes tend to have a Science Fiction setting based on books, comics, or movies, with Fantasy some distance behind.

• MOOs: The least games-oriented codebase, responsible for more non-game worlds than all the other codebases put together. Those games it does produce are usually original (rather than derivative) Fantasy that are geared for role-play rather than adventure.

These stereotypes are reinforced by the historical heritages of each codebase. Although it’s possible (for example) to program an exact replica of a MOO in LPC, people who wanted to write a “MOO-like” virtual world would probably just go for a MOO codebase instead. What’s more, people just starting up an LPMUD would probably take someone else’s mudlib as a starting point. Thus, the theme or genre connotations associated with a codebase will tend to be perpetuated as that codebase evolves, meaning that when new versions appear they will usually be refined for their preferred genres ⁵.

Codebases are a common way of categorizing free, text-based virtual worlds (of which there are several thousand); they are not, however, a lot of use in most other circumstances. Almost all graphical virtual worlds, for example, have their own, proprietary codebase. Other means of usefully distinguishing between the different natures of virtual worlds are therefore also commonly employed.

Age

How long does a virtual world typically last? What stops it from lasting longer?

To give you some idea of the longevity involved here, Table 1.2 lists examples of the oldest incarnations in existence of free, text-based virtual worlds.

Textual worlds have the potential to last indefinitely. This isn’t simply because the graphics never date and the bandwidth requirements are low (although those are factors); rather, it’s that they can remain compelling for long enough that people want to stay. Those that fail to attract a critical mass of players tend to die after a few months, but beyond that a virtual world can last for years so long as there is someone around willing to host and administrate it ¹.

Table 1.2 Ages of Extant Virtual Worlds

Graphical virtual worlds haven’t been around for long enough to determine their individual chances of surviving into their dotage, but so long as the graphics are patched or otherwise updated so they don’t fall too far behind the latest norms, the prognosis is good. Original estimates by publishers that virtual worlds would have around five years of life in them before the servers eventually had to be switched off were proven wrong (at least post- Ultima Online).

There’s generally enough gameplay in a graphical world to last a player six to twelve months, which is less (by around half) than for most textual worlds. However, newbies are easier to attract to these larger environments, and therefore the shortfall isn’t important ².

When a free virtual world gets old, it may defy death for years because a rump of players stays with it; overheads would make this unlikely for a commercial virtual world. On the other hand, free virtual worlds rarely continue to exist after their original designers and administrators have lost interest, whereas commercial virtual worlds do. On the whole, it seems likely that commercial graphical virtual worlds have the potential to last just as long as free textual virtual worlds.

The reason age is an important consideration when looking at a virtual world is because it can be used as a measure of the success of that world. While acknowledging that failures can often be attributed to external factors, nevertheless good designs ought to survive and poor designs ought to fail. Age, as a measure of survival, is therefore a measure of success.

This is not a metric that can be applied in related industries. For example, the first computer game to be released on a CD-ROM came out in 1989: Activision’s ³ The Manhole. Few people even remember it now, let alone play it, and yet DragonMUD was launched the very same year and has been played continuously ever since. The default assumption is that although regular computer games have a limited lifespan, virtual worlds (whether games-oriented or otherwise) could last forever. People don’t ask why Meridian 59 ran for four years: they ask why it only ran for four years ⁴.

Player Base

The other way to look at the success or otherwise of a virtual world is by examining its player base. In theory, the better worlds will attract more players, and therefore those that have the largest player bases are the best. In theory….

Actually, there are many reasons why a virtual world may have a large user base (or a small one), with marketing and pricing not insignificant factors. From a designer’s point of view, these have to be taken into account so the essential reasons for a design’s success can be gauged.

The first thing to note, therefore, is that there are different measures of “size” here. If someone visits the same virtual world for three hours every night, should they carry the same weight as someone who plays for two hours every Saturday morning, or someone who only plays for two hours once every three months? Sure, there’s a different business case for each usage pattern (hard-core players are more important for per-hour charging, whereas casual players are more important for per-month charging). However, that doesn’t help when you’re trying to figure out why a particular virtual world is popular so that you can adjust your own designs accordingly. Some of the best virtual worlds are free: Is being free one of the reasons they have a large player base, or would they have even more players if they charged a fee and could afford to advertise themselves?

For commercial games using the same business model, absolute subscriber numbers are an acceptable means of comparison. If game X has 300,000 subscribers and game Y has 100,000, and they both charge around $12 a month primarily to North Americans, it’s not unreasonable to suppose that game X is “better” in some sense than game Y.

For virtual worlds that don’t conform to these parameters, user base size comparisons are much harder. There are basically five approaches:

• Count the number of registered players. This assumes the world registers its players, of course, but not all do. Why is this? Well, when people want to try out a virtual world, filling out forms puts them off. Even asking for an email address can be annoying—who wants to end up on some mailing list when they’re only looking to see whether they like the world? In other words, forcing players to register can be seen as a barrier to entry. You get more newbies into the game if you don’t take down their particulars first.

• Count the number of characters. Every game keeps records of the characters belonging to players. Yes, there will almost certainly be people who have several characters, either attached to the same player account or ones belonging to false identities they’ve set up. The same applies to all virtual worlds, though, so the argument is that it ought to even itself out. The first flaw here is that actually, no, it doesn’t even itself out. Some virtual worlds have entrance qualifications that make owning multiple characters or accounts very difficult—there are role-playing MUSHes ¹, for example, that interview prospective players and have waiting lists for entry. The second flaw (which also applies to the “count the number of registered players” approach) is that some virtual worlds purge player records that remain dormant for a period, but others don’t. A world which has been running for two years that doesn’t clear out unused player records will be able to boast a larger user base than one that has been running for ten years which deletes records that haven’t been accessed for 90 days.

• Count the number of players who access the world per day. This can actually be quite a good measure, although a bad game with marketing will get more suck-it-and-see players per day than a good game with bad marketing. Also, it depends on the day—weekends tend to be busier than weekdays.

• Count the number of simultaneous players. This measure posits that snapshots of usage throughout the day can give a good comparison of user base sizes across virtual worlds. Suppose two worlds each have 80 players in them at 7 p.m. and 120 players at 8 p.m. It seems fair to suggest that they have roughly the same degree of popularity. It doesn’t matter that for one world half the players at 8 p.m. may still be playing from when they were counted at 7 p.m., and for the other some people have played for half an hour and missed being counted at all; indeed, this is entirely the point. Newbies who enter a game and see a lot of players in a world would think that world was popular, irrespective of how long those players spent per session. The main problem with using a count of simultaneous player numbers is that it varies so much depending on the time and the time zones where their players live. Worlds that have 700 players at 10 p.m. might have only 20 at 5 a.m. The figures are so skewed that the mean, median, or mode average is not of any use. Thus, when people do refer to the number of simultaneous players in a world, they tend to give the daily peak (which is better, but not much better).

• Count the number of player-hours. This is perhaps the best measure of the popularity of virtual worlds, but it suffers precisely because of this. Few administrators are going to publish details of how many player-hours are spent in their virtual world per day if this would make them look bad against the bigger games (and it would!). Incidentally, this and the previous measure are both susceptible to the inflationary effects of people who are logged into a virtual world but not actually playing it. Some textual worlds, for example, regularly have over half their players away from the keyboard while their characters remain unattended in full public view.

However it’s measured, the size of a player base has big implications on the design of a virtual world. For example, the main differences between graphical and textual worlds from a designer’s point of view are to do with the huge numbers of players that the former attract, rather than the fact they have pictures.

Size, as they say, isn’t everything, though. Also important are the demographics of the player base—and not just so marketing people can sell to advertisers and sponsors. Those are actual demographics; when a game is being designed, the target demographics are important. The more designers know about the kind of players that are required, the better they can account for this in their design. A virtual world aimed at wealthy professionals would be different to one aimed at impoverished students. A virtual world aimed at children would be different to one aimed at bored homemakers. A virtual world aimed at everybody would be different to one aimed at just the design team (although many design teams don’t yet seem to have figured this one out).

That said, demographics are only statistics, and they don’t always tell the designers of virtual worlds what they need to know. It’s clear that virtual worlds which are perceived as computer games—and most of them are—seem to attract different groups of people than their regular-game cousins; there is, however, wide disagreement among analysts over the actual figures ². The same overall trends are nevertheless present within individual surveys (which compare like with like), and it’s probably fairly safe to say that in general:

• Virtual world players are older than console gamers, and cover a wider age range than PC gamers.

• Virtual worlds attract proportionately more female players than do console or PC games.

This information is normally interpreted in one of two ways: Designers should make their games more inclusive, so as to further appeal to the mass market; designers should make their games less inclusive, so as not to alienate their core audience.

Actually, though, it’s possible to appeal to both groups of players. Whereas marketing people want to know who is playing, designers are more interested in why they are playing. Players’ expectations and desires are more important to designers than their ages, incomes, and geographic locations; if designers can model how the different player types interact, and design their virtual world such that these interactions are both stable and intrinsically interesting for participants and observers, then demographic information becomes purely a marketing tool. If you want more female players, advertise to women; if you want more older players, advertise to senior citizens; if you want more teenagers, advertise to teenagers. It shouldn’t matter who plays, so long as there are checks and balances within the virtual world itself to ensure that no one playing style can come to overwhelm the others.

Fortunately, models for representing playing habits independently of demographics do exist; they are discussed in Chapter 3, “Players.”

Dimensions: Change and Persistence

So how do designers categorize virtual worlds? And why would they want to categorize virtual worlds anyway?

Categorizations make explicit some of the choices available to designers. It’s all too easy to begin designing a virtual world having already made key decisions without even being aware of the fact. By laying out the options available to them, not only can designers be aware of what options are available to them, they are also forced to look at their solutions more analytically. Categorizations are particularly useful for seeing what the various combinations of design decisions imply about any resulting virtual world.

There are many high-level judgments that designers must make when considering the nature of the virtual worlds they wish to create—so many, in fact, that they merit an entire chapter of this book to themselves (Chapter 4, “World Design”). Most of these options are interdependent in some way, which makes them unsuitable as categorizations; others are so disjoint that they say nothing general beyond their own context.

Two, however, do combine to good effect: the degree to which a world can be changed by its players (sometimes called player impact); the degree to which changes persist over time. This model, originally devised by Raph Koster and Rich Vogel ¹, elegantly exposes what is perhaps the most important question designers must face, which determines the very soul of their creations: Whose world is it?

The two dimensions—change and persistence—are natural progressions from some of the differentiators applied to codebases. Players of MOOs all have full builder privileges, meaning they can add to their virtual world almost indiscriminately (they have direct access to the scripting language, which controls everything above the driver level). Players of AberMUDs have no such capability to change their world. Similarly, in Ultima Online the entire world and everything in it persists indefinitely—you can drop an object in your house and it will still be there weeks later. In MUD1, everything except the player characters’ details is periodically reinitialized.

The issue is one of content. Although developers throw around the term like everyone knows what it means, it’s actually quite hard to pin down. Essentially, content is that which the world provides to hold players’ interest. If players are consumers, content is what they consume.

As an analogy, content in virtual worlds is like what stand-up comedians call “material.” They write a routine stringing together jokes, observations, and witticisms, which they then deliver to an audience. If they’re really good, members of the audience may come back time and time again, but most won’t. After all, if you’ve heard a joke once, it’s not really as amusing when you hear it a second time; their material isn’t sticky. For performances in a 2,000-capacity theater, a single routine can last a comedian for half a year; on television with an audience of 20 million, it’s pretty well dead the moment it has been used.

Content in virtual worlds generally means giving people things to do, places to do it, and things to do it to. The mere presence of other players can be considered as a form of content, being as it is the primary reason most people play. Designers can’t design players, however, just facilitate their interactions; this kind of content is therefore said to be intangible.

Virtual worlds have another major draw, however, that of the virtual environment itself. This, designers can change directly; it’s tangible content. When designers talk about adding content to a world, they generally mean the tangible sort: that which can be coded or scripted, rather than that which emerges from interactions.

The combination of players and world gives rise to content so potent that people can be quite willing—indeed, positively enthusiastic—to repeat an experience over and over again. This makes virtual worlds incredibly sticky—much stickier than related leisure-time pursuits such as books, computer games, movies, and television. Only music is comparably sticky, with many people happy to listen to their same, favorite albums often and for extended periods ².

Players do nevertheless (as individuals) consume content. So where does new content originate? In some virtual worlds, only from the interactions between the players: MUD1 has had only minor changes to the virtual world since 1985, yet people still play it to this day. MUD1, however, is scaled just right for the number of players it attracts. For large virtual worlds such as EverQuest, there are far more people wanting to play than there are things for them to do. As players become increasingly practiced at the game and want to try out the more demanding challenges, there is greater demand for high-end experiences. Therefore, new tangible content (in the form of locations, monsters, treasure, and so on) must be added so that there’s enough around for everyone to eat their fill.

This kind of content can be added in one of two ways: within the context of the virtual world (for example, a nobleman hires a gang of workers to build a castle) or without (for example, a player or designer inserts a castle using a development tool). The distinction is quite marked: Does the world make the changes, or do the players? Put another way, do players have to prove new statements from a given set of axioms, or do they get to add axioms directly?

Some virtual worlds allow only partial access to the full majesty of their scripting language (perhaps through permission restrictions, perhaps through the use of a separate “builder language” itself implemented in the scripting language like regular commands). You might, for example, be able to create objects but not locations, or locations but not commands. In practice, though, these are one step beyond the point of no return: Either you can change the world using independent meta-actions (which is called building) or you can’t (in which case any changes must be through actions within the context of the virtual world itself). Thus, the measure of how much change a virtual world allows depends on the criteria that determine who gets to have the builder privileges.

For some worlds, for example most MOOs, everyone can build; for others, such as the heaviest role-playing MUSHes, only the world’s guardian coders can build (even though the architecture is as open as a MOO’s, and therefore anyone could in theory be allowed to build). In between these two extremes are worlds that allow changes by wider groups of coders/designers, by privileged appointees, by highly-experienced players, by players who have been playing for a certain time period, by players who pass an interview, by anyone who asks; it’s not quite a spectrum, but it’s close.

The other dimension under consideration here, persistence, is also more discrete than continuous. Persistence relates to the amount of a virtual world’s state that would be retained intact were the whole system to be shut down and restarted. All virtual worlds have some degree of persistence (after all, it’s part of the definition of the term “virtual world”), but exactly what they persist varies.

At the most basic end of the scale, all that a world persists is its initial state and the records for individual player characters. AberMUDs are like this. The next step involves persisting what the characters were carrying with them at the time (DikuMUDs), certain classes of objects such as player characters’ corpses (EverQuest), and so on all the way up to the entire world state (Ultima Online) and the entire world state plus all incrementally-added functionality (MOOs).

Persistence is more dependent on the available computer resources than is change. Put simply, the more you want to save, the longer it will take to save it and the more space it will take up. This is not, however, the usual reason why designers might prefer their world to have a relatively low degree of persistence. Adventure-oriented games in particular can have very complicated, inter-related tasks and puzzles that have far-reaching, game-wide effects; this makes them effectively impossible to disentangle from the state of the virtual world—you can’t unlaunch a rocket or unexplode a bomb. Designers want to be able to reinitialize these puzzles, because if something has taken perhaps weeks to implement, they don’t really want it to be single-use for the benefit of only a handful of players.

How can you reinitialize something that has all-embracing consequences, though? Reset strategies are discussed in detail in Chapter 4, “World Design,” but for this particular problem the short answer is that you can’t really reinitialize anything with such a large root system unless you initialize the entire virtual world. Full persistence in this situation would be a bad thing, because persistence is all about not reinitializing. Thus, designers of certain types of virtual worlds can have good reasons for not wanting to persist everything across reboots.

Okay, so let’s see how these concepts of change and persistence interact. Table 1.3 shows a six-by-six grid, with persistence increasing left-to-right and access to content creation increasing top-to-bottom. Major codebases and a number of important individual worlds are positioned in the grid depending on how far they satisfy the persistence and change criteria listed at the heads of the columns and rows, respectively.

Table 1.3 Persistence Versus Change

The first thing to notice is that there’s an apparent line running diagonally from the top left to the bottom right, with most of the virtual worlds appearing on or above it. What this says is that, in general, there’s a relationship between the number of people who have the ability to build things in a virtual world and the persistence of their creations. Note that this alone doesn’t say whether persistence implies building access or vice versa, just that the two go hand in hand.

Above the diagonal, fewer groups of people can build in the world, but what they build lasts just as long as for more relaxed regimes. Below the diagonal, more people can build, but what they build doesn’t last as long as for more open architectures. Given that there are plenty of virtual worlds above the diagonal and few below, we can deduce that increased persistence doesn’t really imply increased numbers of builders, but that increased numbers of builders does perhaps imply increased persistence. In other words, the more people who can add content directly to a virtual world, the more of that world will tend to persist.

Looking at the individual worlds in the grid, most commercial games appear on the horizontal line that indicates content can be added by trusted (because they’ve signed a contract) players but not automatically by anyone who happens to reach some world-defined level of expertise. Given that player-created tangible content is believed by many designers to be the future of virtual worlds, this reluctance to cross the line could present something of a problem. The topic is discussed at length in Chapter 5, “Life in the Virtual World.”

Okay, we’ve learned something, but what has any of this to do with the soul of virtual worlds?

Let’s examine Table 1.3 another way: as quadrants of nine squares each.

The top-left quadrant consists exclusively of adventure-oriented virtual worlds. The designers have created a world, and they’re strict about who can add to it. Whatever content changes they do allow while the world is running will only persist across a reboot under very particular conditions. Everything in the world is how it is for a reason, and has been constructed to be immediately captivating. The virtual world is so rich and complex and its components so interdependent that players’ changes aren’t ever going to be able to do it justice. Sure, players can make changes to the world through their actions within the world, but those changes don’t ever last for long because they disappear whenever the world is reinitialized. The world entirely belongs to the designers, like a movie entirely belongs to its director; it has little life beyond that of its own.

The top-right quadrant also emphasizes the integrity of the world. Only trusted people get to make changes. However, the world itself is more open-ended, and changes will persist for a long time. Whereas a volcanic eruption in a DikuMUD would last until the next reboot, in Asheron’s Call it would lead to a more or less permanent change to the environment. Some of the things the designers put into the world are not immediately interesting, but like seeds they may grow into something special later (or they may not). Players can make changes through in-context actions that have lasting effects. The world still belongs to the designers, but when players start to live in it, it gets a chance to evolve in ways the designers hadn’t necessarily considered.

The bottom-left quadrant is almost empty, with only MUD2 making an appearance. The world design is so tight that little persists from one reboot to another, but in between reboots those players who are of sufficient experience to understand the design can create tangible (albeit ephemeral) content. The designers ³ allow certain players to take control of the virtual world in a major way, but they wrest ownership back with every reboot.

The bottom-right quadrant contains almost entirely socially-oriented virtual worlds (with LPMUDs being the only exception). These often have little or no “game” aspect, and building is considered part of the fun. The original designers only create the core of the world and the means by which it can be extended; thereafter, they hand it over to the players to do with as they wish (although there’s a problem if what the players wish for is that the designers will take back control, as they famously did with LambdaMOO).

So, following this analysis we are at last able to answer the original question: Whose world is it?

• In the top-left quadrant, the world belongs to the designers.

• In the top-right quadrant, it also belongs to the designers, but players have a stake because the changes they make through their in-world actions can change the landscape.

• In the bottom-left quadrant, the world still belongs to the designers. Players are loaned world-changing powers, but come midnight their carriages turn back into pumpkins.

• In the bottom-right quadrant, the world belongs to the players.

When designers begin work on a new virtual world, the question of who is to own it should be uppermost in their minds: It really does encapsulate the soul of the world! Of course designers will have a vision of their world, and of course they will consider themselves to be better designers than are their players (not unreasonably so, despite what players ⁴ may think). Players are people, though, and need to be thought of as such. How much are the designers willing to trust them to add good new content?

• Not at all? Then go for low persistence and low change.

• A lot, if they stick to the rules? Then go for high persistence and low change.

• A lot, but not for long? Then go for low persistence and high change.

• Implicitly? Then go for high persistence and high change.

Perhaps the best expression of this difference is seen in the comparison between the early advertising slogans of Verant (makers of EverQuest) and Skotos (makers of Castle Marrach):

• Verant: You’re in Our World Now.

• Skotos: Why Yes, I am God.

Skotos’ games have only a fraction of the players that EverQuest has, but their slogan sells more T-shirts.

Influences on Virtual Worlds

Virtual worlds are not a self-contained phenomenon, insulated from the real world. Trivially, the hardware on which they run is part of the real world and therefore they themselves must be considered a part of it. However, there are other ways in which the real world can influence the virtual. From a designer’s point of view, the most important of these are those that also involve the construction of imaginary—if not quite virtual—worlds. In practice, this means books, magazines, movies, television series, and (perhaps most importantly) role-playing games.

Printed Works

The single most important influence on virtual worlds from fiction is J. R. R. Tolkien’s The Lord of the Rings ¹ trilogy. Although it would be of huge significance merely for having established the genre of High Fantasy, its ultimate worth lies in its depiction of an imagined world. It’s not the particular world it describes that is momentous (although Middle Earth is indeed classic source material for people writing new text-based games); rather, it’s that creating a fully realized, make-believe world was shown to be actually possible. Prior to The Lord of the Rings, worlds of such depth were practically unknown.

The word “practically” is used because there were immensely detailed imaginary worlds before, but they evolved over centuries and had many authors. Folk tales, while perhaps originally having some basis in fact, nevertheless changed over the telling, drifting toward some popular shared setting that gave listeners a context. Individual stories had a place and time, so no background had to be given, and they in turn made a contribution to enriching the overall canon. These collections of tales set in what were to become shared fictional worlds gave rise to such well-loved anthologies as Britain’s Arthurian Legends, the Middle East’s 1001 Arabian Nights, and China’s The Water Margin.

The other great source of imaginary worlds is religion. This is a little trickier to discuss, because whereas few people today would disagree that the worlds of Greek, Roman, Norse, and Celtic gods were completely imaginary, the suggestion that there might be fictional elements in the Jewish Torah, Roman Catholic Apocrypha, or Hindu Ramayana—to name but a few—is just asking for trouble. The issue of real-world religion in virtual worlds is debated in Chapter 8, “Coda: Ethical Considerations;” for the moment, it’s sufficient to note that religion can be a source of imaginary worlds comparable in breadth and depth to those that are accepted myth, but you’d have to be brave or stupid to use a living one.

What J. R. R. Tolkien showed was that imaginary worlds did not have to emerge from amalgamations of the ideas of many people; it was possible for an individual to construct a believable world from first principles (although he did draw on many tropes from existing myth as part of Middle Earth’s architecture). The sheer amount of vision he produced, maintained over six books in three volumes, is breathtaking. It’s small wonder that the imaginative possibilities raised by The Lord of the Rings are as much an inspiration for designers of virtual worlds today as they were for the authors of MUD1.

That said, the actual content of MUD1 wasn’t drawn from Middle Earth. The game’s terrain was English and the inhabitants were pure fairytale—it had “dwarfs” rather than “dwarves,” for example, and no elves, orcs, nor hobbits whatsoever. There was a fictional influence, but it was due to the sword and sorcery of Robert E. Howard’s Conan the Cimmerian ² series rather than The Hobbit ³. Long novels aren’t as good as action-oriented short stories for evoking the heart-in-your-mouth style adventure that MUD1’s world was intended (among other things) to deliver.

Beyond The Lord of the Rings, the influence of fiction on virtual worlds is three types:

• Direct. The virtual world is an implementation of a familiar fictional world such as Robert Jordan’s The Wheel of Time ⁴ or Terry Pratchett’s Discworld ⁵.

• Partial. The virtual world is inspired by a particular work of fiction or a genre that is derived from one. It might have the same “mutant academy” idea of Stan Lee and Jack Kirby’s X-Men ⁶, but let you create your own superheroes.

• Indirect. The virtual world implements or is inspired by some other work which itself is an adaptation of a book or comic series. A virtual world design team might decide to adopt the Dungeons & Dragons magic system without necessarily knowing that E. Gary Gygax and Dave Arneson (authors of Dungeons & Dragons) themselves adopted the idea from the novels of Jack Vance ⁷.

Given the choice, most professional virtual world designers would prefer to design their own, original virtual world. They have good enough imaginations that they don’t need to steal from fiction (yet are regularly asked “where do you get your ideas from?” as if they couldn’t just think them up unaided). Like a scriptwriter adapting a book for the big screen, designers working to a license might genuinely enjoy what they’re doing but, deep down, they’d rather be exploring their own imagination than someone else’s. For this reason, designers tend to approach novels analytically, deconstructing them for their form rather than their content.

There is, however, a fourth category of fiction that has subject matter in itself of use to designers. These are the books that are about virtual worlds; not in the pedagogical way that this book is, but far more speculatively. Books of this kind are of great interest to the designers of virtual worlds because they actually involve consideration of design issues. Suppose that all implementational and commercial problems have been solved, and people can physically visit invented worlds from reality: What might they find there?

In early examples of the genre, such as Larry Niven and Steven Barnes’ Dream Park ⁸ and Vernor Vinge’s True Names ⁹, the authors had not encountered virtual worlds ¹⁰ and were therefore writing from a position of pure conjecture. Nevertheless, they raised several issues about the design of virtual worlds that have proven to be quite prescient. Dream Park, for example, asks questions about narrative and ownership that were to be raised again some 20 years later when the debate about ongoing content provision for fifth-age graphical virtual worlds began in earnest. True Names made the distinction between player and persona (the real-world identity of an individual being a persona’s “true name”) and explored some of the consequences of identity masking that this enables.

When Cyberpunk brought new meaning to the term “cutting edge” in the Science Fiction literary scene of the mid-1980s, the future of virtual worlds immediately seemed laid out with neon clarity. In Dream Park, virtual worlds were glorified real-world theme parks; in True Names, they were stored in computers that people reached through electrode “portals” suckered to the head; by William Gibson’s tour de force novel Neuromancer ¹¹, access was through neural jacks making direct electronic connections to the brain. Surely this was to be the ultimate in imaginary experience made real? The notion of cyberspace—data represented as imagery within a shared virtual environment—burst into public consciousness. Virtual worlds were merely a manifestation of virtual reality; the interface not only brought the message, it determined it. The syntax shaped the semantics.

It was easy to forget that Cyberpunk fiction was just that: fiction. It was predictive in the cautionary sense, showing how things might become, not how they would become. Part of Cyberpunk’s agenda was to show that although technology offers a way forward, people could corrupt it for their own ends. That which has the potential to bestow liberty can be twisted to the cause of oppression or anarchy. Thus, it was in the interests of Cyberpunk authors to show cyberspace as a slick, high-tech victory of form over substance, hip and happening yet shallow and soulless but for its dark, in-shadow periphery. The cold, objective way that virtual space was depicted (as a network of freeform, three-dimensional statistical symbols) conveyed the impression that getting to cyberspace was more important than what was there when you arrived.

Many people find the neurotechnology envisaged in Neuromancer exciting, because (were it ever available) it would provide a means of entering a virtual world totally and completely ¹². It is unlikely, however, that any virtual world they did visit would look like a classic Cyberpunk vision unless the designers deliberately took such as their model ¹³. This was acknowledged in William Gibson’s later cyberpunk novel, Idoru ¹⁴, which distinguished between network-as-medium and network-as-place by explicitly referring to virtual worlds as MUDs.

Cyberpunk teaches designers a number of valuable lessons about the sociology and psychology of players and the responsibilities of developers. Virtual worlds are not insulated from the real world; they can’t be regarded as solely the purview of their designers, publishers, or even players. Their influence extends into the real world, and therefore the real world extends into them. Ultimately, though, the relationship is one-sided: The real world always wins in the end.

Cyberpunk was the evangelizing prophet of virtual reality, but, once the hype died down, other authors were able to look at the new reality and use that as their starting point for speculative work. Media darling LambdaMOO was an obvious first point of contact for people considering writing speculatively about virtual worlds, although in itself it was hardly representative of what was already out there.

Perhaps the most impressive of those novels first to be informed by extant virtual worlds is Tad Williams’ Otherland ¹⁵ series. This monumental ¹⁶ work traces the fortunes of a number of disparate individuals accessing the “Otherland” virtual world of its title. Among the many things the series gets right that Cyberpunk got wrong are

• Client/server model dynamics. The gradual shift in importance from how powerful the client hardware is to how powerful the server hardware is.

• Multi-faceted worlds within worlds. This is typical of MOOs and other builder-centric codebases (such as the book’s “Otherland”).

• Inter-world object mapping, so that taking an object from one sub-world to another replaces it with a functional equivalent (an analogue). This is indeed how designers intend to handle transfers of objects and characters between virtual worlds.

• Player attitudes to gender-presentation betrayal. When people say they’re something they aren’t and get in too deep.

• Understanding of immersion (the sense of being “in” a virtual world). Cyberpunk mistook visualization for immersion: The two are not the same.

• Virtual worlds modeled on the real world. If what you see looks and behaves like reality, you feel you’re “there” more than if it looks and behaves like a gridwork of platonic solids.

• Recognizing that people have expectations of degrees of reality within the virtual world. Fulfilling these expectations leads to increased immersion and denying it leads to decreased immersion. People don’t want worlds to have anthropomorphic content merely because they feel more comfortable in them that way.

• The difficulty of distinguishing between computer-generated characters in the virtual world and ones under the control of human beings, and (more importantly) the consequences of not being able to tell. People have already been fooled into believing that virtual players are real ones for extended periods; many more will undoubtedly follow.

Of course, the series also gets some things wrong of its own account. The attitude that characters (in the first book) have to persona death, for example, is at odds with how people in the real world tend feel on the subject (real people are far less stoic). On the whole, though, it offers much for virtual world designers to ponder. Besides, no designer could possibly criticize a book that names a virtual mall after LambdaMOO and has the opening line: It started in mud, as many things do ¹⁷.

Film and Television

Most original fictional ideas appear in magazine, comic, or book form first, because these are far less expensive to produce than movies or TV series (or even stage plays). Many of the top-grossing movies, year after year, are based on stories or characters that first appeared in print.

Unsurprisingly, the influence of film and television on virtual worlds falls into the same categories as does that of books and comics:

• Direct. Star Wars Galaxies is set in the Star Wars ¹ universe. There are textual virtual worlds based on Buffy the Vampire Slayer ², The Lion King ³, Battlestar Galactica ⁴ and Tron ⁵—to name but a few.

• Partial. There are virtual worlds derived from the concept behind A Bug’s Life ⁶. Toontown ⁷ is a graphical world set in the Disney cartoon universe.

• Indirect. The original Sailor Moon ⁸ comic books were concordantly made into an animated series, which in turn was implemented as a virtual world (indeed, several of them).

• Meta. The Truman Show ⁹ says much about virtual world design, of narrative, and of the nature of reality.

Because of the crossovers between the media, the treatment of virtual worlds in film and television has paralleled that of novels, from the theme park beginnings of Michael Crichton’s Westworld ¹⁰ to the neural implants of the Wachowski brothers’ The Matrix ¹¹. Superficially, then, it appears as if books and movies will always tend to explore the same themes. This is not, however, necessarily the case.

It is the nature of books to tell and films to show. Thus, Westworld showed damaged robots being repaired for re-insertion into the virtual world (identifying what later came to be known as spawning), whereas Dream Park told what it was like to play (presaging the “it’s just a game” arguments that still surface today).

By showing, a movie or TV series can present a situation in a direct manner, whereas a book (or even a comic) would take time to tell the same thing. If you see an image on a screen, it can convey in an instant what might take a minute to read. There are limitations on what can be shown, though, that don’t apply to what can be told (you can’t really “show” thoughts, for example, just the consequences of people having had them). Books are about imagination, whereas films are about sensory experience. Films concretize what books visualize. It’s not an inconsistency of law that heavily pornographic movies are illegal but heavily pornographic literature isn’t: With films, what you see is what you get; with books, what you get is what you see.

For designers of virtual worlds, one of the most important tropes from film and TV that would not work as well in print is the holodeck from Gene Roddenberry’s Star Trek: The Next Generation ¹² and spin-offs (Star Trek: Deep Space Nine ¹³ and, in particular, Star Trek: Voyager ¹⁴). The holodeck is a programmable environment with which real (in the context of the TV show) people can interact as if it were (their) reality. For example, a character might create and then enter a simulation of Victorian London, assuming the role of Sherlock Holmes. This works on the screen better than it does on the page because the world and the character’s degree of immersion in it are immediately apparent; they require no unveiling. The situation is at once accepted, and the episode can progress to examining the issues it suggests. This can’t happen in a book unless you’re already familiar with the concept of holodecks from the TV show.

Holodecks, although occasionally used for serious purposes such as testing engine designs, are primarily viewed within the Star Trek universe as an entertainment medium. From this perspective, the main lessons to be learned from holodecks are

• They allow characters to express sides of themselves that they may not be able to do in reality ¹⁵. One captain may play a low-life film noir detective; another, a romantic lead. The holodeck is a liberating, albeit temporary, release from reality.

• They distinguish between undirected and directed environments. A representation of a bar where characters can go to hang out would be an example of the former; an interactive “holonovel” to prevent a 1930s-style evil emperor from ruling the galaxy (while rescuing a feisty princess) would be an example of the latter.

• Creating virtual environments is in itself a fun activity.

• The representation of a living person without their permission is rude, but not forbidden. This is just as well, given that they always find out.

• They are a magnet for alien life forms unable to distinguish between the false reality presented by the holodeck and the true reality in which the holodeck exists. It’s a metaphor for people who believe everything they see on TV ¹⁶.

• They malfunction to the extent that they pose a greater threat to the health of crewmembers than a direct hit from a photon torpedo to the ship’s hull with all shields down. This is as a consequence of Star Trek itself being subject to the same laws of drama that it imposes on its holonovels.

Many of the virtual worlds that exist today are, in some ways, more mature than Star Trek’s vision of the future; this is particularly the case with regards to the social norms that have evolved through their use. However, where the concept of the holodeck is most useful is in thought experiments: Were holodecks to exist, what new areas of narrative, performance, and self-awareness would they enable? Are these desirable or undesirable consequences? Could these new areas already exist—or be made to exist—in some form, using the technology of today?

The difference between showing and telling is not the only one between books and movies. Equally important is that, in general, movies will get more exposure (and will therefore be more influential) than books. This means they will provide a greater cultural touchstone. Few people have read Philip K. Dick’s short story We Can Remember It for You Wholesale ¹⁷, but the movie it inspired, Total Recall ¹⁸, grossed $119,394,839 in the United States alone in 1990 ¹⁹. The movie might cause virtual world designers to consider how to stop player involvement derailing prewritten plot lines; the short story won’t, simply because few—if any—designers have read it.

In the same way that some worlds work better as books than on the screen (for example, C. S. Lewis’s Chronicles of Narnia ²⁰ series) and some work better as movies than in print (for example, George Miller and James McCausland’s Mad Max ²¹ series), some virtual worlds work better in text than in graphics and vice versa. The reasons for this are explained in Chapter 4, but for now it’s enough simply to note the fact because it leads to an interesting analogy (that most readers will doubtless have figured out already).

Basically, it can be constructive to regard textual virtual worlds as being like books, and graphical ones as being like movies. Books and textual worlds are cheap to create, more amenable to risk-taking, and they talk to the imagination; movies and graphical worlds are highly expensive productions, less inclined to experiment, and they talk to the senses. Similarly, few textual virtual worlds have the same profile as graphical ones, so when people see that Star Wars Galaxies has a hairdressing skill and think it’s cool, they won’t necessarily know that text-based games like Castle Marrach have had the same thing for years. They just think Star Wars Galaxies is better than EverQuest.

So it goes.

Books and movies, well known and respected art forms that they are, nevertheless rarely contain practical information that virtual world designers can actually use. They can suggest genres, directions, issues, problems, and (occasionally) solutions, but not in any great detail. It’s like using a Canaletto painting of Venice as source material for a novel set in the city in 1740: You may get a great sense of La Serenissima’s atmospheric grandeur, and may in time be able to construct an impression of what everyday life there might have been like, what challenges the people faced; on the whole, though, a resident’s diary would be far more useful for your purposes.

So is there an equivalent to the resident’s diary for virtual world designers, for those times when realism is preferred to idealism?

Yes, there is: role-playing games.

Role-Playing Games

Role-playing games (RPGs) have always had an important influence on virtual worlds.

Role-playing is basically acting, and therefore has its roots in ancient history. It has many uses beyond theatrical expression (for example in psychology, education, and training), but it wasn’t until the 1973 arrival of E. Gary Gygax and Dave Arneson’s Dungeons & Dragons (D&D) ¹ that the concept of role-playing games finally crystallized. Dungeons & Dragons was a fusion of traditional tabletop wargames and interactive storytelling, in which one player (the referee, later to be known as the Dungeon Master/Mistress (DM) or Games Master/Mistress (GM)) designed an imaginary world into which a number of players would go. The referee would describe what the players could see, hear, feel, and so on, and the players would explain what they (or, more correctly, their characters) would do. The referee would then roll a few dice to determine the consequences of these actions in the context of the imaginary world, which would in turn cause the players to try new actions, and so on. Virtual worlds are very close to tabletop RPGs except they have computerized referees.

Being games, RPGs need rules. Because the referee has to construct the imaginary world, these rules do not only describe how to play the game but how to create a game world—which may entail writing new, world-specific rules. Thus, these are actually rule systems. Although referees can and do create vast campaigns (as these worlds, or partial worlds, are known), it takes a lot of time to do so. For this reason, referees may use rule sets that have been adapted for their chosen genre (imperial Rome, horror, far future, wild west, whatever) and use these as a starting point. Others will acquire predefined modules, often written by professional games designers, which define a self-contained sub-world. These sub-worlds have explicit goals for the players and solution paths appropriate to the players’ characters’ abilities.

Some of the genre-specific information researched for these games can save valuable time for the designers of those virtual worlds that are set in the same place or period (which, as tabletop role-playing games tend to draw on the same fictional and historical influences as virtual worlds, is often the case). Indeed, the information they provide can be so well organized, accurate, and complete that it can benefit people not remotely interested in role-playing games or virtual worlds. Anyone wanting to write about, say, the golden age of piracy, should seriously consider buying a specialist rule set for that genre as a starting point ².

Virtual worlds can therefore benefit from tabletop RPGs in four important areas:

• The basic rules of the game.

• The rules for creating an imaginary world.

• Rule sets for particular genres.

• Modules for actual game experiences.

It is no coincidence that this reflects well the driver/mudlib/ world model/instantiation breakdown of virtual world codebase architecture; the two systems really do have a lot in common. They even have branches at some of the same points: Steve Jackson’s GURPS ³ system, for example, is LPMUD-like in that it provides common gaming and creation rules for different environments (feudal Japan, swashbucklers, time travel, you name it), whereas Kevin Siembieda’s Rifts ⁴ system is more MUSH-like in that it ties multiple sub-worlds into a single coherent whole.

Virtual worlds borrow from RPGs at all levels. MUD1’s level system came from D&D, as a neat way to give players intermediate goals. The DikuMUD codebase draws heavily on first edition Advanced Dungeons & Dragons (AD&D) and Bioware’s reincarnated NeverWinter Nights implements the 3 rd edition AD&D rules very faithfully indeed. There are textual worlds set in environments designed for role-playing games, such as Mark Rein Hagen’s Vampire: The Masquerade ⁵. There are even virtual worlds based on specific game modules, for example city campaigns for Ed Greenwood’s Forgotten Realms ⁶.

Although pencil-and-paper role-playing games can be used as a means to “dry run” virtual worlds, it is a mistake to believe that everything in the one is always transferable to the other. The two may be similar, but they are not identical; where they differ, the differences are profound.

The human referees of role-playing games have an intelligence that the computer referees of virtual worlds do not. They can create new content immediately, and are responsive to the needs of their players. What they lack, however, is speed, memory, and bandwidth. A human-moderated world may be more vivid than a computer-moderated one (because its level of detail can be tailored to the moment), but it doesn’t work the same way as the real one and is thus ultimately less convincing ⁷.

What’s more, players of a human-moderated world can exert out-of-context influence over the referee and each other. If a squid picks up a sword and starts fighting with it, a player might say to a human referee, “Hey, squids can’t do that!” The referee can reply appropriately to the situation. For example: “If you check the manual, page 54…” (correcting a misconception); “this one can” (mild hint); “perhaps it only looks like a squid?” (stronger hint); “some swords can control their wielders, you know” (misdirection); “you’re right, its balance would be all wrong” (recognition of mistake); “you spot a thin wire attached to the sword” (taking the objection as an implicit command for the character to look closer).

If a squid picks up a sword in a computer-moderated world, well, the squid picks up the sword. The virtual world is as inviolate as the real one: Waving your fist at rain clouds while asking your deity of preference what you’ve done to deserve a soaking may make you feel better, but on the whole you’re not going to get an apology ⁸.

So what developments in human-moderated worlds don’t transfer to computer-moderated (that is, virtual) worlds?

• Anything subjective. Alignment does not travel well, because a computer can’t quantify the concepts involved. Can a “good” character attack a player who boasts of being a thief? What if they’ve seen the character steal something? What if the theft was of an object that had itself been stolen from the thief? What if the thief originally bought the object from a fence, who got it from another thief? Human beings can make value judgments, but computers are hopeless at it.

• Anything individualistic. Most modern role-playing games are classless and skills-based. They let players decide the directions in which to advance their characters. Most virtual worlds have classes, races, and guilds to coerce players to band together. This helps players who don’t know each other in real life to bond; it also serves as a means to introduce goals into player activities. It promotes role-playing ⁹.

• Not everything theoretical. Although the general principles of world design and role-playing have been analyzed over the years, and a good deal of what has been discovered is indeed applicable to virtual worlds, not all of it is. The danger here is that the studious virtual world designer will miss the boundary and go too far (for example, in creating believable non-player characters) or emphasize the wrong thing (for example, plotting over atmosphere).

• Anything meta-interactive. Players can interact with a virtual world ¹⁰, but they can’t do so beyond its context. Builders can breach the context, but they can only act on the virtual world, they can’t enter any kind of dialogue with it. Players of diceless role-playing games like Erick Wujcik’s Amber ¹¹, on the other hand, interact with the referee (that is, the world) the entire time.

So long as these distinctions are not important to the rule system, a transfer is possible. Gary Gygax’s RPG Lejendary Adventure is now being developed as a virtual world ¹². It is possible.

Transfers (and non-transfers) of expertise in the opposite direction, while perhaps important for the designers of role-playing games, are of little consequence for the designers of virtual worlds; they are therefore not considered here, except to note that there is a significant overlap between the “hard core” virtual world players, the players of single-player role-playing games such as Bioware’s Baldur’s Gate, and the players of pencil-and-paper role-playing games ¹³.

It should be mentioned that there is a third option for role-playing that calls on neither computers nor human beings to moderate the world. This is live-action role-playing (LARP), where people use the real world to model a fantasy world ¹⁴. In Dungeons & Dragons, you roll dice to see if your arrow hits an enemy; in Dark Age of Camelot, the computer calculates the odds; in a LARP, the flight of the (safety-tipped) arrow through the air is the only measure of success. Things the game wants to have that the real world doesn’t are represented by symbols. For example, casting magic spells might be represented by throwing flour or birdseed at the target, or by passing a small token.

The influence of LARP on the design of virtual worlds has not been great, mainly because of the relatively small numbers of people involved. This is a shame, as there are many different LARP systems of potential interest to virtual world designers, offering practical illustrations that ground the mere speculation of, say, Dream Park. Virtual world designers are, on the whole, aware of LARP, but not appraised of it. They’re consequently more likely to talk to actors rather than LARPers when they have their next brilliant idea to pay people to spend eight hours a day in character while role-playing personalities in their worlds. This is another shame.

Why isn’t LARP more popular? Practical matters of organization aside, the main problem is that content in LARP is thinner and more expensive than in tabletop role-playing games or virtual worlds. If the referee of a tabletop game creates a village near a mine, it doesn’t matter if the adventurers never visit it—the content can be used elsewhere, the next time a generic village is needed. For a virtual world, it matters only slightly less; players may not visit the village very often or for the reasons the designer intended, but they will nevertheless visit it in time. In a LARP, if the adventurers don’t make an appearance it means several people have been sitting around in villager costume for an entire afternoon to no avail; for this reason, LARPs’ gameplay is often more collect-the-plot-piece oriented than their cousins’, with most of the fun coming from the deep role-playing involved rather than the adventuring. While role-playing to this degree is great fun for many people ¹⁵, it can be very hard to get into, particularly if you’re shy or retiring (that is, actually likely to be good at role-playing).

One thing that these real world- and human-moderated worlds do show is that the role-playing experience can transcend any preconceptions of something being “only” a game. Role-playing is routinely used for non-game purposes, and appeals to people who would not (nor would they wish to) consider themselves as gamers. It’s even used as a game by people who don’t see themselves as gamers—How to Host a Murder is basically a mini-LARP. Many of the people who visit EverQuest, Ultima Online, and Star Wars Galaxies do not believe themselves to be gamers at all (which is only fair, given that they aren’t).

Other Influences

The design of virtual worlds is influenced by printed works, film, television, and role-playing games. Individual worlds may draw from other fields, too; for example, there are text MUDs set in console game worlds like that of Hironobu Sakaguchi’s Final Fantasy series, and there are scripting languages based on those used for military simulations. Anything requiring imagination can potentially be of value: These genuinely are “imaginary” worlds.

However, external factors are not the only ones at work here.

The greatest influence on the design of virtual worlds is (for better or for worse) the player base. Thus, anything that can influence existing or prospective players is itself an influence on the design of the virtual worlds they elect to play.

Some of this influence falls into the domain of marketing, which from the point of view of a designer can be viewed as a single pressure that is a convenient abstraction of the many other pressures the designer really, really doesn’t want to know about. Further influence comes from customer service, which affects game designers more (in that they have to plan for it in their design), but again it can be viewed as a single pressure that is the summation of many other pressures off the designer’s radar.

The remaining sources of influence are more direct, and should be consulted regularly:

• Competitors. Virtual worlds evolve by trying new ideas, yes, but also by taking ideas that work from other virtual worlds and by discarding ideas that have been shown to fail. Every virtual world has some innovation, and they shouldn’t be ignored simply because they weren’t written by you or they use a different genre.

• Opinion-forming publications. Reviews are important, as are regular columns: After all, even if a columnist were unilaterally to refer to virtual worlds as “MMOs”, sooner or later players would show up calling them MMOs. However, a magazine’s editorial policy matters the most, as it sets the tone for the articles. Computer Gaming World treats virtual worlds in a different manner than Wired, even though both are admirably responsible about the subject. Readers of one will get a different impression of virtual worlds than readers of the other.

• Opinion-forming players. Players listen to each other, whether it’s in the virtual world, in an online forum, or at a rant site. Surprisingly for designers, not every word uttered by players is patent nonsense; surprisingly for marketers and customer service people, not every word uttered by players is blindingly insightful. Players can swirl into a great maelstrom of creativity, but few of them truly understand game design ¹. This is a theme that surfaces time and time again when considering the design of virtual worlds.

Designers should not delude themselves that they can manipulate any of the above. Your fellow designers will usually be only too happy to explain to you those advances of which they’re particularly proud (it’s not like these things can be kept secret once beta-testing begins), but they won’t change their minds on your say-so. Similarly, although those journalists that your marketers allow you to speak to may seem wide-eyed and gullible, that doesn’t mean they really are. As for manipulating players, the customer service departments of some virtual worlds prohibit designers from even speaking to them, so disastrous can the consequences be if they do!

These are sources that can influence designers; the only way to influence them in return is through the designed virtual worlds.

The Designer

The role of virtual world designer is fraught with paradoxes. You have to be imaginative yet realistic; deep-thinking yet practical; surprising yet dependable; an individual yet part of a team; a doer yet a listener. You have to know a lot about some things and at least a little about everything else.

This chapter has presented the context. If you didn’t already, you should now know where virtual worlds are, how they got to be that way, and where they seem to be headed. Whether they actually do go in that direction is another matter. It all depends on people like you.

Subsequent chapters of this book lay out the choices before you, but only you can decide which to make.

The options suggested are only that, options. If you look at them and think, “they wouldn’t work in my virtual world,” you could well be right; that isn’t to say they wouldn’t work in someone else’s, though. Players are often quick to go to the specific when they should be staying at the general. “You can’t have permanent death in EverQuest!” Well, of course not—EverQuest was designed not to have permanent death in it; adding the concept would be as misguided as placing a learn-to-play-golf feature in a Saturday night chat show. It doesn’t fit the format. In an afternoon sports magazine, hey, it might work. In a new series targeted at the recently retired, it would make perfect sense.

You can taste ideas to see if you like them, but you don’t have to swallow them whole. Besides, even if they’re your favorites, they might not go together. Italian cuisine does not call for pistachio ice cream to be added to spaghetti bolognaise.

Question the paradigms, avoid stagnation. You have to understand a system before you can challenge it, but that doesn’t mean you have to accept it. Just because you see a list of ideas here, that doesn’t mean it’s exhaustive. The virtual worlds people remember are the ones that are different, not the ones that are the same.

After the success of the Harry Potter series, children’s book publishers went all out to find the next Harry Potter. Everyone likes plucky, magic-wielding youngsters! Well, up to a point: What they actually like is Harry Potter. Whatever the next big children’s publishing sensation turns out to be, about the only thing you can say about it is that it won’t look like Harry Potter.

Those companies writing virtual worlds that are EverQuest clones are scrapping for crumbs from the high table.

Read, assimilate, understand. Then think for yourself.