World Creation & Content Pipelines

research Doc 19

Contents

How MUDs create, review, deploy, and maintain areas at scale. Covers the full lifecycle from a builder’s first idea to a live area receiving player feedback, plus how mature MUDs with hundreds of areas keep everything coherent.

1. Area Creation Lifecycle

The process from concept to live area follows a well-established pipeline across MUD codebases. Individual MUDs vary in formality, but the phases are remarkably consistent.

1.1 Concept Phase

Every area starts with a core idea that answers three questions: what is this place?, why would players go here?, and where does it fit in the world?

Key decisions at concept:

Theme and setting — A pirate cove, a giant’s fortress, a haunted library. Aardwolf requires all themes to be original; areas cannot be based on copyrighted material (books, movies, games) or real-world topics (electronics, historical events). Most serious MUDs enforce similar originality requirements.
Level range — What tier of players is this for? This determines mob stats, item power budgets, and which continent or region the area connects to.
Narrative purpose — Is this a leveling grind zone, a quest hub, a boss encounter area, a social/roleplay space, or exploration content?
Geographic context — Where does it physically sit in the world? What areas border it? What terrain types does it use?
Size estimate — Small leveling areas run ~50 rooms; mid-level areas ~100; large areas 150-200+. Aardwolf caps first-time builders at 50 rooms/objects/mobs.

At Aardwolf, builders submit their concept to the immortal staff via the personal board with “your area idea/theme/plan, level range of the area, and how large the area is.” Samples of prior work are appreciated. At TBA (The Builder Academy), builders write a formal proposal covering location, level/alignment design, concept, plot, and size — specifically so staff “can catch some of these mistakes early on.”

1.2 Planning

Once the concept is approved, builders plan the area in detail before touching OLC. This phase is universally recommended and frequently mandated.

What gets planned:

Room map — A hand-drawn or tool-generated map showing room layout, exits, major landmarks, and flow. The SMAUG building guide specifically recommends creating visual maps showing “room layouts, major landforms, and feature items before writing descriptions.”
Mob roster — List of every NPC: name, level, role (boss, guard, shopkeeper, atmosphere), rough stats, and any special behaviors (mobprogs/Lua scripts).
Item list — Equipment, quest items, keys, consumables. What they do, where they load, approximate stat budgets.
Quest/goal design — If the area has quests, the puzzle logic, reward structure, and any scripting requirements get sketched out.
Area layout model — The SMAUG guide identifies five layout patterns:
- Linear — Single path A to B to C
- Layered linear — Multiple entry points, fixed difficulty progression
- Fluid linear — Interconnected difficulty levels
- Nonlinear — Compartmentalized encounters, free exploration
- Mega-areas — 500+ rooms with multiple sub-areas

Aardwolf’s documentation puts it directly: “map out your area’s rooms, mobiles, objects, and ideas for any mobprograms before you start building, which will give you a much easier time building the area.”

1.3 Building

The actual construction phase. Builders use either OLC (Online Creation) or external tools to create rooms, mobs, objects, and scripts.

OLC workflow (the standard approach):

All major codebases (ROM, SMAUG, CircleMUD, Aardwolf V3) ship with OLC editors: redit (rooms), medit (mobs), oedit (objects), mpedit/mpedit (mob programs), aedit/zedit (area/zone config).
Builders work on a dedicated builder port — a separate instance of the MUD used only for construction. Aardwolf requires all building on the builder port; offline ROM area creators (MZF, etc.) are explicitly not accepted.
Aardwolf’s V3 system uses a menu-driven approach with zone keys instead of traditional vnums, allowing areas to expand indefinitely. Editors work on data copies rather than live objects; changes only persist on confirmation.
Key discipline: save frequently. The Cleft of Dimensions guide stresses “type asave changed frequently” to prevent data loss during crashes.

Room creation essentials:

Title, description (5-6 lines is typical; “keeping descriptions to a decent length is important”), sector/terrain type, room flags, exit connections.
Extra descriptions for objects mentioned in the room text — these reward curious players who examine things.
Exits can be one-way or two-way, locked (requiring a key vnum), or flagged with special properties.

Mob creation essentials:

Name, short description, long description (shown in room), detailed description (shown on examine).
Level, alignment, hit/mana/damage dice, AC values, wealth.
Race presets that auto-set multiple flags. Act flags for behavior. Vulnerability/resistance/immunity flags.
Shop setup for merchants: hours, profit margins, inventory types.

Object creation essentials:

Type (weapon, armor, container, pill, etc.), level, wear locations, weight, cost.
Stat enchantments via addaffect (e.g., +2 strength) or complex conditional effects via addapply.
Long descriptions should work contextually regardless of where the item gets dropped.

Writing approach (from the SMAUG guide):

Turn off the computer; write descriptions longhand first
Organize notes into text files per room
Use text editors with spell-check and thesaurus
Transfer to MUD client with appropriate formatting
Implement mob programs for atmosphere
Test mob and object interactions

1.4 Internal Testing

Builder self-review before showing the area to anyone else.

Self-review checklist:

Walk every room path — are all exits connected correctly? No dead ends unless intentional?
Check every mob loads where expected and behaves correctly on area reset
Verify all objects load, equip properly, and have correct stats
Test quest/goal scripts end-to-end
Read every description aloud — do they flow? Are there typos?
Run the area syntax checker if available (CircleMUD: bin/circle -c)
Verify reset commands work: mobs repopulate, doors re-lock, objects respawn

SMAUG Editor provides automated checks: unused/unreferenced item detection, syntax checking of mob programs against command/skill files, and an “area walkthrough” simulation that previews room descriptions with loaded content.

1.5 Peer Review

Other builders review the area before it goes to admin. This is where most quality problems get caught.

What peer reviewers look for:

Writing quality — Grammar, spelling, tense consistency, description length, tone match with the game’s voice
Spatial logic — Does the geography make sense? Can you visualize the space? Do exits correspond to what’s described?
Balance — Are mob stats appropriate for the target level range? Are item rewards proportional to difficulty?
Originality — Is this a fresh concept or a reskin of an existing area?
Player experience — Is there enough to do? Is navigation intuitive? Are there frustrating dead-end paths?
Technical correctness — Do resets work? Do scripts fire? Are vnums clean?

At The Builder Academy, trial rooms receive detailed feedback: “We’ll review your trial room once it is complete and may make suggestions to rewrite parts.” The documentation emphasizes this is “normal and should not be interpreted as an insult.”

1.6 Admin Approval

The Head Builder or immortal staff does a final review. This is the formal gate before an area goes live.

Admin review covers:

Everything from peer review, plus:
World integration — Does the area fit the game’s lore and geography? Is the level range appropriate for its location?
Power budget — Will the items introduced disrupt game balance? Are rewards proportional?
Technical health — No broken exits, no orphaned vnums, no script errors
Policy compliance — No copyrighted content, no inappropriate themes, no references that break immersion
Accessibility — Screen reader compatibility, no ASCII art dependency for critical information

1.7 Deployment

Moving an approved area from the builder port to the live game.

CircleMUD deployment process:

Copy area files (.wld, .mob, .obj, .shp, .zon) to the appropriate lib/world/ subdirectories
Register filenames in index files
Run syntax validation (bin/circle -c)
Restart or hotload the zone

Aardwolf deployment:

Areas are “installed on the main port” once complete and approved
The area becomes “a permanent part of Aardwolf”
Builders receive a unique medal with extra stats as a personal reward

Announcement: Most MUDs announce new areas to players via in-game boards, login messages, or changelogs. This drives exploration and gives the builder recognition.

1.8 Post-Launch

The area is live, but work isn’t done.

Player feedback — Bug reports, balance complaints, navigation confusion, quest-breaking edge cases
Balance adjustments — Mob difficulty tuning, item stat tweaks, reward rate changes based on actual player data
Bug fixes — Broken scripts, missing exits, typos players catch
Content updates — Seasonal events, quest additions, description refreshes
Legacy maintenance — Over time, areas may need updating to match new game systems, code changes, or evolving world lore

2. Content Approval and Quality Gates

Mature MUDs run multi-layered quality checks. The gates below represent composite best practices drawn from Aardwolf, TBA, SMAUG communities, Forgotten Kingdoms, and Cleft of Dimensions.

2.1 Writing Quality Standards

Standard	Details
Description length	5-6 lines typical; hack-and-slash games trend shorter, RP games longer. “The ideal/desired description length will really depend on your target audience.”
Point of view	Most MUDs require third-person objective. “Descs should stay objective, avoiding references to the reader.” No “You feel scared.” Some games allow subjective approaches when creative.
Grammar and spelling	Complete sentences required. Spell-check before submission. The SMAUG Editor includes built-in spell-checking.
Tense consistency	Present tense is standard for room descriptions. Past tense for lore objects.
Color standards	MUDs with color have explicit standards. FK has “Colourising Rooms Standards,” “Colourising mobiles standards,” and “Colourising objects” guidelines.
Naming conventions	Room titles often follow “Area Name - Room Name” format. Mob names avoid leading articles unless quoted. Item names include hidden tags (+wtype for weapons, =slot for armor).
Style guide	A formal document maintained by the Head Builder covering all the above. Typically housed on a wiki, in-game help system, or shared doc.

2.2 Balance Review

Mob difficulty — HP, damage dice, AC, and special abilities must match the target level range. Some codebases provide formulator tools to calculate appropriate values from mob level.
Item stats — Power budgets per level tier. Enchantments (+str, +dex, etc.) must not exceed caps. Items should not outclass gear from adjacent level ranges.
Reward rates — XP, gold, and quest point yields should be in line with existing areas of similar difficulty. No area should become the “only place to level” because rewards are disproportionate.
Economy impact — New gold faucets (mob drops, quest rewards) must be balanced against the game’s existing sink structure. Introducing too much gold or too-powerful items destabilizes the economy.

2.3 Integration Review

Lore fit — Does the area’s story align with established world history and geography?
Level range appropriateness — Is the area placed in a region where its level range makes sense? Players shouldn’t walk from a level 10 zone directly into a level 90 zone without clear in-game signaling.
Continent/region placement — Does the physical geography work? A tropical island shouldn’t connect directly to an arctic tundra without a transition zone.
Cross-area dependencies — CircleMUD’s manual discourages zones referencing other zones’ mobs/objects: “this practice is discouraged because it makes zones less modular, meaning that it becomes more difficult to add or remove one zone without affecting another.” Self-contained areas are easier to maintain.

2.4 Technical Review

Check	What It Catches
Syntax validation	Malformed area files, missing terminators, bad vnums
Exit verification	Broken links, one-way exits that should be two-way, exits to nonexistent rooms
Reset testing	Mobs not repopulating, objects not loading, doors not resetting to correct state
Script testing	Mobprog/Lua scripts that error, infinite loops, triggers that don’t fire
Vnum hygiene	Unused vnums, duplicate assignments, range conflicts
Load testing	Area with maximum mob population — does the server handle it?

CircleMUD requires every world file to be “terminated by the dollar sign ($) to tell the server that the file has ended.” Missing terminators are a common deployment-breaking bug.

2.5 Accessibility Review

MUDs have a significant blind player community, making accessibility a genuine quality concern, not a checkbox exercise.

Key checks:

No ASCII art dependency — ASCII art “will sound like a confusing, garbled mess” to screen readers. Any information conveyed through ASCII art must also be available in plain text.
Color is informational, not essential — Color-coded information must have text equivalents. Cyan for new players becomes “(new)” in screen reader mode.
Screen reader mode support — Strip unnecessary visual elements, trim verbose descriptions, use double colons (::) to create audible pauses between information segments.
Table alternatives — Screen readers can’t walk through table cells. Break tabular information into lines with commas or colons.
Player-created content tagging — Systems for marking ASCII art with one tag and providing text descriptions with another, displaying the appropriate version based on user settings.
Community input — “Talk to players who use screen readers and get their input” about where the experience has weak spots.

3. World Management at Scale

How MUDs with 200-300+ areas, built by dozens of volunteer builders over decades, maintain coherence.

3.1 Area Ownership and Builder Assignments

One builder, one area — Aardwolf enforces this strictly: “Builders are only allowed to work on one area at a time, and once your current area is complete and installed on the main port, you can apply to build a new one.”
Area authorship is permanent — The builder’s name is attached to the area forever. This creates pride of ownership and accountability.
Inactivity policy — Aardwolf archives areas after two months of builder inactivity. Whether it can be restored depends on whether the vnums have been reused. Builders must notify staff if taking a hiatus.
Confidentiality — “Builders cannot discuss areas in progress, quest solutions, or building tools with other players.” Unauthorized entry into another builder’s area results in immediate loss of builder status.

3.2 Consistent Lore and Worldbuilding

The core tool for consistency is the builder’s style guide — a living document maintained by the Head Builder.

What a style guide covers:

Room name format and length (“room names should be 3-6 words in length”)
Description length, tone, and voice requirements
Allowed and prohibited content (real-world references, humor level, graphic content)
Color/formatting standards
Object and NPC naming conventions
Geographic and historical lore that builders must respect
Technology level and magic system constraints

The Head Builder is “in charge of reviewing and approving building projects” and acts as the lore gatekeeper. In the absence of a designated Head Builder, “this responsibility may be taken up by the head admin, implementor, or a group effort involving multiple builders.”

Cross-builder coordination:

Shared lore documents and world histories
Regular builder meetings (Aardwolf holds meetings where “the various rules will be discussed”)
In-game help files documenting world facts that all builders must respect
Vnum range allocation managed centrally to prevent conflicts

3.3 Maintaining Quality Across Volunteer Content

Quality variance is the fundamental challenge of volunteer-built MUDs. The most common approaches:

Tiered permissions — New builders get restricted access (limited vnum ranges, smaller areas). Full building privileges come after proving competence through trial areas.
Mandatory review — Every area passes through peer review and admin approval before going live. No exceptions.
Style guide enforcement — Reviewers check against the documented standards. Areas that don’t meet writing quality standards get sent back for revision.
Head Builder role — A dedicated person whose job is quality control, not just building their own areas.
Community standards — Builder communities self-police when there’s a strong culture of craftsmanship. The SMAUG guide draws an explicit distinction between “builders” (generic creators) and “Builders” (quality-focused creators).

3.4 Retiring and Updating Outdated Areas

Legacy content management is an ongoing challenge, especially for MUDs running for 20+ years.

Content refresh cycles — Periodic review of older areas for outdated descriptions, unbalanced stats, or broken scripts
System migration — When the codebase adds new features (e.g., Aardwolf adding Lua scripting), older areas may need updating to take advantage of new capabilities
Player data dependencies — Areas can’t just be removed if players have items, quest completions, or achievements tied to them
Archival vs. removal — Some MUDs “soft-retire” areas by disconnecting them from the main world map but keeping them accessible to admins for reference
Vnum reuse risks — Aardwolf notes that whether archived areas can be restored “depends on whether the vnums have been reused”

3.5 Area Interconnection and Continent Management

Zone modularity: CircleMUD’s design philosophy is instructive — each zone should be “a single, modular, geographically coherent region” with a consistent storyline. Zones can reference other zones’ content, but this is discouraged for maintainability.

Continent structure: Large MUDs organize areas into continents or regions with controlled connection points. Aardwolf uses multiple continents, each containing clusters of areas connected by roads, portals, or geographic transitions.

Connection management:

Entry/exit points between areas are coordinated by the Head Builder
New areas must connect to existing geography logically
Transition zones buffer incompatible themes (you don’t walk from a medieval village directly into a sci-fi station)
Maps (in-game ASCII maps, external mapping tools) help visualize the overall world structure and identify where new areas can fit

3.6 Level Range Coverage and Gap Analysis

Mature MUDs track which level ranges are well-served and which have content gaps.

Common approach:

Maintain a spreadsheet or database of all areas with their level ranges
Identify “dead zones” — level ranges where players have few or no areas to explore
Prioritize new builder proposals that fill identified gaps
The areas command in most MUDs lists all areas with their level ranges, making gaps visible to staff

Aardwolf’s scale: Over 200 areas and 30,000+ rooms, “most of which are unique, having been created by the players themselves.” The game supports levels 1-201 across 10 remort tiers, requiring content across a massive level range.

4. Builder Recruitment and Training

4.1 Finding and Recruiting Builders

Most MUDs recruit builders from their existing player base. The pipeline:

Player interest — Active players who enjoy the game’s world and demonstrate writing ability
Application — Formal proposal submitted to immortal staff. Aardwolf requires an outline with “your area idea/theme/plan, level range of the area, and how large the area is”
Availability windows — Aardwolf notes that “building applications are not currently open” and applicants should watch announcement boards for openings. Not all MUDs accept builders continuously.
Work samples — Some MUDs request writing samples or portfolio pieces

4.2 Training Programs and Mentorship

The Builder Academy (TBA) is the gold standard for MUD builder training — an entire MUD dedicated to teaching building skills.

TBA training pipeline:

Apply with a small project proposal (5-20 rooms)
Receive a trial vnum: 1 room, 1 object, 1 mobile
Build the trial room under mentorship
Trial room review with detailed feedback and revision suggestions
Once trial is approved, receive OLC privileges for the initial project
Complete the project; get reviewed by immortals
Become a “full-fledged qualified builder”

Ongoing support at TBA:

Extensive help files on “almost everything”
No deadlines or pressure
Regular staff members available for questions
New builders can help other new builders with their vnums while learning

Forgotten Kingdoms runs a structured lesson program covering: Mobiles, Objects, Rooms, Shops, Resets, Specials, and Quests — with specific lessons on colorizing standards and an area submission process guide. Downloadable offline builder lessons are available in PDF.

4.3 Trial Areas and Probationary Periods

Nearly universal across MUDs:

First area is small — Aardwolf caps at 50 rooms/objects/mobs. TBA starts with 5-20 rooms.
Close supervision — Trial work gets detailed review that production areas might not
Iterative feedback — “We may make suggestions to rewrite parts” — this is learning, not punishment
Graduation — After the trial area is approved and deployed, the builder can propose full-sized areas
Probationary access — New builders operate with restricted permissions through the builders command

4.4 Builder Documentation and Style Guides

What good builder docs include:

OLC command reference for the specific codebase
Style guide with writing standards, naming conventions, and examples
World lore reference (history, geography, factions, magic system)
Stat formulas and balance guidelines
Example areas to study
Accessibility requirements

Examples in practice:

Aardwolf maintains a web-based builder guide at build.aardwolf.com
Cleft of Dimensions has a detailed wiki-based building guide covering all OLC modes
Forgotten Kingdoms provides indexed lesson topics with downloadable PDFs
SMAUG community has Herne’s building pages as a comprehensive reference

4.5 Motivating Volunteer Builders Long-Term

Builders are volunteers. Keeping them engaged is an ongoing challenge.

What works:

Recognition — Builder name permanently attached to their area. Aardwolf gives builders “a unique medal with extra stats as a personal thank-you.”
Creative freedom — Within the style guide constraints, let builders pursue themes they’re passionate about
Community — Builder-only channels, meetings, and social spaces create belonging
Visible impact — Seeing players explore and enjoy your area is the primary motivator
Progressive responsibility — Moving from trial areas to full areas to potentially mentoring new builders
No artificial deadlines — TBA emphasizes “no deadlines or pressures.” Volunteer burnout comes from obligation, not from building itself.
Alternative contribution paths — Aardwolf notes that “helping build goals in Lua is open” for those who want to contribute without committing to a full area

What kills motivation:

Feeling underutilized or that work doesn’t matter
Harsh criticism without constructive guidance
Bureaucratic overhead that makes building feel like a job
Areas sitting in review limbo for months
Lack of feedback from players or staff

5. External Building Tools

5.1 Offline Area Editors

The Diku MUD family has a tradition of offline area editors predating OLC. These remain useful for bulk editing, cross-referencing, and working without a network connection.

SMAUG Editor (v1.34):

Windows GUI for editing SMAUG and ROM area files
Checkbox/dropdown interfaces instead of manual numeric entry
Tree views showing mobs with associated programs and room hierarchies
Cross-reference displays showing where mobs/objects are loaded
Syntax checking of mob programs against command/skill files
Comprehensive “area checks” identifying unused or unreferenced items
Built-in spell-checking for descriptions
“Area walkthrough” simulation previewing room descriptions
ROM-to-SMAUG and SMAUG-to-ROM conversion
Vnum renumbering across entire areas including program references
Works under Wine on Linux

AVAE (Ack!Mud Visual Area Editor):

Full-featured offline editor for ACK! area files
XML-based settings, potentially adaptable to other formats

Aardwolf’s approach: Explicitly rejects offline editors. “Offline ROM area creators (MZF, etc.) are not accepted.” All building must happen on the builder port to ensure consistency and real-time validation.

5.2 Map Planning Tools

MUD Map Builder:

.NET library that generates map images from JSON area descriptions
Automatically places rooms on a 2D grid to produce PNG images
Useful for documentation and review

MapMaker (Aarchon MUD):

Browser-based visual map editor
Can generate OLC code that is pasted directly into a MUD client to build the area
Bridges the gap between visual planning and in-game construction

MUD Map (SourceForge):

Desktop mapping tool for text-based games
Supports 10 directional connections (N/NE/E/SE/S/SW/W/NW/Up/Down) plus custom exits
Sub-area support for organizing maps within maps (continents, dimensions)
Areas are color-coded and grouped in the places list

MUD Map Designer:

Export to multiple image formats
Designed for plotting area layouts during the planning phase

5.3 Stat Calculators and Balance Tools

Dedicated MUD stat calculators are less common as standalone tools — most codebases build balance formulas into the game itself:

Formulator tools — Built into some codebases (Cleft of Dimensions mentions one) to calculate appropriate HP/armor values from mob level
Mob level-to-stats formulas — Most Diku-family MUDs have standard formulas mapping mob level to hitdice, damdice, and AC. Builders reference these when setting stats.
Item power budgets — Informal or formal guidelines on maximum enchantment totals per item level tier
Spreadsheets — Many builders maintain personal spreadsheets mapping level ranges to expected mob HP, damage output, and item stat ceilings. These are typically shared within builder communities but rarely published publicly.

5.4 Version Control for Area Files

Traditional MUDs predate modern version control, and most still don’t use git for area files. However, approaches exist:

Area files are text-based — CircleMUD uses plaintext .wld, .mob, .obj, .shp, and .zon files. ROM and SMAUG use similar text formats. This makes them theoretically git-friendly.

In practice:

Most MUDs rely on OLC’s built-in save system rather than external version control
Aardwolf’s V3 system saves “every game object as its own file or row in a database” — more granular than traditional area files but harder to diff
Some MUD administrators manually back up area directories on a schedule
Modern frameworks like Evennia, being Python-based, integrate naturally with git

Evennia’s approach — batch processors:

Batch Command Processor — Executes a sequence of in-game commands from a .ev file. The builder character physically moves through the world executing commands sequentially. Files are stored in mygame/world/ and can be version-controlled.
Batch Code Processor — Runs full Python code in chunks. Much more powerful: “practically anything imaginable can be coded and handled.” No in-game character involved. Superuser-only for security reasons.
Both approaches produce files that can be checked into git, reviewed in pull requests, and rolled back — a significant advantage over traditional OLC-only workflows.

5.5 Collaborative Editing Approaches

Builder ports — The most common collaboration model. A dedicated server instance where multiple builders work simultaneously, each in their own vnum range. Aardwolf, TBA, and most Diku-family MUDs use this.

Vnum allocation — Central coordination prevents conflicts. Each builder gets an assigned range. Cleft of Dimensions advises consulting “head builders for vnum allocation and area expansion.”

Access control:

The builders command restricts who can edit which area
Security levels gate access to more powerful OLC features
Builder-level immortals can only modify areas they’re assigned to

Review workflows:

Builder completes area on builder port
Peer reviewer walks the area, checking against standards
Head builder does final review
Area files are copied/installed on the live port

Modern alternatives:

Evennia’s batch files enable git-based workflows with pull request reviews
Some communities use shared documents (Google Docs, wikis) for planning and description drafting before building in-game
Discord/Slack channels for real-time builder coordination