# Layerline — Game Design Document v0.1

**Status:** provisional candidate; automatically approved for design, not selected  
**Platform target:** iOS and Android, portrait 2D  
**Input:** one-thumb pointer/touch  
**Evidence date:** 2026-08-08

## Evidence boundary

Public adoption in adjacent folding and line-routing games is `CONFIRMED`; see
`../01-market-scan/`. Demand for Layerline's coupled mechanic, retention, conversion, revenue,
keyword volume, and trend are `UNKNOWN`. All rules and targets below are `INFERRED` design choices
until pretotype or prototype evidence is recorded.

## Player promise

**Flip layered circuit panels. Every flip rewires the board.**

In a calm, fully inspectable puzzle, the player flips hinged circuit shutters to expose the right
layers and power every terminal at once. A flip always changes two things: which shutters are
available and which route carries power.

## Pillars

1. **One move, two consequences** — spatial access and live routing are inseparable.
2. **Honest state** — touch-down previews the exact move; no timer, hidden physics, or random loss.
3. **Readable calm** — short portrait boards, restrained motion, unlimited undo.
4. **Systemic depth** — difficulty comes from a solvable rule grammar, not spectacle or reskins.

## Audience and session

- Casual puzzle players who understand folding, path, or connection games.
- Expected session: one to five minutes; no session-length claim is validated.
- Normal play is offline-capable after install. Progress persists locally.

## Core loop

1. Read the source, terminals, visible traces, hinge tabs, and covered relationships.
2. Press an exposed hinge tab to preview its destination, coverage changes, and projected power.
3. Release on the same tab to flip; drag away to cancel.
4. Observe the recomputed visible network; undo or choose another legal shutter.
5. Power every required terminal simultaneously to complete the board.
6. Continue to the next board; replay is optional and never required for currency.

## Deterministic rules

### Board model

- A board contains one fixed backplane, one or more sources, required terminals, and 2-10 hinged
  shutters.
- Each shutter has two discrete states, `A` and `B`. Its state determines its occupied footprint,
  visible face trace, and directed cover relationships.
- Every shutter shows its current trace and a small edge glyph for its alternate face. Preview
  reveals the complete after-state, so the reverse face is never hidden information.
- Only top-visible traces conduct. A covered trace is inactive; fixed backplane traces always
  conduct.
- Ports connect only when their geometry and channel symbol match. Color reinforces a channel but
  is never the sole signal.

### Legal move

- A shutter is legal when its hinge tab is not covered and its authored sweep is unobstructed.
- A legal flip toggles its state. It may expose or cover other shutters according to the new cover
  graph.
- A flip never removes a piece, creates randomness, or changes any unrelated board data.
- Illegal input does not consume a move; the blocking shutter pulses once.

### Power and win

- After every preview or committed flip, a graph traversal recomputes power from every source over
  visible compatible traces.
- Diodes permit traversal only in their marked direction. Insulated bridges allow two channels to
  cross without joining. Splitters join one input to two outputs.
- The board completes when all required terminals are powered in the same state.
- There is no timer, life, energy, or fail state. Restart restores the authored initial bitset;
  undo restores the exact prior bitset.

## Content grammar

The launch target is 96 solver-verified boards in eight 12-board modules. This is a production
target, not evidence of content-market fit.

| Module | New rule | Design purpose |
|---|---|---|
| 1. First Light | two-face shutter, one source, one terminal | teach preview and commit |
| 2. Under/Over | changing cover graph | establish the second consequence |
| 3. Branch | splitters and two terminals | simultaneous route planning |
| 4. Direction | diodes | directional reasoning |
| 5. Crossing | insulated bridges | separate overlapping channels |
| 6. Relay | a powered relay exposes a marked hinge | couple route and access more tightly |
| 7. Dual Feed | two marked sources/channels | manage parallel networks without color reliance |
| 8. Synthesis | bounded combinations of prior rules | prove depth without new exceptions |

Each module teaches one rule in isolation, combines it with one prior rule, then ends with three
synthesis boards. A solver must prove reachability, reject zero-move boards, record shortest depth,
and reject duplicate state graphs. Manual curation remains required for readability and pacing.

## Difficulty and progression

- Difficulty inputs: shutter count, cover depth, legal branching factor, shortest solution length,
  misleading locally useful moves, terminals, and rule families.
- The chapter path is linear and unlocks by completion only. No stars, currencies, loot, daily
  streak gate, or decorative meta is required.
- The game may record best move count for diagnostics, but v0.1 does not grade or gate the player
  with it.
- Hint v0.1 reveals one legal move on a shortest path after confirmation. Hints are not sold in the
  prototype and do not create an artificial failure.

## Game states

`boot -> home -> chapter-map -> level-intro -> playing <-> paused -> completed -> next-level`

Playing substates are `idle`, `previewing`, `flipping`, and `flow-settling`. Input is locked only
during the short flip/settle animation. App backgrounding saves the exact board state.

## Economy and monetization boundary

Willingness to pay and unit economics are `UNKNOWN`. The prototype has no monetization. Candidate
constraints for later testing:

- no mid-level interstitials, paid undo, energy, or manufactured loss;
- any ad appears only between completed/abandoned sessions and must be frequency-capped;
- premium, one-time ad removal, or additional level packs remain hypotheses, not commitments.

## UX, accessibility, audio, and feedback

- Board occupies at least 70% of the safe portrait width; hinge targets are at least 44 x 44 CSS
  pixels in the web prototype.
- Channel identity uses line pattern and terminal shape in addition to color.
- Settings: sound, music, haptics, reduced motion, high contrast, and reset progress.
- Preview uses a ghost footprint and dashed prospective flow; commit uses a 220-320 ms flip and a
  short power chase. Reduced motion uses a crossfade under 100 ms.
- Audio uses soft mechanical ticks, a continuous low power tone, and a restrained completion chord.

## Analytics plan

Record event names and parameters without personal content: tutorial start/complete, preview,
cancel, legal flip, illegal tap, undo, restart, hint, level complete, attempts, active time, and
exit level. Phase 10 may compare uninstall, engagement, retention, and performance with store
benchmarks only after real data exists.

## Technical contract for prototype

- Pure deterministic state reducer: immutable board data + state bitset -> legal moves, cover graph,
  active electrical graph, and win state.
- Solver and runtime share the same transition and win functions.
- Portrait web prototype first; no Unity work before prototype greenlight.
- The web prototype contains a 50-board solver-verified campaign. Six authored mechanic templates
  anchor it; reflected and alternate-state boards exercise the same deterministic grammar from
  distinct starting states. This validates runtime breadth, not production pacing or content fit.
- First run teaches the goal, hold/release preview input, and layer consequence in a skippable,
  replayable FTUE. Tutorial completion is persisted only after a real legal shutter flip.
- Target 60 fps animation on representative mobile hardware; no network is required for play.
- Level JSON owns footprints, state faces, trace ports, cover edges, sources, terminals, and initial
  state. Presentation code cannot change game rules.

## Pretotype and prototype acceptance

Advance from pretotype only if:

- at least 70% of a minimum 20 target-lane testers describe both “flip/expose” and “connect/power”
  after one store frame;
- no more than 20% call it merely Paper Fold with wires or a standard pipe rotator;
- the first frame is understandable without more than one short caption.

Greenlight the playable prototype only if:

- at least 8 of 10 first-time sessions correctly predict both consequences after FTUE and within
  the first three boards;
- all 50 prototype boards are solver-verified and undo/restart are exact;
- no critical rule, save, input, or layout defect remains;
- three synthesis boards produce distinct solution graphs and remain readable on a small phone.

These are future decision thresholds, not observed results.

## Kill or revise conditions

- Kill if the core reads as a cosmetic fold/circuit clone or the no-repeat ledger matches.
- Kill if the solver cannot generate varied, readable state graphs.
- Revise if two-consequence prediction misses the tutorial threshold.
- Revise the visual language if projected flow or cover changes cannot be read together.

## Out of scope for v0.1

3D camera, physics, screw/bolt removal, trays, hidden rear information, botanical restoration,
characters, narrative scenes, competitive modes, live events, cloud sync, subscriptions, and Unity
production.