← Creasebound prototype

Symposium Studios / Development record

Make the fold
mean something.

This is the retained development trail for a small atlas puzzle: its original promise, the revisions that made the transfer legible, accepted evidence, and the limits it does not hide.

The original promise

Folding is delivery, not decoration.

Creasebound began with a specific differentiator: folding lets a player copy a named property from one panel to another, and the unfolded destination keeps that change. The design deliberately rejects freeform paper physics, procedural levels, and a progression system.

The completed page contains four panels and two routes: Light from conservatory to beacon, Heat from furnace to gate. The player folds through a legal crease, confirms Transfer, and explicitly unfolds to inspect the persistent result.

Chronology

Seven moments where the page became a puzzle.

  1. 01–02

    Promise and system contract

    Narrowed the premise to folding as delivery for a named state: a destination keeps the transfer when the panels separate.

  2. 03

    Visual-direction revision

    Refined the slice into a dimensional cut-paper atlas and kept reference material separate from runtime proof.

  3. 04–05

    Bounded page and provenance

    Held the scope to four panels and two routes while recording 58 source/runtime asset entries with provenance and checksums.

  4. 06

    Graybox revisions

    Strengthened deterministic core behavior and normalized mouse and touch routing after two implementation revisions and three manager reviews.

  5. 07

    Designed-slice revision

    Accepted runtime art, audio, persistence, accessibility, and reduced-motion evidence after one presentation revision.

  6. 08

    Complete desktop playtest

    Recorded first-read, invalid-recovery, replay, pause/resume, revision fallback, reduced-motion, input-route, and timing evidence.

  7. 09–10

    Story check and final audit

    Checked the local product story for provenance and claims, then completed the Gate 5–9 validation audit.

Evidence, not atmosphere

What the final audit actually checked.

The acceptance record is desktop-only and specific. Nothing here substitutes for a device run, release review, or external player study.

Creasebound opening atlas page used in the first-read playtest journey.

First read

The authored sources, destinations, and legal crease were checked as a readable opening state.

Creasebound invalid-recovery runtime capture.

Recoverable failure

An invalid route remains understandable; undo, retry, and replay preserve the deterministic baseline.

Creasebound pause and settings capture used for accessibility evidence.

Settings and accessibility

Pause/resume and reduced-motion evidence were retained alongside the completion journey.

Observed validation

Useful checks, named honestly.

  • Godot 4 deterministic authored-state, fold/transfer, persistence, resume, and input-route checks.
  • Desktop portrait first-read, invalid-recovery, replay, pause/resume, reduced-motion, and revision-fallback journeys.
  • Warmed native timing record: 1.327 ms input to decision, 15.696 ms to next visual frame, and 120 frames averaging 9.997 ms.
  • 58-entry source/runtime provenance record, local product-story check, final Gate 5–9 review, and git diff --check.

Boundary and next decision

The proof stops at the desktop page.

This completed slice does not prove iOS/device behavior, Apple signing or packaging, App Store readiness, legal title clearance, public release, external-human playtesting, player response, sales, or operating metrics.

The next human-led decision is whether this evidence earns a separately authorized title-clearance and external-playtest track, or a bounded iOS/device-validation lane. Neither is implied by the current prototype.

Return to the product page