Pulse Court

Pulse Court is a local arena game in which two players try to send a moving core into the opposing goal. It also asks a less visible engineering question: when a match is described as policy-controlled, what proves that the policy selected its actions? During the integration audit, the smoke runner could load a policy and then continue playing from a scripted action stream. A successful load and a completed match could both be true while the intended test had never happened.

The repair made execution explicit. Policy preview drives a native controller, records network decisions, and produces matches whose inputs and state hashes can be checked independently. The resulting evidence establishes that the network ran. The policy used for this check is synthetic and untrained. A later local simulator migration addresses the ruleset mismatch described below, while certification remains a separate unfinished step.

Replay is only useful if the same inputs mean the same game. A collision resolved in a different order, a cooldown tied to drawing frames, or an input interpreted under another ruleset can change the outcome while leaving a plausible-looking match on screen. I made simulation state, timing, resolution order, and replay versions explicit so those differences can be detected.

The game offers three original characters with different abilities, but the authoritative rules live below the viewer. Positions, velocities, cooldowns, and tuning use integer fixed-point arithmetic. The simulation advances at 120 Hz, with defined ordering for players, contacts, goals, and wall reflections. This makes the state transitions inspectable without claiming universal cross-platform equivalence from one Windows test environment.

The pulse_core library has no windowing or rendering dependency. The native viewer and headless runner consume the same simulation, while each owns the concerns of its interface. A state hash covers authoritative fields and match configuration. The replay verifier runs the recorded inputs through a fresh simulation and reports the first divergent tick, rather than merely checking the final score.

Optional events let strikes, abilities, bounces, and goals trigger animation or tracing without affecting the solver. The event buffer is excluded from state hashing. Rendering can then change without becoming another source of game rules, and headless replay checks can run without loading art or creating a graphics surface.

The native policy layer runs an FP32 multilayer perceptron. A controller refreshes its decision every 12 simulation ticks, with extra refreshes on initialization and phase changes. That is a 10 Hz decision cadence over the faster simulation clock. Observations, legal actions, inference, and controller state remain outside pulse_core, and the controller supplies actions through the same boundary as other inputs.

The original integration gap sat after loading: the runner could discard the loaded policy and keep using scripted actions. The repaired runner selects scripted or network mode explicitly and counts fresh network decisions. Regression tests separately step a policy controller, reproduce the bot inputs and state hashes, and check that the network action stream differs from the scripted stream. That links the loaded artifact to what actually happened in the match.

The September preview ran ruleset v2, while the strict policy contract required v4. Its compatibility shim lost touch-kind information. A network could execute successfully and still receive observations that did not match the reference game. Preview made that integration path inspectable, but could not make the rules equivalent.

The September 20 audit made the mismatch concrete. Both encoders return 64 numbers, but an identical core velocity becomes a different network input because the speed caps differ. A strike also changes the core’s motion differently. Body contact can produce matching motion while v2 loses who touched the core. Matching vector length and action mappings therefore cannot establish that a policy is playing the same game.

The subsequent local migration ports the v4 simulation and observation semantics together, removes the lossy shim, and preserves touch ownership and the touch recorded before a goal reset. All 34 synthetic fixtures, covering 78 snapshots, now match the identified v4 reference in observations, actions, masks, touch state and same-ruleset hashes. Native adapter tests also exercise generated, untrained policies. These checks close the measured compatibility gap without certifying a trained model.

Replay history needs its own boundary. A separate verifier retains the exact v2 core and still verifies the unchanged 5,720-tick preview replay. The active v4 loader keeps the hardened admission checks and rejects foreign-ruleset files. Neither rewriting an old replay header nor obtaining a v4 match would establish certification, so strict deployment stays disabled until accepted certification and policy-artifact identity are checked.

The September 21 repair follows simulator identity through the evaluator's lifetime. A DLL pathname alone leaves two questions open: which library did the wrapper actually use, and did that ownership last until native state was destroyed? The wrapper now uses the same loaded library whose receipt, source and configuration were checked, and retains a Windows handle that blocks file replacement. Both evaluator paths expose completed identity only after teardown. The report producer rejects missing or mismatched evidence.

Failure changes what the report may say. If native destruction raises an error, the wrapper cannot assume that the native state is gone. It retains the library and its protection until process exit, without retrying destruction or producing completed identity. The software tests exercise this failure path with a fake native dependency.

The evidence covers 62 software test methods and a separate native probe that called five identity and ABI getters. That probe never created an environment or ran a policy. The new checks concern the library used for a future evaluation. They do not identify the DLL that trained a historical checkpoint, and strict deployment remains disabled.

Six preview games with the synthetic, untrained policy exercised both bot seats and recorded 9,483 native network decisions. All six replays passed verification. Six explicitly scripted control games recorded zero network decisions. This comparison checks controller selection, not the relative playing strength of two agents.

The included replay is the smallest of the set, a 5,720-tick match that the synthetic policy lost. Its recorded inputs reproduce the saved hashes. Choosing it for portability rather than as a representative performance sample is part of the artifact description. The result closes the execution gap without claiming a trained champion, a human challenge, or competitive ability.

The same September checkpoint passed all four automated suites in both Release and Debug. The suites cover simulation and replay contracts, policy behavior, logging, and challenge paths. Launcher argument checks also passed for spaced and relative Windows paths. These are distinct checks on the path into a run and the evidence coming out of it, with no new inference-latency claim.

The viewer exposes pause, single-step simulation, hitbox and animation overlays, an action trace, and separate simulation-speed and render-cap controls. Its fixed simulation accumulator ties animation events to simulation ticks. Focus loss clears held input and pauses play. Those controls are intended to make a questionable action inspectable at the point it happened.

Art goes through a manifest-driven pipeline: poses are cleaned into a consistent grid, sheets are baked near their draw sizes, and the runtime supplies procedural fallback when an asset is missing. The images here are repository art. They show the assets used by the viewer, rather than proving that the latest native runtime passed visual acceptance.

Gallery and character setup use Direct2D, while gameplay still uses GDI/GDI+. Keeping the old gameplay renderer during the migration provides a reference for the remaining conversion. Resize behavior, visual parity, alpha edges, and device-loss recovery need their own checks. An isolated rendering spike therefore does not become a gameplay frame-rate claim.

The headless results answer a concrete chain of questions: a controller made network decisions, those decisions produced recorded inputs, and replaying those inputs reproduced the saved state. They do not establish that a human played a challenge or that the viewer handles every input and rendering condition. Headless smoke sessions and viewer challenge sessions still have separate implementations, so their protocols cannot be treated as interchangeable.

The current game is a local 1v1 prototype. Larger teams would change state layout, input frames, collision handling, observations, and tests together. Networking, gamepad support, and audio remain deferred. A new GUI and device-loss acceptance pass was not part of the September evidence, and the requested self-play and earlier-champion replay browser remains unimplemented.

The local v4 integration now supplies a simulator, observation adapter and replay contract that agree on the exercised fixtures. The next policy step is to bind an accepted trained artifact to its certification and golden-reference evidence, then check it in the actual deployment path. No trained policy was loaded for the migration checks, and the local branch is not merged or deployed. A candidate checkpoint or a successful file parse is still insufficient.

Rendering has its own path: convert gameplay, check visual and device-loss behavior, and then retire the legacy renderer. Keeping these follow-ups separate preserves the value of the current result. Policy execution is now observable through the match evidence, and the project can state exactly which part of deployment remains unproved.