Playtest

In plain words: Foundry: automated playtests

Designed 1 min read 1 glossary terms 5 connected pages
The short version written for the Snayu team

How Foundry runs a declared gameplay scenario against an exact build with a restricted controller and records structured engine observations as evidence.

Why read it: Read when building automated playtesting or balance suggestions.
  1. 1A scenario pins build, start state, inputs, assertions and time limits.
  2. 2Screenshots support but never replace structured observations.
  3. 3Evidence can show loading or regressions, never fun or release readiness.

Words on this page, decoded click one for its card

The original text Underlined words open their plain-English card.

The candidate loads. Now make the player perform the declared interaction and inspect what the engine reports. game.playtest_candidate@1 runs that bounded scenario against the exact build; screenshots support, but never replace, structured observations.

PlaytestSession@1 owns the bounded live process. A trusted/TombSandbox driver may implement it directly; an independently resident, queued, or remote harness may expose SessionGrant. World keeps finite EngineToolJob@1. The scenario's ControllerAdapter exposes only admitted inputs, without shell, editor, debug console, arbitrary RPC, anti-cheat bypass, public-server access, or deceptive player authority.

Pin the attempt

Define what the attempt will do and what would count as a result in GameplayScenario@1. It binds build/world epoch, initial state, spawn/reset, random streams, ordered steps, inputs, structured observations, tick/clock policy, time/action budgets, assertions, tolerances, and terminal outcomes.

A fresh session normally starts a new epoch. Reusing one requires proof of process, world, cursor, and clock continuity. The epoch and cursor keep late observations from being mistaken for evidence about a different attempt.

During the attempt, EngineObservationSet@1 retains exact tick/time, entity identities, transforms/velocities, collisions/triggers, navigation, controller/animation state, selected gameplay state, logs, performance, gaps, and assertions. Those observations also support recovery. If an input acknowledgement disappears, reconcile the same epoch, cursor, and resulting state before considering another input. Settle recovered, failed, cancelled, or indeterminate/contained. Do not repeat an unproved effect: repetition cannot establish what happened.

What the evidence can judge

Scenario author, controller, evaluator, and human player remain separate roles. Their evidence may establish loading, completed interaction, frame-time bounds, or regression. It cannot decide fun or release. game.balance_from_evidence@1 proposes a bounded successor through ordinary project/build/playtest gates without revising old evidence.

A Spectre Encounter is separately admitted participant, comfort, interruption, and exit work in a VR Habitat. It cannot substitute for candidate-build judgment.

Continue to Build when the scenario and checks support review.