Starter patterns and conventions for ASCII wireframes in game design. Use when creating screen layouts, UI mockups, spatial maps, encounter arenas, menu structures, or flow diagrams during game design sessions. Provides a toolkit of box-drawing characters, common primitives, and genre-specific examples as inspiration — not rules. Each project builds its own legend.yaml as the source of truth.
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.
| Situation | What to Draw | Why |
|---|---|---|
| Screen layout | Full screen with regions marked | Establishes spatial hierarchy and information density |
| UI state change | Before/after of the same screen | Shows what changes on player input |
| Spatial layout | Room, level section, or world map | Tests navigation and sight lines |
| Encounter arena | Combat or puzzle space with entities placed | Validates spacing, threat placement, escape routes |
| Interface elements with content |
| Checks information load and access patterns |
| Flow diagram | Screens connected by arrows | Maps player journey through menus or game states |
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.
┌──────────┐ ╔══════════╗ ┌──────┬──────┐
│ 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).
These are starter suggestions. Your project's legend.yaml overrides everything here.
| Symbol | Common Use | Notes |
|---|---|---|
@ | Player character | Traditional roguelike convention |
# | Wall / solid block | Dense, reads as impassable |
. | Floor / empty space | Light, reads as walkable |
~ | Water / liquid | Wavy reads as fluid |
* | Item / collectible | Stands out against floor |
! | Important / alert | Reads as attention-grabbing |
? | Unknown / interactable | Invites investigation |
^ | Spike / hazard / upward | Pointy reads as dangerous |
> < | Door / passage / direction | Arrows for flow |
X | Enemy / danger | Bold, reads as threat |
$ | Currency / treasure | Universal money symbol |
+ | Health / positive | Medical cross association |
= | Bridge / platform | Horizontal and solid |
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)
Every project develops its own symbol conventions. The legend.yaml file is the per-project source of truth.
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.
Legend grows organically: As new elements appear in simulation, add them to the legend. Each wireframe includes its legend so it's self-contained.
User overrides welcome: The user can change any symbol at any time. Their preference wins — update the legend and re-render if needed.
Legend format:
# legend.yaml — Project symbol conventions
# Source of truth for all wireframes in this project