Objects

The rule with objects in virtual worlds is integrate everything.

When a virtual world is implemented, the entities of which it is constructed are its objects. The relationships between these entities are their properties. Together, objects and properties comprise the tangible part of the virtual world, which the physics brings to life. It doesn’t have to be this way—you could in theory devise a system where objects are mere consequences of interactions between fundamental equations in the same way that numbers are. If you try that, good luck.

It is essential for designers to recognize that although many objects in their virtual worlds have wildly different characteristics from many others, fundamentally they’re the same. They can be arranged into conceptually useful groups—player characters, mobiles, containers, rooms, portable objects, fixed features, and so on—but it’s a big mistake to treat these as unrelated, partitioned sets. You’ll get much better coherence (and a much better understanding of your own world) if you consider them to be specializations of a general abstract object rather than the roots of their own abstract hierarchy.

For example, suppose you decide that your player characters should have a “health” attribute. It would be an obvious step to use this same property to record the health of mobiles. You might also want to give ordinary objects a “wear” rating to track how close they are to falling to pieces. It should then occur to you that “wear” is measuring the same kind of thing as “health,” therefore you should use “health” rather than “wear. ¹”

This may seem rather obvious, but all too often it’s not ². In the early days, all MUD designers were also programmers, and it wasn’t until they picked up on object-oriented programming language ideas that some of them were prepared to accept that hey, maybe rooms and player characters are just objects after all? This is somewhat ironic because it turns out that the objects of virtual worlds don’t correspond well to the objects of an object-oriented programming language like C++. To explain why, I’ll have to digress for a while (but I’ll try to keep it short).

In an object-oriented programming language, there is a hierarchy of object classes. Individual objects are instances of a class. Thus, you might say that doubloons are a kind of coin, coins are a kind of treasure, treasure is a kind of portable object, and portable objects are a kind of (root) object. Although I’ve used the word “object” here, in programming terms these would be classes. Doubloon33 might be an instance of the class “doubloon,” which would make it an object. The power of object-oriented programming lies in its removal of repetitions: I don’t have to define “get doubloon1,” “get doubloon2,” and so forth, I only need to define “get doubloon.”

If objects can be instances of more than one class, or classes can be subclasses of more than one superclass, you have a multiple-inheritance system. Otherwise, it’s a single-inheritance system. For virtual world design, a multiple-inheritance system is highly convenient. If a room contains a doubloon, a penny, and a Ming vase, then when I issue the command “get coin” I want to pick up the doubloon and the penny; if I try “get antique” then I want the doubloon and the vase. The doubloon is both a coin and an antique, but not all coins are antiques and not all antiques are coins. It’s a common occurrence: Not all mammals are carnivores and not all carnivores are mammals; not all pop stars are men and not all men are pop stars. Is the queen of diamonds primarily a diamond or primarily a queen?

Unfortunately, programmers are likely to want to use C++ or some derivative (for example, Java) that only uses single inheritance{Erratum: C++ does has a form of multiple inheritance, (somewhat ironically) using the virtual keyword.}. They’ll see that there are “objects” in the virtual word, they’ll tie these to the “objects” in their object-oriented system, and then 95% of the way through coding they’ll hit difficulties. It’s possible to fake multiple inheritance in a single-inheritance system, just as it’s possible to fake single inheritance in a flat system. It’s a lot of work and it involves a lot of repetition; it’s still doable, though.

What isn’t so doable is inheritance of commands. Object-oriented programming involves the association of items of code (called methods) to object classes. These are not themselves objects; they don’t exist in an inheritance tree. In other words, I can’t say that the method “punch” is a subclass of the method “hit.” If I want 30 different ways to hit something, I have to implement them separately. If I want the effects to differ depending on whether the objects I hit are soft or hard, I have to repeat for each. For large or complex worlds, this can rapidly get insanely tedious both to implement and to maintain. Object-oriented programming is about removing mindless repetition, not about enforcing it.

This situation arises because the virtual world “objects” were a bad choice for the programming language “objects.” Instead, commands should be the objects. If “hit object” and “hit soft_object” are defined as (object-oriented) classes, then a command like “slap cushion” is an instance of a command (in this case the second one), from which the associated code can be located and run. It’s essentially a programming issue rather than a design one, but because of the heritage of virtual worlds it has made it into the design paradigm. Designers often think in terms of objects and methods when they should be thinking of multiple inheritance hierarchies and commands.

Okay, end of digression.

So, object classes in virtual worlds are generally arranged in some kind of hierarchy. This allows the sharing of properties, which encourages integration, which in turn delivers coherence. The days when you had to “ring bell” because “hit” was already taken by “hit creature” are gone ³.

If asked, most designers would probably subscribe to the idea that integration is good. Sadly, though, they often don’t give it much thought. Spells and skills have much in common, for example—they’re the ability to perform a specialized task to a particular standard, which has to be learned. Few virtual worlds consider them at all related, though. Similarly, what player characters might have as skills or spells, artifacts could have as effects or enchantments. If I can learn to cast a lightning bolt spell, then why can’t a magical staff be taught to do it, too? This approach has been used in single-player role-playing games (for example, Larian Studios’ Divine Divinity), but it’s uncommon in virtual worlds.

Although much of this discussion on objects has concerned textual worlds, it applies equally well to graphical worlds.

Graphical worlds are generally nowhere near as functionally rich as textual ones, but the gap is closing; sooner or later, the limits of using single inheritance for virtual object classes will become an issue. You can get 95% of the way without multiple inheritance and the ability to quantify over actions, but then that last 5% becomes important.