Skip to content

Technical Design Document

Engineering Lead: Gabriel Li
Platform: Windows PC / Steam
Engine: Unreal Engine 5.8
Current playable: Content/2ndPlayable/LV_2ndPlayable

Game summary

Rephrased is a 3D isometric exploration game about the rune language of a lost civilization. Sol wakes among its ruins and learns the language by using it. Each word he understands becomes a new way to read, change, and move through the world.

The game keeps that learning inside the world. Runes appear as carvings, objects, structures, shadows, natural forms, and player-drawn patterns. A command produces a visible environmental response, giving the player evidence for the next hypothesis.

Player promise: understanding becomes power.

Technical goals

The technology supports four priorities:

  1. Readable cause and effect. Selection, grammar, command travel, object response, and final state each have clear feedback.
  2. Contextual rune behavior. A Verb resolves against a Noun and the receiver's current status.
  3. Designer-owned content. Word data, noun rules, drawing patterns, State Looks, and Performances stay exposed through data assets and Blueprint-friendly classes.
  4. Reliable team iteration. Shared assets have clear ownership, gameplay code has automation coverage, and LV_2ndPlayable remains the integration target.

Platform and toolchain

  • Unreal Engine 5.8
  • Visual Studio 2026 Community, MSVC v14.50
  • Windows PC as the primary platform
  • Keyboard and mouse plus Xbox-style and DualSense gamepads through Enhanced Input
  • Perforce mainline workflow with numbered changelists
  • Rephrased MCP for onboarding, task setup, checks, review, submit, wiki lookup, and devlogs
  • Unreal MCP for editor inspection, compile support, Play In Editor, and viewport operations

The project uses a C++ gameplay module with Blueprint and data-asset content on top. C++ owns stable runtime rules. Blueprints own assembly, presentation, and content-specific tuning.

Core gameplay flow

  1. The player approaches a world rune and uses Interact, or opens Mind Drawing and completes an exact pattern.
  2. The rune coordinator accepts the word as a transaction token.
  3. The first word becomes pending.
  4. A matching second word completes one Verb + one Noun in either order.
  5. The noun provides the command origin and target identity.
  6. A command orb expands from that origin and reaches eligible receivers.
  7. Each receiver finds its noun's rule for the Verb and its exact current state.
  8. The rule updates gameplay state.
  9. The puzzle presents that state through its State Looks and plays the matching Performance: animation, light, sound, VFX, and camera.
  10. The transaction clears and the player reads the result.

This same flow supports world runes and drawn runes. The input source changes; grammar and command resolution stay shared.

Rune system

Word data

URuneDataAsset is the authored definition for a word. It carries the player-facing word, definition, EWordType, and word mesh.

For a Noun, the data asset also holds its row of the effects matrix:

  • Default Status: the state a placed object starts in;
  • Rules: one row per cell, from an exact state to an exact state, with Stops Motion for Freeze;
  • Temporary Rules: cells whose effect lasts a while, such as Rise.

For a Verb, Duration sets how long its temporary effects last.

The Current Rune Type matrix is the behavior authority for each Verb × Noun × Status row.

Rune base construction

Runes are built by highlighting and rotating parts of one shared base. Three part systems make up the base:

  • Big circle / body: the large rim, four limb-like strokes, and the triangle's closing bar rotate together around the main centre.
  • Small circle: the two outline halves and the inner straight stroke orbit together around the main centre, independent of the body.
  • Fixed frame: two squares, outward corner strokes, and eight directional sockets stay in place.

The two rotation controls are independent. Zero degrees is the upright standing reference. Sliders move smoothly and lock to 45 degree steps on release.

The large rim divides into eight socket-to-socket arcs. The small outline has two selectable halves. Each square edge splits at its midpoint socket. Corner strokes are selected manually; touching a socket does not switch them on.

A Verb requires all three of:

  • the entire small-circle outline highlighted;
  • the straight stroke inside the small circle highlighted;
  • matching big-circle and small-circle angles.

The rest of the figure suggests the action. The whole big circle does not have to be highlighted.

Nouns are pictographic and use the two orbits more freely. A Noun still needs a meaningful visual idea and must stay distinguishable from the verb signature.

The full stroke and orbit rules live in Rune language. The authoring workflow lives in Making runes.

Coordinator and transaction

URuneCoordinatorComponent lives on ARephraseCharacter. It owns:

  • world-rune candidate selection;
  • interaction routing;
  • one active FRuneTransaction;
  • drawn-rune acceptance;
  • grammar completion;
  • command spawning and completion;
  • drawing context and input-mode transitions;
  • player-facing delegates for selection, completion, rejection, and clearing.

FRuneTransaction stores up to one Verb token and one Noun token. Word order is flexible; the completed command is normalized into Verb and Noun roles.

Selecting the same token can cancel that token. Leaving a world rune's deactivation range clears its pending contribution. Grammar rejection returns readable feedback and leaves the system ready for the next attempt.

World runes

AWorldRune is the in-world activation actor. Its authored ranges separate three responsibilities:

  • interaction range for candidate selection;
  • command range for receiver delivery;
  • deactivation range for pending-token cleanup.

Candidate, pending, active, and rejected states use distinct material feedback. A world rune can act as either half of the two-word transaction.

Environmental runes are world runes placed as level objects. They carry a normal or broken state. A broken environmental rune is repaired before it can contribute a token, and the same verb/noun transaction resolves the repair. See Environmental runes.

Mind Drawing

Mind Drawing uses URuneDrawingDataAsset as the exact-pattern graph. Each rune maps to a unique set of StrokeId values.

WBP_RuneDrawing presents the board. The player navigates and toggles strokes through the rune drawing input context. An exact match activates automatically and contributes a normal transaction token. The first matched word parks beside the board while the player draws the second.

UDrawnRunePresentationComponent presents active drawn words over the character. Drawn commands use the player as their spatial origin when the drawn Noun supplies the command center.

The drawing board opens and closes with the tablet action. Character control is disabled while the board is open. The board opens with every stroke inactive. The selected stroke is white, active strokes are yellow, and when the active strokes form a valid rune the pattern activates automatically and its strokes turn blue. Breaking the pattern deactivates the rune and returns the remaining strokes to yellow. An activated rune stays active after the board closes. Closing the board restores character control.

Command delivery

AExpandingRingActor is the command orb. It visualizes the command radius and provides the delivery clock.

As the edge expands, it reports overlapping receiver actors once. Query collision is part of the receiver contract. The visual edge and overlap edge share the same timing so players can connect contact with response.

If command-orb presentation cannot start, the coordinator still completes delivery through the same overlap area. Gameplay resolution remains deterministic while presentation stays replaceable.

Runeable objects

URuneableObjectComponent turns an actor into a command receiver. It owns:

  • current Noun data;
  • the current state, as Status.* tags;
  • receiver eligibility;
  • rule resolution;
  • status updates;
  • status-change, rule, and rejection delegates.

The component checks:

  1. the command Noun matches the object's Noun;
  2. the receiver can accept a command now;
  3. the Noun has exactly one rule for this Verb and the exact current state;
  4. the puzzle can play it now.

Rules, looks, and performances

The rule decides the result: a permanent rule sets the new state, and a temporary rule keeps it while its performance plays. Every state has its own tag, and combined states are tag combinations such as Broken + Open.

ARunePuzzleActor is the base of every puzzle device. It presents each result through:

  • State Looks: one row per state, setting each part's mesh, materials, visibility, on/off, and transform;
  • Performances: what plays per result: Animate to Look, Play Cinematic with its Cinematic Sequence, and an optional behavior such as Move, Rotate, Rise, or Swap Mesh;
  • Part components: every part the looks and performances control, such as a lamp's bulb or the pieces of a repair, is a component of the puzzle's Blueprint.

Rules that reach the same result share a performance. One performance plays at a time, and Freeze can land in the middle of any action.

Player and input

ARephraseCharacter owns locomotion, camera components, interaction discovery, and the native rune coordinator.

The default gameplay context contains movement, interaction, and reset actions. The rune drawing context contains tablet toggle, board navigation, and stroke selection actions.

Opening the tablet adds the drawing context and switches to the authored game/UI input mode. Closing it removes that context and restores the configured mode. Mapping-context ownership stays in the coordinator so possession and UI transitions use one path.

Current controls in LV_2ndPlayable:

Action Keyboard Controller
Move WASD Left stick
Interact / activate world rune F mapped Interact action
Open / close Mind Drawing E mapped tablet action
Navigate drawing WASD / arrows left stick / D-pad
Toggle stroke Space / mouse input mapped drawing action
Reset mapped reset action mapped reset action

The data assets and mapping contexts remain the authority for physical bindings.

Camera

The camera supports exploration readability and puzzle presentation.

URuneCameraSubsystem coordinates active camera ownership. ACameraZoneActor gives level designers placeable framing volumes with priority and blend settings. Puzzle actors can request focused presentation for a repair or state-changing sequence, then return control to gameplay framing.

Camera choices serve three purposes:

  • direct attention toward a readable clue;
  • keep the command origin and receiver relationship visible;
  • reveal the environmental consequence after a state change.

Content organization

Shared content lives under Content/Rephrased/:

  • Gameplay/Runes/Nouns/ and Gameplay/Runes/Verbs/ — word data;
  • Gameplay/Runes/WorldRunes/ — world-rune Blueprints;
  • Gameplay/Runes/Drawing/ — drawing graph;
  • Gameplay/PuzzleDevices/ — puzzle devices;
  • Input/ — gameplay and drawing actions/contexts;
  • UI/ — Mind Drawing and gameplay widgets;
  • Art/Materials/ — rune feedback materials.

Content/2ndPlayable/LV_2ndPlayable is the shared playable and integration map. Personal experiments use Content/Developers/<Discipline>/<Name>/.

The full authoring workflow lives in Making runes.

Audio and VFX

Audio and VFX reinforce the command chain:

  • world-rune candidate and selection;
  • exact drawing match;
  • pending-word state;
  • grammar completion or rejection;
  • command-orb travel and contact;
  • receiver status change;
  • route or puzzle completion.

Rune and puzzle sound is authored in Wwise and hooked to these moments. AAudioManager owns level music and volume routing.

World-rune glow materials show candidate, pending, active, and rejected states. The command orb carries the spatial relationship between noun and receiver. Puzzle presentation lives in State Looks and Performances so Tech Art can iterate without changing the noun's rules.

Save and progression

The save system uses Unreal USaveGame with an explicit schema version. Checkpoints preserve:

  • current level and checkpoint identity;
  • player transform when the checkpoint needs it;
  • runeable-object status;
  • puzzle presentation state required to rebuild the scene;
  • learned drawing patterns and progression flags.

Each saved object uses a stable authored identifier. Loading restores gameplay state first and asks each receiver to rebuild presentation from that state.

Short puzzle spaces use checkpoint boundaries. This keeps save behavior understandable for players and maintainable for the team.

Accessibility

The game supports keyboard/mouse and gamepad through semantic Enhanced Input actions. The production path includes:

  • rebindable actions;
  • readable focus and selection states;
  • color, shape, brightness, motion, and sound redundancy for rune feedback;
  • reduced-flash options for rejection effects;
  • volume controls and subtitle/definition sizing where text appears;
  • gamepad navigation for menus and Mind Drawing.

Rune meaning remains inferable through more than one sensory cue.

Verification

Automated

Rephrased.Rune.PROT001 covers the rune transaction, drawing, receiver, state, presentation, save, and regression contracts. Rephrased.Rune.CORE009 covers noun rules, State Looks, performances, and saving. New matrix rows add focused tests at the rule seam.

Play In Editor

Every gameplay change receives a PIE pass in LV_2ndPlayable or the assigned room. The pass covers:

  • world Verb + world Noun in both orders;
  • drawn Verb + drawn Noun in both orders;
  • mixed world/drawn commands;
  • token cancellation and deactivation range;
  • exact-match and extra-stroke behavior;
  • receiver collision and command range;
  • valid, repeated, and rejected status transitions;
  • repeated input-context open/close;
  • keyboard and supported gamepad controls;
  • camera and presentation cleanup.

Build and review

C++ changes compile in Development Editor | Win64. Documentation changes pass python -m mkdocs build --strict. Changelists run project convention checks and team review before submit, with human PIE for gameplay behavior.

Technical plan

2nd Playable

  • Keep Repair/Open + Door/Light as the smallest complete teaching set.
  • Tune candidate, pending, command, rejection, and status feedback.
  • Keep the current character and split input contexts as the integration path.
  • Keep authoring docs aligned with real asset paths and Details-panel fields.
  • Add mirror receivers that reflect space, rune shapes, and light, so a rune can be completed through reflected geometry.
  • Add swamp terrain that blocks movement, ignores Open and Freeze, burns when ignited, and becomes dirty water that Water purifies.

First Playable

  • Build the opening learning sequence from encounter through contextual comparison and Mind Drawing.
  • Add approved Rune Matrix rows as noun rules, with State Looks and Performances on each puzzle.
  • Establish stable checkpoint identifiers and receiver-state save data.
  • Complete camera, audio, VFX, and controller passes for the vertical slice.

Production

  • Expand vocabulary in the order defined by the Game Macro.
  • Add validation for word fields, status tags, drawing-pattern uniqueness, rule rows, receiver collision, and stable save IDs.
  • Build rune-responsive puzzle devices as ARunePuzzleActor Blueprints.
  • Profile command delivery and presentation in dense rooms.
  • Lock designer-facing interfaces before Alpha.

Technical risks

Shared binary ownership

BP_RephraseCharacter1, mapping contexts, DA_RuneDrawingGraph, shared puzzle Blueprints, and maps require one active owner. Task setup assigns ownership before checkout.

Matrix growth

Each Verb × Noun × Status row creates design, rule, presentation, and test work. The team approves rows in the matrix, authors them as noun rules, and adds a puzzle behavior when a row needs motion the shared behaviors lack.

Pattern collisions

Exact drawing depends on unique stroke sets. Content validation checks duplicate patterns and missing StrokeId values.

Receiver reachability

Command delivery depends on query collision and authored range. Every puzzle checklist includes collision visualization and contact verification.

Presentation re-entry

A puzzle plays one performance at a time and rejects other commands, with feedback, until it settles; Freeze lands at any time and stops movement. Repeated-command tests cover each transition boundary.

Input mode ownership

Mind Drawing, menus, and possession changes share input state. The coordinator owns mapping-context add/remove and restores an explicit mode.

Save evolution

The schema version and stable receiver IDs make new status fields and puzzle presentation states migratable.

Content throughput

Noun rules, shared performance behaviors, and per-puzzle State Looks keep new rune rows on one runtime pipeline.

Planned content

Mirror receivers and swamp terrain are designed for the 2nd playable and are not yet in the build. Both introduce receivers whose behavior depends on geometry the level provides, so their command ranges and status sets need authoring review before implementation.

Source drift

Mind Drawing rules and area counts differ between the design sources. The shipping implementation accepts one drawn word into a two-word transaction with no three-creation limit, and the level documents describe carried physical runes. Reconcile the sources before the affected content is authored.

Open questions

  • Mind Drawing: the Game Macro Readme says each creation counts as one rune and after a maximum of 3 created runes the game checks for an effect, then the created runes are invalidated. The shipping implementation accepts one drawn word into a two-word transaction with no 3-creation limit.
  • Level counts: the GDD Top Line says 5 areas x 5 sub-areas x 3 puzzles. The Game Macro sheet says 5 chapters with 6-7 areas each and 3-5 puzzles per area.
  • Rune availability: level docs mark runes as "In Mind Palace", meaning a learned rune can be produced with Mind Drawing rather than found on the ground.
  • Carrying: level docs require carrying physical 3D runes, but no carry component is compiled in the current module.

Design and engineering sources

Wiki pages:

Design documents on Google Drive:

The full list, with the rest of the source documents and folders, is on Design sources (Google Drive).

Change history

  • 2026-10-02 — Gabriel Li — Performances list Animate to Look, Play Cinematic, and behaviors; puzzle parts are Blueprint components; checkpoints record receiver status (CORE-011).
  • 2026-09-29 — Gabriel Li — Rune sections describe noun rules, State Looks, and Performances; updated Runes folders and audio (CORE-009).
  • 2026-09-17 - Gabriel Li - Added the rune base construction rules, the Mind Drawing feedback contract, environmental rune repair, the mirror and swamp plan items, and links to the design source documents.