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.
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 (the results of 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[52] good clients about that people will almost certainly be using one anyway.
[52] http://www.mudconnect.com/resources/Mud_Resources:Mud_Clients.html has a list of client resources.
A custom client works 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 2½D (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).
Another categorization that is important to newbie players but less so to designers is genre[53].
[53] I use the word to mean both the theme/setting and the content category (usually expressed in terms of suitability for children).
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 16th 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[54]! 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:
[54] There's also the problem (noted by Damion Schubert) that the enemies don't get bigger. Aside from the real-life political problems that would arise from killing virtual natives and Mexicans, what happens when your character advances in experience? Do you kill bigger natives and Mexicans?
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[55]. 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?
[55] The only one of those mentioned above that I haven't encountered in my capacity as a virtual world design consultant is the Comedy genre. All the rest I've seen people try?some, more than once.
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[56]. 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?!"
[56] For regular computer games, a license often amounts to a big sign saying, "Warning: Highly derivative product!"
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).
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[57]).
[57] The main open source 3D graphics engines in development are
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 is 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[58]. 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.
[58] For "mud library." MUD1 had a mudlib, but it was an adaptation of the BCPL input/output library and therefore was at a lower level than today's mudlibs. The modern use of the term was coined independently by LPMUD.
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 (based on Raph Koster's original at http://www.legendmud.org/raph/gaming/book/6b.html) 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[59]), or data (non-executable).
[59] There is an argument that high-powered scripting languages such as LPC, which can be used for applications beyond virtual worlds (for example, writing WWW servers), should count as both code and scripting language. MUDDLE can even be compiled and run directly, instead of being interpreted.
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, LPMUD).
Very generally, the major codebases[60] used for (textual) virtual worlds conform to the following stereotypes:
[60] For further details and descriptions of derivative codebases, see the rec.games.mud FAQ parts 2 and 4:
http://www.mudconnect.com/mudfaq/mudfaq-p2.html#q6
http://www.mudconnect.com/mudfaq/mudfaq-p4.html
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 way 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[61].
[61] For an examination of the different codebases from both a player's and developer's perspective, see Andrew Busey, Secrets of the MUD Wizards: Playing and Programming MUDs, MOOs, MUSHes, MUCKs and other Internet Role-Playing Games. Indianapolis, Sams.net Publishing, 1995.
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.
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.
Virtual World | Birth Year | Codebase | Home Page URL |
|---|---|---|---|
MUD1 | 1987 | MUD1 | http://www.british-legends.com/ |
Void | 1989 | custom | http://void.greenfinch.com/ |
DragonMUD | 1989 | TinyMUD | http://www.dragonmud.org/ |
BatMUD | 1990 | LPMUD | http://www.bat.org/ |
Medievia | 1991 | Custom | http://www.medievia.com/ |
Northern Lights | 1992 | AberMUD | http://www.ludd.luth.se/mud/aber/northern_lights.html |
MediaMOO | 1993 | MOO | http://www.cc.gatech.edu/~asb/MediaMOO/ |
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[62].
[62] Reasons why virtual worlds nevertheless don't all last for more than a few years are discussed in Chapter 3, "Players."
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[63].
[63] From the point of view of the virtual world's healthy survival. Obviously a game will generate more money when paying customers stay longer, which is why retention is a big issue for commercial products.
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[64] 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[65].
[64] The company was known as Mediagenic at the time.
[65] Which perhaps explains why it was bought from 3DO and relaunched in 2002.
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[66], 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.
[66] Such as GarouMUSH, http://www.garoumush.org/.
Count the number of players who access the world per day. This can actually be quite a useful measure, although a bad game with good 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 demo graphics 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[67]. 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
[67] For example: What percentage of computer gamers are female?
43% http://www.idsa.com/IDSATopTen2002.pdf (2001 survey by Peter D. Hart Research Associates and NPD Group)
42% http://www.mediafamily.org/research/vgrc/2001-2.shtml (2001 survey by National Institute on Media and the Family)
12% http://www.techmall.com/techdocs/TS000822-1.html (2000 survey by The Strategy Group for Ziff-Davis).
Contrast these with the results of Nick Yee's EverQuest survey, which discovered that approximately 16% of that game's players are female. http://www.nickyee.com/eqt/demographics.html.
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."
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[68], elegantly exposes what is perhaps the most important question designers must face, which determines the very soul of their creations: Whose world is it?
[68] In http://www.legendmud.org/raph/gaming/despat_files/frame.htm . Their narrative cube, discussed in Chapter 7, "Towards a Critical Aesthetic," is a related idea.
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[69].
[69] Whether they would do so if they had to pay a monthly license fee to listen to them is another matter, of course.
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, gamewide 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.
Persistence (what survives a reboot) | |||||||
|---|---|---|---|---|---|---|---|
Map and characters | Property objects | Objects by class | Objects by location | Entire world | Functionality | ||
Change (who gets to build) | Coders | Shades | (role-play) MUSHes | ||||
Trained administrators | MUD1/III; AberMUDs | DikuMUDs | |||||
|
Trusted players | EverQuest | Asheron's Call | Ultima Online | MUD1/II; Castle Marrach | |||
Experienced players | MUD2 | LPMUDs | MUCKs | ||||
Non-newbies | TinyMUDs | ||||||
|
Anyone | LambdaMOO | MOOs | |||||
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[70] allow certain players to take control of the virtual world in a major way, but they wrest ownership back with every reboot.
[70] Actually, because there's only one of me, this should be "designer."
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 w
 | Designing virtual worlds |
Top
