The include guard. These two lines and the #endif at the bottom stop the header being processed twice when a file includes it more than once. Every area header needs one.

The area’s root path. Every cross-reference to another file is written CABEIRI + "goblin/room/r2.c", never a hardcoded string. While you build, this points at your realm (/realms/<yourname>/Cabeiri/); migrating the area to /domains/ means changing this one line.

Difficulty tiers. Monsters call set_level(CABEIRI_LEVEL_BUFF) instead of set_level(4). Want the whole area a level harder? Bump these three.

The real file also defines armour-class (CABEIRI_AC_*) and weapon-class (CABEIRI_WC_*) tiers here the same way; you will see a few of them in the weapon and armour examples. Then the guard closes.

ROOM

Rooms inherit ROOM (/std/room). This is goblin/room/r1.c, the entrance to the goblin cave. Like every file in the area, it starts with the global mudlib header and the area header.

inherit ROOM; makes this a room. ROOM is a macro from <std.h> that points at /std/room.

create() runs when the room loads. Call the parent’s create() first, always: it builds the room’s internals, and skipping it leaves the room half-built.

Room flags. "light": 1 lets players see (0 is pitch dark), "indoors": 1 shelters the room from weather and some spells, and "no teleport": 1 blocks teleporting in or out.

The one-line name shown in the room title and on exits. Lowercase, no trailing period.

The paragraph players see on look. The text is split across lines as adjacent string literals, which the compiler joins, so there is no + between the pieces and no \n.

Sensory detail for the listen and smell commands. "default" is what a player gets with no argument.

Details players can look at that are not real objects. The key is the noun the player types (look rocks); the value is the description. Give most nouns from the long description an entry here.

Directions mapped to destination files, built from the CABEIRI base path. An exit can cross into another zone: up leads into the mountain.

The ordering rule that bites everyone: set_exits() must come after ::create(). The parent’s create() builds the exit mapping, so exits set before it runs are silently wiped.

VAULT (rooms with doors)

A VAULT (/std/vault) is a room with doors: exits that can be opened, closed, locked, and unlocked.

Doors come in pairs: each side is its own room, and each declares the door pointing back at the other. This is goblin/room/r17.c, the north side. Its partner, goblin/room/r24.c, is the mirror image: the same door id, pointing back north.

Inherit VAULT instead of ROOM. Everything from the ROOM example still applies; the door calls are the addition.

The partner room’s path, defined once because reset() below needs to reach across to it.

The same opening as any room: the parent’s create() first, then flags and descriptions.

The door item is a function, not a string. (: ... :) is evaluated each time a player looks, so the description always says whether the door is open or closed right now.

Only the ordinary open exits go here. The door’s direction (south) is added by set_door() below, so it is not listed twice.

set_door(id, dest, dir, key) declares the door. id is the noun players use (open door), dest is the room on the other side, dir is the exit it adds, and key is the id of the key that unlocks it, or 0 for none. Both rooms of a pair use the same id, so the base class keeps the two sides in sync when a player opens or closes it.

The starting state: closed but unlocked. For a locked door, pass a key id to set_door() and call set_locked("door", 1); a player then needs an object whose set_id() matches that key.

A custom message for a successful open. There are matching hooks for close, lock, and unlock.

reset() runs periodically. This one swings a left-open door shut on both sides, using DOOR_ROOM to reach the partner and tell everyone in either room. query_reset_number() > 1 skips the very first reset, right after the room loads.

MONSTER

Monsters inherit MONSTER (/std/monster, which itself inherits /std/living). This is goblin/npc/warrior.c, the basic goblin fighter.

Locals are declared at the top of the function, then the parent’s create() runs first, just like a room.

The nouns players can target: kill goblin, kill warrior. Include every reasonable word, from the general to the specific.

set_name() is the proper name, set_short() is what appears in a room’s contents, and set_long() is the look description.

Difficulty comes from the area header, never a magic number. Health, damage, and experience all scale from the level.

set_class() gives the monster that class’s combat behaviour and abilities.

A 33% chance each round to cast something from the spell list.

Random flavour actions: how often they fire, then the pool of messages.

The clone guard. create() runs once on the blueprint (the master copy the driver loads) and again on every clone that appears in the world. Gear, loot, and money belong to each clone, so the blueprint stops here.

set_inventory() clones each file into the monster and runs the command after it, so the sword arrives already wielded. The value can be a command, a count (2 for two copies), or ({ count, command }). Entries with a count of 0 are skipped, so random(2) makes the chainmail a coin flip: about half the warriors spawn wearing it.

set_inventory() only clones and runs a command. An item that needs setup after cloning, like this salve’s type and number of uses, is still cloned by hand. !random(5) makes it a one-in-five drop.

Coins that drop into the corpse when it dies.

WEAPON

Weapons inherit WEAPON (/std/weapon). This is goblin/obj/sword.c.

Identity works the same as for monsters: the nouns players can target, the proper name, the short shown in inventory, and the look description.

The weapon class (damage tier), from the area header so all the area’s loot stays on one scale. WC_D is low-end; WC_X is the area’s best.

The weight. Heavier weapons encumber more.

The sale price, randomised a little (random(16) adds 0 to 15) so the economy is not perfectly predictable.

The weapon skill it trains and its attack style: "blade", "blunt", "knife", "projectile", and others. Two-handed weapons also call set_hands(2), which blocks the off hand (no shield), and set_hit((: ... :)) adds an optional special hit on each swing.

What it is made of. Materials interact with rust, acid, fire, and some abilities.

Keeps the sword through reboots for players level 1 and up, which is everyone. See the autoload appendix for the full format.

ARMOUR

Armour inherits ARMOUR (/std/armour). This is goblin/obj/chainmail.c.

Identity first, exactly as for weapons.

The armour slot: "body armour", "helmet", "gloves", "boots", "shield", "robe", "bracers", and so on. It decides where the item is worn and which slot it fills.

Ties the armour to a body size. Wrong-sized armour fits poorly or not at all; most human-scaled gear passes 0 for one size fits all.

The body parts it protects. A helmet is just ({ "head" }); body armour covers the torso and all four limbs. The AC is spread across them.

The armour class, from the area header so every body armour in the area is consistent and tunable from one place.

Weight, materials, price, and autoload work exactly as for weapons.

RING

A ring inherits RING (/std/obj/ring), which is itself a thin subclass of ARMOUR, so everything from the ARMOUR example applies. This is goblin/obj/ring.c.

• inherit RING; gives you the ring slot (worn on a finger) with all the armour machinery underneath.
• set_ac(random(CABEIRI_AC_RINGS)) randomises the AC from 0 up to the header’s ring cap, so some rings roll worthless and some roll useful. Use a flat set_ac(CABEIRI_AC_RINGS) if you want every copy identical.
• set_size(0) means one size fits all, which is normal for rings.

Rings are the natural place to hang small stat or resistance bonuses on named loot; the base is deliberately minimal so you add only what a ring needs.

Storage: containers, chests, and bags

“Storage” covers a few distinct things. Pick the right base:

CONTAINER (/std/container) is the low-level base that both STORAGE and ROOM build on; you rarely inherit it directly.

A fixed loot container (STORAGE)

This is cemetery/obj/urn.c, a sealed urn that holds coins and cannot be carried off.

STORAGE gives it put and get behaviour: players can put items in and take items out.

coins is declared at the top, then the usual identity block.

How much it holds. A chest meant for gear would use a much larger number; 10 keeps this urn to a little loot.

Pinning it to the room. set_prevent_put() stops players putting the urn inside another container; set_prevent_get() stops them picking it up at all.

Lets it hold a little more than its raw capacity would allow.

Seeding it with coins: clone /std/obj/coins.c, set the money, and move it inside. This is the standard way to fill a container.

The lock. set_key() is deliberately an id no key carries, so the urn can only be opened by breaking it or through a quest; a normal chest would use a real key’s id. set_can_close() and set_can_lock() enable those verbs, and set_closed() and set_locked() start it sealed.

A wearable carry bag (BACKPACK)

The simplest carry bag just inherits BACKPACK and sets a few values. This is Mjharr/mines/obj/satchel.c.

Prefer inheriting BACKPACK over building a bag by hand. Only add code (stat bonuses, a custom wear handler, colour codes) when the item genuinely needs it.

BACKPACK is ARMOUR with storage switched on, so the satchel is worn on the torso and holds items. None of that plumbing is repeated here.

Identity, materials, weight, and price, as for any armour. Note the trailing space at the end of the long description.

How much it carries, and the small armour bonus for wearing it.

Keeps the satchel through reboots for players level 30 and up. Only the bag itself is saved: the player save looks at top-level inventory, so whatever is inside the bag does not come back with it.

A number is a minimum level. 1 means every player keeps the item; 30 means only players level 30 and up.

A string passes if it matches any one of the player’s class, subclass, race, guild, kingdom, or gender. The match is exact, including capitals.

A mapping lists conditions that must all pass. The common case is newbie gear that only follows low-level players: this autoloads for levels 1 to 15, so starter gear disappears once a player outgrows it.

Every key a mapping can use, all optional:

• class, subclass, race: a string, or an array to allow any one of several. race also matches a werewolf’s form.
• guild, kingdom: a name. Capitals do not matter here.
• gender: a gender, such as "male".
• level, maxlevel: the lowest and highest player level allowed.
• alignment: a positive number means at least that good; a negative number means at least that evil.
• quest: the player has completed this quest.
• deed: the player has done this deed.

Because every key must pass, you would never use them all at once; this just shows the shape of each. A misspelled key never passes, so a typo means the item never autoloads.

An array of mappings passes if any one mapping passes. Here, clerics level 20 and up keep the item, and so does any member of the Order.