History of MUDs

Audience: Everyone Status: ✅ Ready

TelosMUD did not appear from nothing. It sits at the end of a fifty-year lineage that runs from tabletop role-playing games, through the first text-based multiplayer worlds, and out into the graphical MMOs most players know today. Understanding that lineage explains almost every design choice in the engine: why the world is made of rooms, why combat is round-based, why content and engine are strictly separated, and why TelosMUD can ship a D&D 5e ruleset as nothing more than a data pack. This page is background and color — no code required.

Tabletop role-playing games

The genre’s taproot is Dungeons & Dragons (Gygax and Arneson, 1974): the first game where players inhabited persistent characters in a shared imagined world whose outcomes were adjudicated by a referee — the Dungeon Master — using dice and a rulebook. Two ideas born here run straight through to TelosMUD. First, the separation of rules from setting: the mechanics (how you roll to hit, how damage works, how you level) are a general system, while the world (this dungeon, that dragon, this town) is content laid on top. Second, the dice-driven, adjudicated resolution of uncertain actions — the ancestor of every to-hit roll and saving throw in the games that followed.

That rules-vs-setting split matured through the d20 lineage — D&D 3rd Edition (2000) and its System Reference Document, and later 5th Edition — which did something crucial for a project like this: it published the rules under open licenses. The 3e-era Open Game License (OGL) and the 5e SRD’s later Creative Commons (CC-BY) release made the core mechanics legally reusable. That is precisely why TelosMUD can plan an SRD5 content pack: the engine provides the mechanism, and a freely licensed ruleset can be poured in as content. The same openness underlies the D6 Space pack (OpenD6, released under the OGL).

MUDs

In 1978, Roy Trubshaw and Richard Bartle built MUD1 (“Multi-User Dungeon”) at Essex University — a tabletop-style adventure world that many players could inhabit at the same time, typing commands and reading text descriptions. As it spread onto the early internet over telnet, MUD1 established the template every text MUD still follows: a world made of interconnected rooms, populated by mobiles (mobs) and objects, driven by a command parser, with output narrated to everyone present.

By the late 1980s and early 1990s the genre split into distinct codebase lineages, and two of them shaped TelosMUD directly:

  • DikuMUD (1990) and its descendants Merc and ROM codified the “hack-and-slash” model: hardcoded classes and levels, room/mob/object prototypes with numeric IDs and resets, round-based combat, and the act() messaging primitive that renders an event from each observer’s perspective. This is a fast, opinionated, C-coded engine where the rules live in the engine.
  • LPMud (Lars Pensjö, 1989) took the opposite tack: a compiled driver provided only the low-level machine — networking, an object database, an embedded language interpreter — while the entire game, including its rules, was written as softcode in a separate mudlib loaded on top. The driver knew nothing about combat or classes; the mudlib supplied all of it.

TelosMUD deliberately blends the two. It echoes the Diku/ROM feel that players recognize — rooms, round-based combat, Diku-style keyword/numbered targeting, act()-style messaging — but it adopts the LP philosophy of a strict driver/mudlib split: the Go engine is the driver (mechanism only), and every rule and every room is content (flavor). Where LPMud drew that line at “compiled driver vs. interpreted mudlib,” TelosMUD draws it at “engine vs. content packs,” achieving the same goal — the game is data, not code. See the Overview for how that pillar is realized.

Later MMOs

The graphical massively-multiplayer online games of the late 1990s and 2000s — EverQuest (1999) and then World of Warcraft (2004) — were the direct descendants of MUDs, keeping the underlying structure while replacing the text with 3-D graphics. Much of what feels like “MMO design” was inherited straight from MUDs: worlds partitioned into zones, aggro/threat in combat, loot tiers and rarity, respawning content, and instancing to handle crowds.

TelosMUD borrows several of those refinements back into a text engine:

  • Rich-client data via GMCP — sending structured character, room, and inventory state alongside the text so modern clients can draw health bars, maps, and panels, much like an MMO UI.
  • Loot rarity and pity systems, per-instance item quality, and scheduled world-boss spawns driven by the orchestration layer.
  • Sharding: distributing zones across servers so the world can scale beyond one machine — the MMO scale problem, solved for a MUD via cross-shard handoff and dynamic placement.

Where TelosMUD sits

TelosMUD is a synthesis of all three eras:

  • From tabletop, the rules-vs-setting separation and openly licensed rulesets it can host as content.
  • From Diku/ROM, the recognizable text-MUD feel — rooms, round-based combat, classes, keyword targeting, act() messaging.
  • From LPMud, the driver/mudlib philosophy, taken to its conclusion as a hard engine-vs-content boundary where the entire game is a swappable data pack.
  • From MMOs, the scale story (zone sharding, handoff, directors) plus modern affordances — OAuth terminal-native login and GMCP rich-client data.

The result is an engine whose flavor is entirely content-defined, which is why it can host very different rule systems from the same code: a Diku-style demo world today, and — as design targets — a D&D 5e SRD pack, a WoW-like d20 pack, and a D6 Space dice-pool pack. If any single lesson from fifty years of MUD history is baked into TelosMUD, it is this: keep the engine general, and let the world be data.