MUD Text UI Design

A comprehensive guide to the visual and formatting conventions that define the MUD player experience. Everything here is rendered in a fixed-width terminal — the constraints are the medium.

1. The MUD Prompt

The prompt is the most-seen element in a MUD. It fires after every command, every combat round, every tick. It is the player’s HUD.

Standard Elements

Most MUD prompts include some combination of:

Aardwolf Prompt System (Industry Standard)

Aardwolf’s prompt system is one of the most fully-featured and widely imitated. Players build prompts from ~50+ variables:

prompt %hhp %mmn %vmv qt%q>

Produces:

10hp 10mn 10mv qt0>

A more detailed example:

prompt [%p-%h/%Hhp %P-%m/%Mmn %v/%Vmv QT: %q Tnl: %X Tells: %t%d %e] >%c

Produces:

[100%-5000/5000hp 100%-5000/5000mn 5000/5000mv QT: 15 Tnl: 5000 Tells: 0 Dbl: 1 NESWUD] >

Color-coded version:

prompt {@g%h@w/@G%Hhp @r%m@w/@R%Mmn @B%v/%Vmv @W%Xtnl @Y%qmin@M%d@w}

Produces (with ANSI color):

{2766/2920hp 2048/2129mn 1963/1963mv 1921tnl 11min Dbl: 1}
 green/GREEN  red/RED       blue         white   yel   mag

Battle Prompts vs Exploration Prompts

Most MUDs support separate prompts for combat and exploration via bprompt:

Exploration prompt — emphasizes navigation, quest status, resource awareness:

<4500hp 1200mn 1963mv QT:15 NESW>

Battle prompt — adds enemy health, group leader status, strips room info:

<4500hp 1200mn 1963mv Enemy: 78%>
You:100% Enemy:78%
<4200/4800hp 1200/2500mp 1963/1963mv

The %b token (enemy health percentage) only works in battle prompts. The %r (room name) and %e (exits) tokens only work in regular prompts. This separation is intentional — different contexts need different information.

Color as Urgency

A common convention: HP/mana values automatically turn red when below 25% of max (autowarn). This transforms the prompt from passive display into active alert system without adding text.

<4500hp 1200mn 1963mv>     # normal - all green/white
<1100hp 1200mn 1963mv>     # HP turns red - danger
< 300hp  200mn 1963mv>     # HP and mana red - critical

Prompt Design Principles

• Brevity wins. Players see this line thousands of times per session. Every character counts.
• Current/Max is clearer than percentage alone for resource management, but percentage is better for quick scanning.
• Color codes at the start of the prompt (e.g., @w) prevent color bleeding from previous output.
• The > character is the universal “ready for input” signal. Some MUDs use ) or - or nothing.
• Multiline prompts are possible (via %c for carriage return) but uncommon — they eat screen real estate.

2. Score / Character Sheet Display

The score command is the character sheet. It is typically the densest single screen of information a player sees.

ROM/Diku Standard Format (Prose Style)

The classic DikuMUD/ROM score output uses formatted prose:

You are Valdris the Warrior, level 42, 3 years old (127 hours).
Race: Human  Sex: Male  Class: Warrior

You have 910/1040 hit, 122/122 mana, 651/651 movement.
You have 14 practices and 3 training sessions.
You are carrying 23/100 items with weight 156/300 pounds.

Str: 18(21)  Int: 12(12)  Wis: 14(14)  Dex: 16(19)  Con: 15(18)

You have scored 364178 exp, and have 12450 gold and 340 silver coins.
You need 35822 exp to level.

Hitroll: 24  Damroll: 31
Armor: pierce: -45  bash: -38  slash: -42  magic: -30

You are standing.
You are affected by: sanctuary haste

The parenthetical stats notation — Str: 18(21) — means 18 natural, 21 with equipment/spells. This convention is universal across Diku-family MUDs.

Bordered/Panel Style

More modern MUDs use ASCII borders for visual structure:

+-----------------------------------------------------------+
|  Valdris the Battlemaster         Level: 42 (Tier 3)      |
|  Race: Human     Class: Warrior   Clan: Steel Legion      |
+-----------------------------------------------------------+
|  HP: 4500/4800   Mana: 1200/2500   Moves: 1963/1963      |
|  STR: 21 [18+3]  INT: 12          WIS: 14                 |
|  DEX: 19 [16+3]  CON: 18 [15+3]   LCK: 16                |
+-----------------------------------------------------------+
|  Hit/Dam: +24/+31          Armor Class: -45               |
|  Alignment: 1000 (Saintly) Position: Standing             |
|  Gold: 12,450              Quest Points: 340              |
|  Exp: 364,178              To Level: 35,822               |
+-----------------------------------------------------------+
|  Affects: sanctuary, haste, stone skin                    |
+-----------------------------------------------------------+

Information Hierarchy

Score screens generally follow this order:

1. Identity — Name, title, level, class, race, guild/clan
2. Vitals — HP, mana, movement (current/max)
3. Attributes — Str, Int, Wis, Dex, Con (natural + modified)
4. Combat stats — Hit/dam rolls, armor class
5. Resources — Gold, quest points, experience
6. Status — Position, alignment, active effects/spells
7. Progression — XP to next level, trains/practices remaining

Accessibility Consideration

The Discworld MUD offers a screen-reader mode for score that strips ASCII borders and color, inserting colons as audible pauses instead. Good MUD design separates data from presentation.

3. Room Display Formatting

Room display is the most important prose output in a MUD. It is the world.

Standard Display Order

Almost every MUD follows this sequence:

[1] Room Name
[2] Room description (paragraph of prose)
[3] Obvious exits
[4] NPCs/creatures present
[5] Items on the ground
[6] Other players

Example (Verbose Mode)

The Town Square
   A wide cobblestone square stretches before you, dominated
by a weathered stone fountain at its center.  Merchants hawk
their wares from colorful stalls lining the eastern edge,
while the imposing facade of the Adventurers' Guild rises to
the north.  The air smells of fresh bread and horse dung.

Obvious exits: north east south west
A grizzled town guard stands here, watching the crowd.
A mangy dog is sleeping here.
A small leather pouch lies on the ground.
Valdris the Warrior is standing here.

Color Coding Conventions

While not universal, these color associations are common:

Formatting Rules (Discworld Ten Commandments)

The Discworld MUD’s style guide codified several important rules that are widely applicable:

1. Never start with “You are standing in…” — Remove direct references to the player. Describe the place, not the player’s experience of it.
2. Double-space between sentences in fixed-width fonts to improve readability (this is debated but traditional).
3. Avoid color in room descriptions — Color is powerful but garish when overused. Save it for mechanical elements (exits, NPCs), not prose.
4. If you mention a noun, make it examinable — Every object named in a description should respond to look <noun>.
5. NPCs are separate from room descriptions — Don’t embed living things in the room description text; they should appear as separate lines below.
6. 80 characters per line maximum — The terminal standard. Descriptions that exceed this wrap unpredictably on different clients.
7. 3-space indent for multi-line descriptions — Single-line descriptions have no indent.
8. Don’t waste description space on exits — That is what the exits line is for.

Brief vs Verbose

Most MUDs support at minimum two room display modes:

Verbose — Full description every time you enter a room (default for new players).

Brief — Room name and exits only on revisited rooms; full description on first visit:

The Town Square
Obvious exits: north east south west
A grizzled town guard stands here.

Some MUDs offer granular control — brief combat (suppresses missed attacks and fully-absorbed hits), brief channels, brief movement messages. The Discworld MUD lets players toggle brief on individual subsystems independently.

Description Length Guidelines

• Hack-and-slash MUDs: 2-4 sentences. Players are here to fight, not read.
• RP-focused MUDs: 4-8 sentences. Atmosphere matters.
• Room names: 3-6 words. Think of them as section headers.
• Never write so much that a player has to scroll to see the exits and NPCs.

4. ASCII Maps and Navigation

Inline Minimaps

Many MUDs display a small map alongside or above room descriptions. Common sizes are 5x5 or 9x9 grids centered on the player:

     . . . . .
     . . # . .
     . . @ . .
     . . . . .
     . . . . .

Terrain Symbol Conventions

Borrowed heavily from the roguelike tradition:

Color-Enhanced Maps

When ANSI color is available, terrain symbols gain a second dimension of meaning:

  Green .   = grassland
  Yellow .  = desert/sand
  Blue ~    = deep water
  Cyan ~    = shallow water
  Green %   = deciduous forest
  Dark green % = dense forest
  White ^   = snow-capped mountain
  Brown ^   = foothills
  Red !     = danger/quest marker

Wilderness Systems

Some MUDs implement large-scale wilderness with coordinate navigation:

Map of the Northern Reaches [47, -12]
  . . . ~ ~ ~ . . .
  . % % ~ ~ . . ^ ^
  . % % . . . ^ ^ ^
  . . . . @ . . ^ .
  . . * . . . . . .
  . . . . . . % % .
  . . . . ~ ~ % % .

Legend: . plains  % forest  ~ water  ^ mountain  * town  @ you
Coordinates: 47 North, 12 West

Discworld Map Command

The Discworld MUD’s map command shows your surroundings using a top-down grid view. Rooms are clickable links (in MXP-capable clients), so clicking on the map walks you to that room. This bridges pure text and point-and-click navigation.

Client-Side Mapping

Modern MUD clients (Mudlet, zMUD/CMUD) can build graphical maps from room data, either by parsing output or through GMCP room data:

{
  "num": 12345,
  "name": "On a hill",
  "area": "Barren hills",
  "environment": "Hills",
  "coords": "45,5,4,3",
  "exits": {"n": 12344, "se": 12336}
}

Mudlet’s mapper renders these as full 2D/3D graphical maps with room shapes, exit lines, and area coloring. For MUDs without GMCP, Mudlet can render ASCII grid maps as overlays using hardware-accelerated rendering.

5. Communication Formatting

Channel Types and Visual Conventions

MUDs typically distinguish communication by scope, each with its own formatting:

Say (room-local, IC):

Valdris says, "Anyone seen the blacksmith?"

Tell (private, typically OOC):

Valdris tells you, "Hey, what level are you?"
You tell Valdris, "42, you?"

Whisper (close-range, IC):

Valdris whispers to you, "Watch the guard by the gate."

Shout/Yell (area-wide, IC):

Valdris shouts, "INCOMING FROM THE NORTH!"

Channels (global, typically OOC):

[Gossip] Valdris: 'Anyone want to group for the dragon?'
[Newbie] Theron: 'How do I equip a weapon?'
[Trade] Merchant: 'WTS +5 Sword of Flames, 5000g'
[Clan] Valdris: 'Rally at the guild hall'

IC vs OOC Formatting Conventions

In-Character (IC) — presented as direct speech or action:

Valdris says, "The road north is dangerous at night."
Valdris nods solemnly.

Out-of-Character (OOC) — typically marked with brackets, parentheses, or dedicated channels:

((brb, phone))
[OOC] Valdris: 'Anyone know the syntax for dual wield?'

Double parentheses (( )) are the near-universal convention for inline OOC comments within IC contexts.

Color in Communication

Common channel color assignments:

GMCP Communication Data

Modern MUDs send channel data via GMCP for client-side handling:

Comm.Channel.Text {
  "channel": "gossip",
  "talker": "Valdris",
  "text": "Anyone want to group?"
}

This lets clients route messages to separate windows/tabs, apply custom highlighting, and filter by channel — moving communication management from server to client.

6. Information Density Management

The fundamental tension: MUDs generate enormous amounts of text. Combat alone can produce dozens of lines per round. The player must extract actionable information from a torrent of prose.

Brief Mode as Core Tool

Most MUDs provide a brief command that toggles verbosity for multiple subsystems:

The Discworld MUD’s implementation is especially granular — each subsystem can be toggled independently:

brief               -- show current settings
brief combat        -- toggle combat to brief
verbose combat      -- toggle combat to verbose
brief room          -- toggle rooms to brief

Color as Information Architecture

Color is not decoration — it is a parsing aid. In a wall of combat text, the player’s eye should be able to:

• Spot damage dealt (one color)
• Spot damage received (another color)
• See critical events (bold or flashing)
• Ignore routine messages (gray/dim)

Example combat output with color hierarchy:

[bright white]  You slash the orc with devastating force!     # your hit
[gray]          The orc dodges your thrust.                    # your miss
[red]           The orc bashes you with its shield!            # damage taken
[yellow]        The orc is BLEEDING!                           # enemy status
[bright red]    *** You are STUNNED! ***                       # critical alert

Paging

Long output (help files, inventory lists, room descriptions in verbose areas) uses paging — the MUD sends a screenful and waits:

[Hit Return to continue, 'q' to quit]

Standard page size is 24 lines (matching the traditional terminal height), but most MUDs let players configure this.

Tables vs Prose

For dense data, tables beat prose every time:

Prose (hard to scan):

You are wearing a steel helm on your head, a chainmail shirt on your
body, leather gloves on your hands, and iron boots on your feet.

Table (easy to scan):

 <head>      a steel helm
 <body>      a chainmail shirt
 <hands>     leather gloves
 <feet>      iron boots
 <wielded>   a longsword
 <shield>    a wooden buckler

Combat Damage Consolidation

Some MUDs consolidate damage per round rather than showing individual attacks:

Individual (noisy):

You hit the orc. (14 damage)
You hit the orc. (11 damage)
You hit the orc. (18 damage)
The orc hits you. (9 damage)
The orc misses you.

Consolidated (clean):

[Round 4] You deal 43 damage to the orc. The orc deals 9 damage to you.
Orc: [████████░░░░] 67%    You: [██████████░░] 89%

The Golden Rule

If a player has to scroll up to find something important, the UI has failed. Critical information — health changes, incoming tells, quest updates — should always be visible at or near the prompt.

7. Modern MUD UI Patterns

Split-Screen Layouts

The most common modern pattern: the main output window sits in the center, with peripheral panels around it.

+------------------+------------------+
|                  |    MAP           |
|   MAIN OUTPUT    |                  |
|                  +------------------+
|                  |   VITALS/GAUGES  |
|                  |  HP [████████░░] |
|                  |  MN [████░░░░░░] |
|                  |  MV [██████████] |
+------------------+------------------+
|  COMMUNICATION TABS                 |
|  [Chat] [Tells] [Clan] [Combat]    |
+-------------------------------------+
|  > command input                    |
+-------------------------------------+

Mudlet is the reference implementation — its entire UI is moddable via Lua scripting. The Procedural Realms Script for Mudlet provides six configurable container windows with tabs for communications, mapper, vitals gauges, statistics, and combat info.

GMCP-Driven Gauges

Instead of parsing text prompts, modern clients use GMCP data to render graphical gauges:

Char.Vitals {
  "hp": "4500", "maxhp": "4800",
  "mp": "1200", "maxmp": "2500",
  "ep": "15000", "maxep": "16000",
  "wp": "14000", "maxwp": "15000"
}

Clients render these as filled bars, circular gauges, or numeric displays in dedicated panels — removing vitals information from the text stream entirely.

MXP (MUD eXtension Protocol)

MXP brings HTML-like markup to MUD output. Key features:

Clickable commands:

<send href="buy bread">bread</send>

Displays “bread” as an underlined link; clicking sends buy bread to the MUD.

Popup menus:

<send "attack orc|examine orc|flee" hint="Attack|Examine|Run away">orc</send>

Right-clicking “orc” shows a context menu with three options.

Custom elements:

<!ELEMENT RoomName '<COLOR cyan><B>' FLAG='RoomName'>
<RoomName>The Town Square</RoomName>

Defines reusable formatting tags, letting the MUD send semantic markup.

Gauges:

<GAUGE hp maxhp>

Creates a graphical health bar widget in supporting clients.

Frames (separate windows):

<FRAME name="Map" left="75%" top="0" width="25%" height="50%">

Opens a dedicated panel for specific output types like maps or chat.

Web-Based Clients

Several approaches exist for browser-based MUD play:

Iron Realms Nexus — Full-featured web client with GMCP support, scripting via JavaScript, customizable gauges and keybindings. Available as both browser app and desktop download.

MUDPortal — Cloud-based websocket proxy that connects to any MUD. Features draggable/resizable windows, MXP support, and MCCP compression.

LociTerm — Progressive Web App providing MUD telnet connectivity through any browser via a hosted server component.

Architecture: Browser clients use WebSocket (wss://) connections to a proxy server that translates to telnet. The proxy handles protocol negotiation (GMCP, MXP, MCCP) and forwards structured data to the browser client.

Mobile-Responsive Patterns

Mobile MUD clients face the constraint of small screens and no physical keyboard:

• Single-panel layout — map and gauges collapse to compact bars above/below main output
• Swipe navigation — swipe in cardinal directions to move
• Tap targets — NPCs, items, and exits are rendered as tappable elements via MXP
• Abbreviation bars — rows of common command buttons replace typing
• Iron Realms’ Nexus mobile client (Android) provides these patterns out of the box

8. ANSI Art

When to Use

• Login/welcome screens — The first thing a player sees. A good ANSI splash screen sets the tone instantly.
• Game logo/title — Displayed once at connection, so visual impact is worth the cost.
• Major events — Level-up banners, boss kills, seasonal events.
• Help file headers — Subtle decorative borders for navigation.
• Maps — Large-scale world maps as static art.

When to Avoid

• Room descriptions — ASCII art in room descriptions is generally discouraged. It creates accessibility problems, looks broken on different terminal widths, and players see room descriptions constantly.
• Frequently-displayed content — Anything the player sees repeatedly should be clean text. Art creates fatigue.
• Inline with prose — Art and prose have different visual rhythms. Mixing them is jarring.
• Without a plain-text fallback — Screen readers cannot interpret ASCII art. Always provide an alternative.

Login Screen Example Pattern

                    _____ _            _____            _
                   |_   _| |__   ___  |  ___|__  _ __ | |_
                     | | | '_ \ / _ \ | |_ / _ \| '_ \| __|
                     | | | | | |  __/ |  _| (_) | | | | |_
                     |_| |_| |_|\___| |_|  \___/|_| |_|\__|

              ================================================
                   Welcome to The Font - A World Awaits
              ================================================

                  Based on the works of J.R.R. Tolkien
                  Running since 1997 - 247 players online

              By what name do you wish to be known?

ANSI art editors like MUDdescANSI can export directly to MUD-compatible formats (MUD/MUSH/MUX/MOO @desc syntax). The 16colo.rs archive preserves MUD-related ANSI artpacks from the BBS scene.

Text-Based Progress Bars

Progress bars are a form of inline ASCII art that earns its place through utility:

HP:  [████████████████░░░░] 80%
MP:  [████████░░░░░░░░░░░░] 40%
XP:  [██████████████████░░] 92%

Character options by compatibility:

ANSI Color Reference

The standard 16-color palette available in virtually all MUD clients:

Bold/bright variants: prefix with \e[1m. Reset: \e[0m.

Extended: 256-color via \e[38;5;<n>m (foreground) and \e[48;5;<n>m (background). True color (24-bit) via \e[38;2;<r>;<g>;<b>m.

Text attributes: bold (1), dim/faint (2), italic (3), underline (4), blink (5), reverse (7), strikethrough (9).

Universally supported: codes 0 (reset), 1 (bold), and 30-37 (foreground colors). Everything else varies by client.

MUD-Specific Color Code Systems

Most MUDs implement their own shorthand rather than raw ANSI:

Convention: lowercase = normal color, uppercase = bold/bright variant.

Design Principles Summary

1. The prompt is the HUD. Treat it as your most critical UI element. Every token must earn its place.

2. Color is information architecture, not decoration. Assign colors to semantic categories and be consistent. Red = danger. Green = positive. Cyan = interactive/informational.

3. Brief mode is not a luxury, it is infrastructure. Every repeating display should have a compact variant. Respect the player’s screen real estate.

4. 80 columns is the law. Design for fixed-width, 80-character terminals. Everything else is a bonus.

5. Separate data from presentation. Use GMCP where possible. Let clients render gauges, maps, and panels however they want. Send structured data, not formatted strings.

6. The display order matters. Room name > description > exits > NPCs > items. Score: identity > vitals > stats > combat > resources. These hierarchies exist because thousands of players validated them.

7. If it scrolls past, it is lost. Put critical information where the player will see it — the prompt, persistent gauges, or separate windows. Do not bury important state changes in scrolling text.

8. Accessibility is not optional. Color should never be the only signal. ASCII art needs fallbacks. Screen readers need clean text without visual formatting.

Sources

• Aardwolf Prompt Help
• Aardwolf Prompt Examples
• Aardwolf GMCP Documentation
• Discworld MUD Room Description Line
• Discworld MUD Ten Commandments of Descriptions
• Discworld MUD Brief Mode
• Discworld MUD Map Command
• Writing Games: MUD Style Guide
• Writing Games: Building a Better MUD for Screen Readers
• BaseMUD (ROM 2.4b6) Source: act_info.c
• IRE GMCP Specification
• Achaea GMCP Spec (PDF)
• TinTin++ ANSI Color Reference
• MXP Specification
• Mudlet Manual: Supported Protocols
• Mudlet Manual: Mapper
• Procedural Realms Mudlet Script
• MUDPortal Web Client
• LociTerm PWA
• Iron Realms Nexus Client
• Cogmind: ASCII Maps in Morgue Files
• GMCP Protocol (TinTin++)
• Gammon.com.au: Adding MXP to a Server
• 16colo.rs MUD ANSI Art Archive
• MUDdescANSI Editor