observable-gameplay
Observable Gameplay — If the Console Is Closed, Can You Tell What’s Happening?
Section titled “Observable Gameplay — If the Console Is Closed, Can You Tell What’s Happening?”Always-loaded, engine-agnostic. The observational half of rules/game-feedback-mandate.md: that
rule specifies WHICH feedback each action class owes and gates on a filled Feedback Matrix; this one
is the check you run when no matrix was ever authored, and it needs no artifact to fail.
A gameplay slice is not done until its effects are visible on screen, not only in state. Before declaring one complete: watch the game with the console closed — can you tell what is happening? Entity counts dropping in a debugger, or a green test suite proving damage was applied, is not a game being played.
Three traps the Feedback Matrix does not catch, because each one has its cell filled and still reads as nothing happening:
- Every damage event shows the value actually applied after mitigation — never the raw pre-mitigation roll. Showing the roll instead of the result makes a working damage-reduction system look broken, and sends the next reader to debug a system that is fine.
- Any attack that conceptually travels gets a visible travelling representation. An instant hit standing in for a travel-time attack reads as nothing happening, however loud its impact cue.
- Significant state changes (death, level-up, pickup, phase change) are legible on screen, not only in component state or a log line.
Placeholder art is not an excuse: a primitive with a colour and a tween satisfies every point above.
Handing the slot to an artist later is rules/placeholder-first-handoff.md’s job, not a reason to
ship the slice invisible now.
A matrix gate is an artifact gate: it fires when someone fills the matrix wrong, and stays silent when nobody wrote one. The failure this rule catches is the second case — a slice driven to a green suite in which combat resolved as instant damage, no damage number, no projectile. Every system worked, entity counts moved correctly, assertions passed, and a person watching the screen could not tell the character was fighting. The loop was verified through assertions and entity queries, never through what a player would see, so “the core gameplay loop works” was true of the simulation and false of the game.
That is rules/green-that-proves-nothing.md (core) in its game-specific form: ask what this green
would look like if the thing it guards were broken. A suite that asserts state transitions goes red
for a broken simulation and stays green for an invisible one.
How to apply
Section titled “How to apply”Before calling a gameplay slice done: stop, close the console/log panel, watch the running game for the scenario the tests cover, and answer the test above. If the answer is no for any damage, travel, or state-change event, it is not done — add the visible representation, then re-check. A reviewer blocks on a failed console-closed test the same way they block on a missing REQUIRED matrix cell.
Related
Section titled “Related”rules/game-feedback-mandate.md— the spec this verifies: channels, action classes, timing budgets, the Feedback Matrix artifact, and the blocking gate. This rule does not restate them.rules/green-that-proves-nothing.md(core) — the parent failure class.rules/placeholder-first-handoff.md— handing the finished slot to an artist, once it is visible.- Your engine kit’s placeholder-visuals skill — HOW to make a slice visible cheaply (primitives, procedural sprites, playability checklists). Those skills scope themselves to art-free work; this criterion applies with or without final art, which is why it lives here as a rule.