Power to the Player

Chapter 1 stated that players can create content in a number of ways, which can usefully be categorized as being either in-context (you put a minotaur on retainer and hire a bunch of NPC peasants to construct your labyrinth) or out-of-context (you manifest a minotaur and a labyrinth from nothing). People with the ability to make out-of-context changes are “builders.” An analysis of who can build and how long their creations last determines who “owns” a virtual world.

Although the switch between in-context and out-of-context creation is a step change, on either side of the discontinuity the power to change is more continuous. Again, although designers do consider content creation using in-context methods to be important—especially for the elder game—they don’t mean that when they talk about player-created content. Player-created content means building, and there is an escalating scale of what can and can’t be done using it. In describing this, the important concepts are

• Objects. Tangible virtual world entities, including mobiles and geography.

• Functionality. Code that changes the properties of objects.

• Building blocks. Prefabricated components that are combined to make a whole.

• Free-form. New components can be constructed from nothing. In increasing power of expression, these can be combined as follows:

• Objects from predefined components. A musket is a heavy, antique, two-handed firearm. Its default weight, value, and accuracy have these new default values: mass=8000, value=125, ammo=ball, and so on.

• Functionality from predefined components. To load a musket, you must put in the gunpowder, the wadding, and the ball, in that order. Only then can you fire it.

• Free-form functionality. When you fire a musket, there’s a chance it could explode and cause a new kind of damage to your hands, arms, torso, and face. The noise could deafen people close by.

• Free-form objects. There’s this entirely new object, a grenade. When you release the trigger, you have 10 seconds before it explodes. It has entirely new properties for blast radius and the distance it can be thrown, with these default values: mass=250, delay=10, blastradius=50, and so on.

The latter two can perhaps be combined, because for functionality to be truly free-form it would include the ability to create objects anyway. Free-form object creation appears last because it cannot occur without free-form functionality.

In-context object creation occurs by combining components within the (possibly loose) constraints of a recipe, therefore it’s not hard to extend to out-of-context creation. You may get some fairly bizarre constructions, but they’re not going to cause the virtual world to crash.

Functionality additions are more problematical. If they’re from components, again your virtual world should be fairly safe. So long as you ensure that there’s no danger of recursion (for example, your new “load musket” function contains a call to “load musket” ¹), all should be well.

Free-form functionality is dangerous. People can do things that cause crashes (for example, dividing by zero) or hangs (for example, non-terminating loops). Crashes can be trapped, but the state of the virtual world after a function has aborted mid-way through will not necessarily be consistent. Loops can’t be detected, only assumed: The virtual world’s engine can stop a player-created loop after a million iterations only to screw up everything because the critical million-and-oneth iteration never got to execute. Resource hogging also can be a problem: Players really will create 99 red balloons ² without a moment’s thought, and if that works they’ll go for 1,001 Arabian Knights (that’s humor for you).

TinyMUDs and their ilk have evolved mechanisms to prevent these issues from becoming too problematical, using approaches similar to those adopted in the old days of mainframe computer timesharing systems. Crashes are handled by the operating system’s interrupt mechanism. Hangs and processor-hogging are handled by interrupting functions after they have exceeded some guaranteed minimum amount of processor time. Disk and memory usage is limited by the number of objects (and, optionally, properties and functions) that an individual can create in total—you have to delete old stuff to make room for new stuff once your quota is reached. Some virtual worlds have allocation committees to decide who gets what resources.

The more powerful player-created content forms are prevalent only in textual worlds. This is for practical reasons more than anything: Everyone who plays the virtual world can by definition type, therefore they can all create word-based content. For graphical virtual worlds, few of the players can draw (and, unlike the situation with writing, it’s usually apparent even to them ³ that they can’t). This isn’t to say that their ideas are no good; it merely means that they are unable to put them into practice. Given that most people can’t even take professional-quality photographs, this situation would likely prevail even were the best graphics-creation tools to be made available to players.

For the time being, graphical worlds that want to allow some degree of building are therefore pretty well stuck with using predefined components or restricting creation to artistically blessed players. That’s for object creation; new functionality would need to be hugely controlled if it were to escape being employed as a tool for abuse—so much so that it hardly seems worth bothering implementing.

The first 3D graphical virtual world to take player-created content seriously is World Fusion’s Atriarch ⁴. This Science Fiction world has modifiable terrain and allows characters to purchase components for the construction of buildings. Construction is open to all who can obtain the components ⁵, therefore it’s neither an end-game thing nor even out-of-context. Still, it’s a start ⁶.

Another approach is to push the problem one level back. This is the tactic adopted by Bioware with Neverwinter Nights ⁷. The idea is to make the necessary development tools for virtual worlds available to players so they can create their own independent (in this case) games. Bioware makes its money from selling the boxed sets and from hosting secure servers for characters (so they can move from one mini-world to another ⁸). It’s a business model that has potential, but each virtual world is limited to 64 simultaneous players, so it’s hardly going to challenge the likes of EverQuest on that basis ⁹.

Also, as I said, it pushes the problem one level back. Bioware are the developers of the game engine and they maintain network operations for players, but that’s all. The same design and customer service issues that apply to virtual worlds still apply, just to the (from Bioware’s perspective) players. It’s like the way that Dungeons & Dragons defines a gaming system but the players themselves design and (within the confines of that system) develop the individual game worlds; this is perhaps not surprising, given that NWN is a D&D license and implements the 3 rd Edition D&D rule set.

This tool-oriented attitude is set to become increasingly important in the development of virtual worlds. If cheap engines are available to run the virtual worlds and enough customizable predefined artwork exists to satisfy most needs, at a stroke the two most expensive development costs are removed. Hobbyist designers will be able to create their own graphical virtual worlds in the same way that for years they have been creating textual ones. A start has been made with the use of virtual reality VR viewing software (Active Worlds ¹⁰, for example, allows people to create custom, shared virtual spaces, albeit not ones you can do much in except look around). If actual game engines are made open source, we’ll see the same codebase branching occurring that drives much textual world development, too. There is some movement in that direction, most notably with Nevrax’s ¹¹ decision to make its NeL (Nevrax Library) development toolkit available under the GNU General Public License ¹² (GPL). They stop short of giving their server source code away, however.

A way to introduce some element of freeform player creation while maintaining the integrity of the virtual world is to allow link-outs to the general Internet. Depending on the degree to which developers are willing to sacrifice design control and immersiveness, there are many possible scenarios. Some examples:

• Clicking on a character extracts data from a file on the player’s own web site and presents it as a biographical description of that character.

• Clicking on a character’s shop opens a browser window showing the prices of the goods available for sale.

• Clicking on a player’s castle reads the definition of its interior layout from files on its web site.

• Clicking on a magic portal teleports your character to another virtual world entirely.

• Clicking on a web site queries the virtual world and produces data that can be incorporated into the web site (for example, prices, character name lists, remote views).

There is, obviously, great scope for abuse here. Instead of prices, that browser window might contain pornography, for example. In small, tight, role-playing virtual worlds, misbehavior can be controlled relatively easily because players know that there is a line of people waiting who would be only too happy to replace someone who was spoiling things for others. In large-scale commercial worlds, this measure of restraint is simply not going to happen except perhaps when players have a lot to lose (for example, in the elder game).