maze-tui — maze build/solve visualizer (box-drawing wall-style catalog)
Batch 8 — rendering / screensaver / ambient-display cluster.
What it is
Section titled “What it is”maze-tui is a terminal app that builds mazes and solves them, animating both phases as procedural visualizations on the cell grid. It exposes a wide algorithm roster on both sides and renders the maze with selectable Unicode box-drawing wall styles, under full playback control (pause, step, speed, zoom). The grid is encoded compactly — each cell is a u32 with bitwise wall/path flags — and solvers can run multi-threaded for “more fun and interesting visualizations.”
It is the cluster’s reference for two things the deck wants: a catalog of box-drawing wall aesthetics and a playback-control model for algorithm animation (the same controls a scene-design / attract pipeline wants).
KN-86 relevance
Section titled “KN-86 relevance”1. The wall-style catalog (the headline takeaway). The -w flag selects how walls render, and the roster is a ready-made reference for KN-86’s box-drawing vocabulary (Canonical Hardware Specification: Press Start 2P + CP437 box drawing):
| Style | Look |
|---|---|
mini | Half-size walls and paths (sub-cell density) |
sharp | Default straight single lines ─│┌┐└┘├┤┬┴┼ |
round | Rounded corners ╭╮╰╯ |
doubles | Sharp double lines ═║╔╗╚╝ |
bold | Thicker straight lines ━┃┏┓┗┛ |
contrast | Full-block width/height walls █ |
half | Half wall height, full-size paths |
spikes | Connected lines with spikes |
That maps almost one-to-one onto CP437 / Unicode box-drawing weights the deck already has in its font. The lesson for KN-86: box-drawing line weight is a deliberate aesthetic axis, not an afterthought — single vs. double vs. bold vs. rounded carry different tones (technical / formal / heavy / soft), all in one color. A KN-86 UI-pattern catalog should name and standardize these the way maze-tui does, so frames, panels, and dividers across carts read consistently. (round corners ╭╮╰╯ already appear in astroterm’s smooth-line renderer — same family.)
2. Algorithm-animation with step/speed control. Build and solve are animated: you watch the maze carve and the solver flood. Playback controls — SPACE pause/play, </> slower/faster, ←/→ step frame-by-frame (and reverse direction), CTRL +/- zoom, ESC cancel — are exactly the control surface a KN-86 attract-mode / scene-design tool wants, and a strong model for any cart that visualizes a process (a generation step, a decryption, a search). The deck has no mouse, but these are all keyboard controls already, so they port directly to the deck’s input model.
3. Distance-map coloring → single-color adaptation. The distance solver colors cells by path-distance from the center, producing a heat-map. On the monochrome deck that becomes a brightness/density ramp: distance maps to amber intensity or to glyph density (the same lever neo and astroterm use), so a flood-fill or distance field still reads as a gradient without color. The build/solve algorithm rosters themselves (rdfs, kruskal, prim, eller, wilson / wilson-walls, fractal, hunt-kill, grid, arena; DFS/BFS/flood-fill solve variants) are a useful menu of procedural-generation references for any KN-86 cart that builds spaces — mission maps, node graphs, dungeon-like layouts.
Single-color adaptation
Section titled “Single-color adaptation”maze-tui is RGB-color by default (distance heat-maps), but the structure — walls, paths, the maze itself — is entirely shape, no color needed. Drop color and the maze is fully legible from box-drawing alone; that is the point. For KN-86:
- Walls render in one amber on black, styled by line weight (the
-wcatalog above), not hue. - Distance / flood-fill animations use the amber-intensity ramp or glyph-density ramp instead of a color heat-map — the canonical single-color substitution this whole cluster keeps landing on.
miniandhalfstyles are sub-cell techniques (half-size walls), aligning with ADR-0027’s half-block 128×150 pseudo-pixel canvas — another way to get finer maze detail out of the 128×75 grid without color.
Relation to the (reveal …) visual language and ambient mode
Section titled “Relation to the (reveal …) visual language and ambient mode”A maze building itself cell-by-cell is mechanically a (reveal …)-adjacent animation — structure appearing over time. A slow maze build/solve loop is also a plausible ambient-mode scene alongside neo’s rain and astroterm’s starfield: low-stakes, procedurally endless, visually evolving. The step/speed control model is the natural control surface for the KN-86 scene-design / attract pipeline when authoring those ambient scenes.
- Source detail was partially verified directly from the repo (the task brief flagged its source as partial): wall-style names, algorithm rosters, and playback keys are confirmed from the project README; the
u32-per-cell bitwise encoding and multi-threaded solver design are the stated architecture. - Rust + ratatui/crossterm — not a code-lift target. The deck runtime is C11 (CLAUDE.md). The value here is the wall-style taxonomy and the animation-control model, both reimplemented in nOSh; no Rust crosses over.
- Cross-link astroterm — shares the smooth box-drawing / rounded-corner line family and the core/render split for spatial rendering.
- Cross-link neo — both are procedural ambient-scene candidates; both substitute a brightness/density ramp for color.
- Cross-link ascii-effects.md — the box-drawing wall-weight catalog belongs alongside the spec’s density/ramp vocabulary as the structural (line-weight) counterpart to the tonal (density) ramp.
- Cross-link reveal-styles.md — cell-by-cell maze construction is a
(reveal …)-family appearance animation.