MUD Codebases & Engines

The DikuMUD Family Tree

DikuMUD (1990)
├── CircleMUD
├── Silly
└── Merc (1992)
    ├── Envy
    └── ROM (1993, Rivers of MUD)
        ├── ROM 2.4b6 (1998, final public release)
        ├── QuickMUD
        │   └── BasedMUD (modernized refactor)
        └── SMAUG
            └── Various derivatives
        └── Aardwolf (1996, heavily customized ROM)

DikuMUD (1990)

• Created by: Sebastian Hammer, Tom Madsen, Katja Nyboe, Michael Seifert, Hans Henrik Stærfeldt
• Where: University of Copenhagen Department of Computer Science (DIKU)
• Language: C
• Goal: “A MUD that was less messy than AberMUD, less buggy than LPMud, and more like Dungeons & Dragons”
• Key feature: Hard-coded virtual world (no live modification), remarkably accessible codebase
• Influence: Raph Koster credited it with “the greatest proliferation of gameworlds”
• License: Permissive but non-commercial (no selling the game)

Merc (1992)

• Created by: Michael Chastain (“Furey”), Michael Quan (“Kahn”), Mitchell Tse (“Hatchet”) at UC Berkeley
• Released: December 18, 1992
• Size: ~30,000 lines of C
• Improvements over DikuMUD: Cleaner code organization, bug fixes, better documentation

ROM (Rivers of MUD, 1993)

• Created by: Russ Taylor (“Alander”)
• Final version: ROM 2.4b6 (May 1998)
• Architecture:
  • Area files define world content (rooms, mobs, objects, resets)
  • OLC (Online Creation) for in-game building
  • do_*() functions for commands in act_*.c and wiz_*.c files
  • Data-driven design with tables over hard-coded logic

BasedMUD (Modern ROM Refactor)

Key modernizations of the ROM codebase:

• Separated concerns: handler.c → chars.c, objs.c, rooms.c, find.c
• Typed unions: obj->value[x] → obj->v.weapon.weapon_type
• Helper macros: BAIL_IF() replaces repeated error-handling
• Flag separation: MOB_* flags vs PLR_* flags (was a common bug source)
• Message helpers: act2() (char + room) and act3() (char + target + room)
• Optional features: Colored room titles by terrain, per-pulse regeneration

SMAUG

• Stands for: Simulated Medieval Adventure Multi-user Game
• Features: Extended OLC, more world-building capabilities, mob programs

The LPMud Family

LPMud (1989, Lars Pensjö)
├── MudOS
│   └── FluffOS (actively maintained)
├── DGD (Dworkin's Game Driver)
└── Pike (programming language, spun off from LPC)

Architecture: Driver + Mudlib Separation

The revolutionary LPMud insight: separate the engine from the game.

The Driver (C):

• Virtual machine that interprets LPC code
• Manages network connections
• Provides OS-level services (file I/O, timers, networking)
• Sandboxes against infinite loops, recursion, crashes
• Game-agnostic — the driver doesn’t know what kind of game it’s running

The Mudlib (LPC):

• Defines the game world: rooms, objects, NPCs, combat, magic
• Written in LPC, a C-like object-oriented language
• Acts as an “operating system” on top of the driver VM
• Can be modified while the game is running
• Different mudlibs create entirely different game experiences

LPC Language:

• C-based syntax, object-oriented
• Designed for non-programmers to create rooms and objects
• Inheritance-based: extend base Room class to make a specific room
• Notable mudlibs: CDlib, Discworld Mudlib, Lima Mudlib, MorgenGrauen Mudlib

Key Design Philosophy

“The driver should not define the nature of the game. The nature of the game is to be decided by the individuals involved, and you should be able to add to the game as it is being played.”

This separation influenced all modern MUD engine design.

The MOO Family

MOO (MUD, Object-Oriented)

• Original: Stephen White (based on TinyMUCK experience)
• LambdaMOO: Pavel Curtis at Xerox PARC (October 30, 1990)
• Architecture:
  • Server manages connections, task queues, database access
  • Database contains all objects in the virtual reality
  • Users can program within the server, expanding its behavior
  • Single-inheritance object model
  • MOO programming language: simple, OO, designed for non-programmers
• Notable: LambdaMOO (1991) — one of the most famous virtual communities

MOO Language

• Object-oriented, single-inheritance
• Basic syntax, designed for accessibility
• Objects have properties (data) and verbs (methods)
• Everything is an object — rooms, players, items, system utilities
• Built-in persistence (object database is the server state)

The TinyMUD Family (MU*)

TinyMUD (1989, James Aspnes)
├── TinyMUCK (added MUF language)
├── TinyMUSH (expanded commands)
│   └── PennMUSH
│   └── TinyMUX
└── MOO (object-oriented offshoot)

• Focus on social interaction over combat
• Player building is central — players create rooms, objects, descriptions
• “MU*” terminology to distance from hack-and-slash
• MUSH = Multi-User Shared Hallucination
• Heavily used for roleplay communities

Modern Engines

Evennia (Python)

• Language: Python 3.11+
• Frameworks: Django + Twisted
• Database: SQLite3 (default), PostgreSQL, MySQL
• Architecture:
  • Portal: Handles network connections (telnet, SSH, WebSocket, web)
  • Server: Runs game logic, manages objects and state
  • Typeclasses: Core abstraction — Python classes backed by database
    • Account, Character, Room, Exit, Object, Script
  • Command Sets: Stored on individual objects, mergeable, hot-swappable
  • Attributes: Dynamic key-value storage on any object
  • Tags: Flexible categorization system
  • Scripts: Asynchronous/timed execution
  • Locks: Fine-grained access control
  • Channels: In-game communication
• Design philosophy: Bare-bones but powerful foundation; you define gameplay in pure Python
• Built-in: HTML5 web client (WebSocket), own web server, contrib system for combat/crafting/weather/NPCs
• Async: Event-driven, no race conditions

Ranvier (Node.js)

• Language: JavaScript
• Architecture:
  • Bundle system: Nearly everything is a swappable bundle (commands, areas, items, NPCs, channels, behaviors)
  • Event-driven: Node.js events throughout — mob scripts are event listeners
  • Unopinionated network layer: Swap telnet for WebSocket or anything else
  • Flexible data layer: Not tied to any specific database
  • Core code has no opinions on game style
• Design philosophy: Modularity and extensibility; game-agnostic core
• Scripting: JavaScript (same language as engine)

Comparison Matrix

ROM Area File Format

The format Aardwolf and many DikuMUD derivatives use:

Sections

• AREA: Area metadata (name, builder, level range)
• ROOMS: Room definitions (vnum, name, description, sector type, exits)
• MOBILES: NPC definitions (vnum, name, stats, behavior flags)
• OBJECTS: Item definitions (vnum, name, type, stats, wear locations)
• RESETS: World population instructions
• SHOPS: NPC shop definitions
• SPECIALS: Special mob behaviors

Reset Commands

OLC (Online Creation)

OLC systems let builders create content while the MUD is running:

• redit — room editor
• medit — mobile editor
• oedit — object editor
• aedit — area editor
• Changes saved to area files or database

Sources

• ROM - MUD Wiki
• DikuMUD - Wikipedia
• BasedMUD - GitHub
• LPMud - Wikipedia
• MOO - Wikipedia
• Evennia
• Ranvier
• LPMud - Muds Wiki