# The Big Six

LLMS index: [llms.txt](/dvw/en/llms.txt)

---

Surprisingly, there are only six categories of commands for virtual worlds, only half of which are in-context. Implement these and you have the makings of a basic virtual world. The big six are

- Exit the virtual world (“quit”).

- Get playing instructions (“help”).

- Make a note (“bug”) [^78].

- Communication (“tell,” “say,” “shout,” “pose,” and so on).

- Create/destroy object (“chop wood”).

- State change (movement, “get,” “drop,” everything else).

Of these, the last one is the most important from the point of view of the virtual world’s physics.

Tangible objects in virtual worlds have properties, which in turn have values. Properties can take many forms: “Mass” might be an integer; “label” might be a string; “location” might be a set of co-ordinates; “contents” might be a list of objects; “components” might be a treelike data structure. Some of these values may be independent; others may be recomputed each use because they depend on many factors (for example resistance to magic).

State-change commands alter properties. A simple “get,” for example, entails changing the location of an object from the floor to the character; movement involves changing the character’s location property from one point to another; “open door” means changing the door’s “opened” property to true.

It’s more complicated than this in practice, of course. There are all manner of preconditions that need to be satisfied (objects can be too heavy to pick up, or tied down, or on fire, or being stood on, or plenty of other irritating things); there is feedback to be generated (you see the door open, as do people on the other side of it); the properties themselves can take different forms (location as co-ordinates or as a contains/contained-by hierarchy). From the designer’s point of view, though, the actual mechanics aren’t particularly important; of more interest is what can be done with them. This is because everything tangible except object creation/destruction can be done with them.

This means that the properties you choose set the level of player commands, which in turn set the level of the physics. If the properties are fine-grained (as they might be if you kept a record of how many roses were growing in a bush, say), then the commands that change these properties must also be fine-grained—therefore, the physics that underlies the commands must be slightly finer-grained yet (because it’s what gives the properties their meanings). It makes no difference whether people use the commands frequently or infrequently; once you have that level of detail, you have to support it.

Similarly, by going the other way and having coarse-grained properties, you get coarse-grained commands. If flowers are properties of a garden rather than objects in their own right, characters can’t ever do so much with them (which means less detailed work for your physics).

As for what level of detail to go with, that depends on both the virtual world and the real one. It depends on the virtual world because some contexts need finer-grained properties that others can do without. A murder mystery detective game, for example, would need many detailed properties for each object, because meticulousness is a feature of detection; a space opera game would be able to gloss over most such properties because it concerns the grander scale. However, in all cases real physics is absolute. Players will have certain expectations, which they will proceed to act on. If you encourage them to look deeply, they may look deeper than you can manage; if you encourage them to look only superficially, it may be too superficial to satisfy their natural curiosity.

All that designers can really do here is to put themselves in the position of the player. Imagine what the completed virtual world would look like, then consider what players would want to do in it. Create objects to this level, set properties for objects at this level, and specify commands that operate at this level. From that, you’ll get your physics level.

I’ll discuss properties of objects in more detail shortly [^79]. For the moment, though, we’ll keep with the basic underlying physical system and ask the question: What happens when you want to model something that’s impossible in the real world?


[^78]: You could lump this under communication if you wanted, but I consider it to be more fundamental than that.
[^79]: To save you from getting your hopes up, I’ll warn you now that I’m not going to present a list of common object properties. The point of this section, after all, is to persuade designers to think about virtual world physics from first principles for themselves.