Why this shape suits virtual worlds.
In most game engines the world and the program are separate. Content sits in data files, behaviour sits in a compiled program, and changing either means stopping the game, rebuilding, and starting it again.
A MOO does not work that way. The world is a set of numbered objects held in a live database — and the code that gives those objects behaviour is stored on the objects themselves, in the same database. There is no separate program holding the rules. A room knows how to be looked at because it carries the instructions for being looked at.
The consequence is that building and programming become the same activity, performed with the same commands, at the same time, on a world that is running with people in it.
| Idea | What it means |
|---|---|
| Objects have numbers | Every room, exit, item and character is an object with a permanent number — #17, #412. Names are for players; numbers are how you refer to something exactly. |
| Single-parent inheritance | Every object is made from one other object and inherits its behaviour. A chair made from the furniture prototype can be sat on before you write anything. |
| Verbs live on objects | A command is a small Python file attached to an object. look is not a feature of the engine; it is a verb sitting on the room prototypes. |
| A natural-language parser | Players type put the blue sword in the oak chest, and the engine splits that into a verb, a direct object, a preposition and an indirect object before your code runs. |
A virtual world is mostly exceptions. One door is locked. One statue answers questions. One cup refills itself. In a conventional engine each exception is a special case somewhere in a central system, and those special cases accumulate until the movement code knows about every strange door in the world.
Here, the strange door carries its own instructions and nothing else changes. The general case stays simple no matter how many exceptions you add, because each exception is attached to the object that is exceptional.
The counterpart to per-object behaviour is shared behaviour. Write the common case once on a prototype and every object made from it gets it. Change the prototype and they all change together. The rhythm of building is: define the common case on a parent, override the exception on the one object that needs it.
Because behaviour is data in the database, changing it takes effect at once. You do not reproduce a problem in a test copy and deploy a fix. You stand next to the broken door, fix it, and try the door again — while players are walking around you.
You are never building an application that will one day contain a world. The world exists from the first minute; you add one room, one object, one behaviour at a time, and it is always running. That is why MOO worlds get built at all: the next step is always small.
Everyday commands are not attached to players. In MegaMOO they live on
the room prototypes, because the room is what decides what is
possible inside it. If you go looking for look on a
character, you will not find it. Character objects carry only staff
commands.