Solids: Containers

Objects in virtual worlds can be in various hierarchies. The main one is the class hierarchy (X is a kind of Y), but other possibilities include an assembly hierarchy (X is a component of Y), a spatial hierarchy (X is on top of Y), and a container hierarchy (X is contained by Y). The latter two are related, as we’re about to see.

Container hierarchies are useful because they give players physical means by which to move around groups of objects in a virtual world. They’re not essential: In the same way that early computer operating systems didn’t have the equivalent of subdirectories or folders, so some early virtual worlds (most notably Shades) didn’t have containers. However, they’re very useful. In a nodal implementation of a virtual world, the work is already done anyway: Rooms can contain characters, characters can carry (that is, “contain”) objects, therefore, it’s not a huge leap of the imagination to allow objects to contain other objects too.

Virtual worlds that use a co-ordinate system to handle location typically have to switch to a nodal system for containership. Although it’s possible to extend the co-ordinate approach to allow objects to be carried around in backpacks and pockets and on belts and so on, in practice it’s too inconvenient for the players. It’s no fun for the programmers, either, having to lock arbitrary objects onto the co-ordinate frame of a character so that wherever the character moves, so do the objects. For this reason, most graphical virtual worlds maintain a separate inventory for containership, using a co-ordinate system only for the top level (which can more easily be displayed graphically).

Graphical worlds don’t have a problem illustrating the spatial relationship between objects. You can see that the bottle is on the table, the chair is next to the table, the boots are under the table, and so on. This is because of the rigid spatial structure imposed by the co-ordinate system. Nodal systems do not have this underlying structure: If two objects are inside a room, that says nothing about the spatial relationship between the two. Even the connectional relationships between two adjacent rooms are not implied; they have to be stated explicitly. Some nodal virtual worlds—for example, those developed by Skotos—do have a relationship network between objects. However, without absolute co-ordinates it’s hard to make deductions: If X is next to Y and Y is next to Z, is X next to Z? Co-ordinate systems have this problem too, of course, when it comes to modeling the contents of containers. Fortunately, most players don’t care to think beyond “X is in the bag”—they’re not really worried about where in the bag, so long as it doesn’t move around and they can get at it when they want it.

Containers are usually limited in what they can contain. They’ll hold only a certain volume (or number) of objects. Sometimes only objects below certain dimensions will go in (you can’t put a table spoon inside a beer bottle) and sometimes only objects above certain dimensions will stay in (you can’t store pencils in a net bag). The containers may be rigid or soft, opaque or transparent, closable or always open—the same kind of properties you get for many other objects. There are some particular issues that containers have which don’t affect other objects, however.

Most containers are endocontainers, in that they contain things inside them. Chests, bags, bowls, baskets—they all enclose what they contain. There is also, however, a smaller class of exocontainers; these contain other things outside them. Music stands, hat racks, and Christmas trees are examples of exocontainers. Exocontainers “wear” what they hold.

Some virtual worlds treat exocontainers and endocontainers as totally distinct, on the grounds that holding by enclosure is fundamentally different to holding by hooking or tying or anything else. The concepts are indeed disjoint, of course, but there is enough commonality that it’s generally better to treat them as the same thing. “Take music from stand” and “take stand from case” are essentially the same action and can be implemented using much the same functionality.

The key differences are in two areas.

Firstly, although the contents of an opaque endocontainer can be concealed from prying eyes, you always see what an exocontainer is holding. This isn’t too bad for textual worlds, but graphical worlds need to be able to construct animated images to match the almost arbitrary clothing permutations that players will try, which can be very tricky ¹.

Secondly, for endocontainers, the containers protect their contents. If you hit an endocontainer, the amount of damage suffered by what’s inside may be reduced. For exocontainers, the reverse applies: The damage suffered by the container may be reduced because it’s absorbed by what the exocontainer is holding. This is how armor works.

This brings up the subject of a very special endocontainer: the player’s own character. In Fantasy worlds in particular, things the character carries or wears are position-sensitive. You don’t put helmets on your arms, you don’t put boots on your chest. Graphical and textual virtual worlds both have problems with this.

Graphical worlds have adopted a standard from single-player computer role-playing games, whereby an image of the character is displayed with the “slots” (usually) indicated, and players dress it up paper doll style ². Although not exactly immersive, it’s in keeping with the way that the inventory in general works. Textual worlds have more to worry about because players want to refer to body parts. It’s okay to have “wear socks,” “wear cravat,” and so on, but players want “wear ring on left index finger.” This implies that bodies should be treated as assemblies. They’re not assemblies that players will typically want to dismember in a controlled fashion, and, except for in Horror genres, people aren’t going to care to reassemble new bodies from parts, either. Nevertheless, if players want to reference parts of an assembly then the assembly has to be constructed or faked up; either way, it’s very tiresome to implement and clue players in to the fact that assemblies are possible. First it’s bodies, then suits of armor, then horses, then carts—before you know it, you’ve gone way further than you ever wanted and it’s starting to have an impact on response times. If you do decide to implement bodies, make the decision then and there whether or not it’s a one-off, and stick to it. You won’t be swayed, you have a will of iron….

What about books, then? Books contain pages, but those pages are fixed in a certain order, so they’re basically assemblies. If someone wants to “read page 24” are you going to let them? Or are you going to keep your books really short, so they only ever have one page?

It can be very tempting to turn a container into an assembly. Be careful.

Turning containers into generators is also tempting, but much less dangerous. A bag of nuts that always has nuts in it no matter how many you take out is fine, as long as you don’t let anyone turn it inside out. A coat rack in a shop can have a fixed number of coats hanging from it, each of which is created using a lazy evaluation approach (that is, only when someone tries to access a coat is one created).

The final thing to mention about containers is the notion of encumbrance. This is an old (some would say dated) idea from table-top role-playing games. In general, the weight of objects that a container ³ can contain depends on its strength; the number it will hold depends on the dimensions of the container and of the objects concerned (although for exocontainers it also will involve some measure of viable contact points—that is, the container’s dexterity). However, objects are often so awkward that they slow you down much more than others of a similar weight or shape would. An open umbrella is harder to handle than a closed one; a helium balloon gets in the way more than a soccer ball (both of which are easier to keep a hold of if they’re deflated).

The idea behind encumbrance is to quantify how much something affects the attributes of its container by virtue of its own attributes. It’s an imperfect abstraction, but at times it can be a useful one. Even a virtual world that stored the exact dimensions of objects would still have to approximate some computationally expensive calculations—for example, knapsack-packing problems (emptying a full knapsack, then getting all that was in it back inside is non-trivial—it’s like doing a 3D jigsaw puzzle).