Programmer Docs

Developer documentation for people building on FallMOO: how the core systems are wired, the conventions to follow, and the verbs to hook when you extend the world. If you are a player looking for game rules, see Game Mechanics instead.

These pages assume you can read and write MOO code and move around the object hierarchy. They describe how things are actually implemented, name the verbs and properties involved, and point at the objects you extend or override. Treat the live database as the source of truth: verb bodies and property values drift, so verify against the running game before you rely on a specific line.

House rules

• Everything is owned by the same wizard. There is no permission or quota system in this world, so never write permission checks, ownership checks, or quota checks.
• Player-facing text goes through $you / $emote. Never build sentences by hand with pronoun substitution. Use $you:do(...) and $emote:new(...) so names, pronouns, and verb agreement come out right for every observer.
• Timed things are actions. Anything a character does over time is an $action child with a two-phase start -> finish lifecycle, queued with player:queue_action(...). Do not sleep inside a command verb.
• Unique system objects self-register. Effects, actions, activities, areas, jobs, and weather are $singleton children: creating a child registers it into its parent's contents automatically.
• Gate with why_cant_X, act with do_X. The common pattern is a predicate verb that returns a reason string (empty means allowed) and a separate verb that performs the change. Command parsing calls the predicate, then queues the action; the action re-checks the predicate before committing.

Pages

See also

• Game Mechanics - the player-facing rules the code implements.

• Install & Uninstall