Skip to content

Development plan

Current rune work builds on the shipping activation, drawing, command-orb, and runeable-object modules. Each extension should begin with a design matrix row and a risk-sized task.

Expand the rune matrix

Every noun carries its matrix row as rules. New or changed rows follow this order:

  1. approve the Verb + Noun state behavior in the rune matrix;
  2. add or edit the rule row on the noun's data asset;
  3. give the noun's puzzle the State Looks and Performances the row calls for;
  4. add a new puzzle behavior only when the existing ones cannot express it;
  5. author world and drawn forms;
  6. add automation and PIE coverage for success and rejection states.

Owner: Lead Designer + Systems Engineer.

Rune-responsive puzzle actors

ARunePuzzleActor is the base of every puzzle device. A new puzzle noun is a Blueprint child of it with its own State Looks and Performances.

Keep the seam consistent:

  • runeable component: noun, status, rule resolution, command events;
  • actor: State Looks, Performances, collision presentation, audio/VFX, cinematic timing;
  • CanReceiveCommand: actor-specific availability gate.

Owner: Puzzle Engineer.

See Making runes and Adding a puzzle device.

Drawing vocabulary

New drawable words need exact, unique StrokeIds on DA_RuneDrawingGraph. Before adding a pattern:

  • confirm visual legibility on the 21-stroke board;
  • check that no existing exact set matches;
  • test keyboard and gamepad navigation;
  • verify the first word parks cleanly while the second is drawn.

The shared graph is a binary asset and should have one owner per changelist.

Owner: Lead Designer + Blueprint Engineer.

Input and accessibility

Enhanced Input separates normal gameplay (IMC_Default) from open-tablet controls (IMC_RuneDrawing). Follow-up work includes:

  • key-rebind UI;
  • gamepad menu navigation;
  • accessibility review of candidate, pending, active-pattern, and rejection feedback;
  • audio redundancy for rune state changes.

Owner: Generalist Engineer + UI/UX.

Save and load

Checkpoint saves use URephrasedSaveGame with a schema version. A checkpoint records:

  • level, checkpoint, and player transform;
  • runeable status per receiver, keyed by a stable authored id;
  • the component transforms and swapped meshes a puzzle's performances leave behind;
  • runtime Data Layer state and learned-rune knowledge.

Follow-up work: a pending transaction policy at load time. Prefer checkpoint saves between puzzles rather than serializing a command orb or half-complete transaction.

Owner: Systems Engineer.

See Save / load.

Main, Pause, Settings, and Credits use UMG. Coordinate input-mode restore with the player's URuneCoordinatorComponent when a menu opens over gameplay or the drawing tablet.

Owner: Generalist Engineer.

Controller support

Windows gameplay input uses Game Input. Continue PIE coverage on Xbox-style and DualSense controllers when changing IMC_Default, IMC_RuneDrawing, or drawing action triggers.

Owner: Generalist Engineer.

Audio integration

Rune and puzzle sound is authored in Wwise and hooked to command and puzzle moments. Keep reusable audio in Content/Rephrased/Audio/ and coordinate middleware changes with the Audio Engineer.

Owner: Audio Engineer + Engineering Producer.

Change history

  • 2026-10-02 — Gabriel Li — Puzzle actors section describes ARunePuzzleActor as the base of every puzzle device; save section describes the checkpoint save in the build (CORE-011).
  • 2026-09-17 — Gabriel Li — Rebased the plan on the shipping rune transaction, drawing, runeable-object, status-effect, and split input-context architecture.
  • 2026-08-26 — Gabriel Li — Added org repo source-of-truth note after migration to Rephrased-Games/Rephrased-Game.
  • 2026-05-23 — Gabriel Li — Save/load partial status aligned to GDD; redefinition cross-link to RuneSystemCore.