Links
Essays
Talks/Interviews
Snippets
Laws
Timeline
Book
All contents of this site are
© Copyright 1998-2010
Raphael Koster.
All rights reserved.
The views expressed here are my own, and not necessarily endorsed by any former or current employer.
A key requirement regardless of the method used to describe the space is the fact that the space must persist independently of any connections to the server. This does not mean that it must remain running at all times—one of the most common optimizations done to virtual worlds is to let unused areas of the map go inactive. Rather, it implies that the space itself should have a degree of persistence. It may evolve over time, or grow, but it remains the same.
In this model, the server references a map that exists as an independent entity, defined in a database. The client connects to the server, which feed it information about the map. In graphical systems, there is usually a duplicate copy of the map living on the client side, in order to avoid having to send bulky graphical data across the wire. The map database is monolithic, and the server always addresses the same database. This does not imply anything about the continuity of the map defined or the spatial relationships within the map. In fact, the map may in fact consist of multiple separate sub-maps.
An alternate model, which falls outside the scope of a traditional virtual world, is one where there exist multiple spaces that the server rotates amongst. These spaces may be predefined, or they may be created on the fly using random algorithms. This model is used by first-person shooter games such as Unreal Tournament and Quake, and (with random creation of maps) by action-RPG games such as Diablo. The reason these fall outside of the scope of the genre is because they fail to offer constancy. In interacting with a virtual world, one has the expectation that the world is indeed a world, an independent entity that remains, despite changes over time, just as our world remains, even though it has been deforested, continents have shifted, and new mountain ranges have risen from the earth’s crust.
Now, many muds have offered a similar range of maps to play on, in a manner much like that of Quake. But they have always involved having a central, persistent hub space. The hubs in Quake and Diablo are not spatial depictions (in first person shooters, they are little more than a list of servers; in Diablo, it is a chat room) and therefore do not even pretend to be virtual worlds. Muds such as HoloMUD offer a standard central map that is considered by game convention to be “the real game.” Then it allows teleportation into “holographic spaces” via doorways leading off of that central map. These lead into sub-maps which are radically different, and in fact are arenas for a game very akin to Quake. The sub-maps have very little persistence, and reset most elements of their game data on a regular basis. However, the persistence of the space itself remains, because the sub-maps fall under the umbrella of the central lobby, which is, for all intents and purposes, HoloMUD itself.
A tactic for solving the issues inherent in developing large amounts of space, as well as graphically representing it, is for the space to be the output of a predictable function using a fixed random seed. Under this method, an entire map or subsection thereof could be defined using a single number. When this number is fed into the algorithm, a predictable result is always obtained. This method of map generation has been used by standalone games such as Worms; using it to fractally generate terrain maps and populate them with objects such as flora and buildings is the intent of several major commercial endeavors, including Simutronics’ Hero’s Journey. It is in use in textual environments such as Discworld as well. To date, no graphical virtual worlds have opened to the public using this idea, even though methods of employing this technology for virtual world development were publicly discussed on the MUD-Dev list in the mid-1990’s. The savings are considerable—not only is map generation the single costliest part of creating a virtual world, but in the case of worlds too detailed (or too graphical) to stream down to the user via their client, one could place duplicate algorithms on both the client and server sides, and merely send down the seed value. This keeps you from having to store large maps on the client side, and perhaps keeps you from requiring a CD as part of your game.