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.
Creates ASCII wireframes and legends for game UI mockups, spatial maps, and flow diagrams during design sessions.
npx claudepluginhub smileynet/game-spiceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
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 |
| Menu / HUD | 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
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
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
These examples show how different genres use ASCII differently. Adapt, don't copy — your game has its own needs.
* *
* ════════
@ ════
════════ ^^^^ ════════════
############ #### ## ############
Legend: @ Player = Platform # Ground
^ Spike * Collectible
Conventions that work for platformers:
^) below platforms show risk/reward########## ########
#........# #......#
#..@.....+--+..C...#
#........# #...g..#
#.*......# #......#
###+###### ########
|
| ~~~~
---+--- ~N~~
..... ~~~~
..*..
.....
Legend: @ Player # Wall . Floor + Door
* Item C Chest g Goblin N NPC
~ Water - Path | Path
Conventions that work for top-down:
| and - between rooms╔═══════════════════════════════════╗
║ ADVENTURE GAME ♥♥♥ $127 ║
╠═══════════════════════════════════╣
║ ║
║ (game area here) ║
║ ║
╠═══════════════════════════════════╣
║ [Sword] [Shield] [Potion x3] ║
╚═══════════════════════════════════╝
Legend: ♥ Health $ Gold
[ ] Inventory slot
Conventions that work for HUD:
╔═╗) for outer frame╠═╣)[ ] for interactive slots╔══════════════════════════╗
║ INVENTORY 6/20 ║
╠══════════════════════════╣
║ [Sword ✦] [Shield ] ║
║ [Potion ] [Key ✦ ] ║
║ [Scroll ] [Ring ] ║
║ [ ] [ ] ║
╠══════════════════════════╣
║ ✦ = Equipped ║
╚══════════════════════════╝
Conventions that work for inventory:
[ ] blocks with content✦ equipped, ! new) inside cellsused/total┌─────────┐ ┌─────────┐ ┌─────────┐
│ Title │────→│ World │────→│ Combat │
│ Screen │ │ Map │ │ Scene │
└─────────┘ └────┬────┘ └────┬────┘
│ │
↓ ↓
┌─────────┐ ┌─────────┐
│ Shop │ │ Game │
│ │ │ Over │
└─────────┘ └─────────┘
Arrows: ───→ player-initiated transition
---→ system-initiated transition
(see simulation-guide → Turn Structure)(see scoping/vertical-slices.md → Vertical Slice Decomposition)(see scenario-walkthrough)(see design-frameworks)