ASCII Wireframing Toolkit

Starter patterns for low-fidelity game wireframes. These are building blocks, not rules — a top-down RPG needs completely different conventions than a side-scroller. Use what fits, adapt what doesn't, invent what's missing.

When to Wireframe

When NOT to wireframe: Don't wireframe particle effects, animations, color palettes, or anything that's about polish rather than structure. "A satisfying effect plays" is enough during simulation.

Starter Toolkit

Box Drawing — UI Panels and Boundaries

┌──────────┐    ╔══════════╗    ┌──────┬──────┐
│  single  │    ║  double  ║    │ left │right │
│  border  │    ║  border  ║    │      │      │
└──────────┘    ╚══════════╝    └──────┴──────┘

Corners:  ┌ ┐ └ ┘ (single)    ╔ ╗ ╚ ╝ (double)
Lines:    ─ │ (single)        ═ ║ (double)
Joins:    ┬ ┴ ├ ┤ ┼           ╦ ╩ ╠ ╣ ╬

Use single borders for most panels. Reserve double borders for emphasis (active selection, important UI, primary window).

Common Primitives

These are starter suggestions. Your project's legend.yaml overrides everything here.

Shading and Fill

Dense:   ████████  (full block — solid walls, filled areas)
Medium:  ▓▓▓▓▓▓▓▓  (dark shade — semi-opaque, fog of war edge)
Light:   ░░░░░░░░  (light shade — transparent, fog of war)
Empty:   ........  (dots — open floor, traversable)

The legend.yaml Workflow

Every project develops its own symbol conventions. The legend.yaml file is the per-project source of truth.

How It Works

1. First wireframe: The agent proposes symbols based on the game's needs, drawing from the starter toolkit above or inventing new ones. Output the legend alongside the wireframe.
2. Legend grows organically: As new elements appear in simulation, add them to the legend. Each wireframe includes its legend so it's self-contained.
3. User overrides welcome: The user can change any symbol at any time. Their preference wins — update the legend and re-render if needed.
4. Legend format:

# legend.yaml — Project symbol conventions
# Source of truth for all wireframes in this project

player: "@"
wall: "#"
floor: "."
enemy_basic: "g"      # goblin
enemy_elite: "G"      # elite goblin
door_locked: "D"
door_open: "/"
chest: "C"
npc_friendly: "N"
# ... grows as the project evolves

Inline Legend Convention

Every wireframe should include a legend block so it reads independently:

┌─────────────────────────────┐
│ . . . . . # # # . . . . .  │
│ . @ . . . # C # . . X . .  │
│ . . . . . . D . . . . . .  │
│ . . . * . . . . . . g . .  │
└─────────────────────────────┘

Legend: @ Player  # Wall  . Floor  C Chest
        D Locked door  X Elite enemy  g Goblin  * Item

Genre-Specific Inspiration

These examples show how different genres use ASCII differently. Adapt, don't copy — your game has its own needs.

Side-Scroller / Platformer

                    *  *
          *     ════════
     @  ════
════════      ^^^^      ════════════
############  ####  ##  ############

Legend: @ Player  = Platform  # Ground
        ^ Spike   * Collectible

Conventions that work for platformers:

• Gravity matters — ground at bottom, platforms above
• Vertical space shows jump arcs and fall danger
• Hazards (^) below platforms show risk/reward

Top-Down / RPG

##########  ########
#........#  #......#
#..@.....+--+..C...#
#........#  #...g..#
#.*......#  #......#
###+######  ########
   |
   |    ~~~~
---+--- ~N~~
 .....  ~~~~
 ..*..
 .....

Legend: @ Player  # Wall  . Floor  + Door
        * Item  C Chest  g Goblin  N NPC
        ~ Water  - Path  | Path

Conventions that work for top-down:

• Rooms as bounded rectangles connected by doors
• Corridors as | and - between rooms
• Terrain types use visually distinct fills

Menu / HUD

╔═══════════════════════════════════╗
║  ADVENTURE GAME        ♥♥♥  $127 ║
╠═══════════════════════════════════╣
║                                   ║
║   (game area here)                ║
║                                   ║
╠═══════════════════════════════════╣
║ [Sword]  [Shield]  [Potion x3]   ║
╚═══════════════════════════════════╝

Legend: ♥ Health  $ Gold
        [ ] Inventory slot

Conventions that work for HUD:

• Double border (╔═╗) for outer frame
• Sections separated by horizontal rules (╠═╣)
• Brackets [ ] for interactive slots

Inventory / Grid

╔══════════════════════════╗
║  INVENTORY         6/20  ║
╠══════════════════════════╣
║ [Sword ✦] [Shield  ]    ║
║ [Potion  ] [Key  ✦ ]    ║
║ [Scroll  ] [Ring    ]    ║
║ [       ] [       ]     ║
╠══════════════════════════╣
║ ✦ = Equipped             ║
╚══════════════════════════╝

Conventions that work for inventory:

• Grid cells as [ ] blocks with content
• State markers (✦ equipped, ! new) inside cells
• Capacity shown as used/total

Flow Diagram

┌─────────┐     ┌─────────┐     ┌─────────┐
│  Title  │────→│  World  │────→│ Combat  │
│  Screen │     │   Map   │     │  Scene  │
└─────────┘     └────┬────┘     └────┬────┘
                     │               │
                     ↓               ↓
                ┌─────────┐     ┌─────────┐
                │  Shop   │     │ Game    │
                │         │     │ Over    │
                └─────────┘     └─────────┘

Arrows: ───→ player-initiated transition
        ---→ system-initiated transition

Guidelines

Sizing

• Screen layouts: 30-60 characters wide fits most contexts
• Room maps: Scale to fit — 10x10 is fine for a small room, 30x20 for a dungeon floor
• HUD mockups: Show relative proportions, not pixel-perfect sizing
• Don't over-detail: If a wireframe needs more than ~40 lines, split it into focused sections

Readability

• Leave whitespace between distinct regions
• Align elements to a visible grid when possible
• Use consistent indentation within bordered panels
• Label ambiguous elements — if a symbol could mean two things, add a legend entry

Iteration

• Wireframes are disposable — redraw freely as the design evolves
• Version wireframes by keeping both "before" and "after" when making significant layout changes
• Reference the legend.yaml so symbols stay consistent across wireframes in the same session

See Also

• simulation-guide — Turn structure that uses these wireframes during Wizard of Oz simulation (see simulation-guide → Turn Structure)
• scoping — Vertical slice planning for what to prototype (see scoping/vertical-slices.md → Vertical Slice Decomposition)
• scenario-walkthrough — 5-Beat Structure that wireframes illustrate (see scenario-walkthrough)
• design-frameworks — Game feel principles for what wireframes should convey (see design-frameworks)