Manual regression loops
The same gameplay path is replayed by hand after build after build.
CADE LABS · GAME SIMULATION HARNESS
Make gameplay bugs reproducible.
Cade Labs builds reproducible gameplay QA automation around your game: controlled runs, checkpoint/replay, structured failure evidence, bounded exploration and machine-readable transition maps where your runtime supports them.
£2,500 fixed pilotOne build + one runtimeImplementation-ledEvidence before claims
RUN / QA-017REPLAY MATCH
STARTINPUTCP-04FAIL
checkpointCP-04
comparisonselected state fields
resultMATCH × 3
STATE A
CP-04
action A → STATE Baction B → STATE C
THE QA PROBLEM
A bug you cannot replay is expensive to understand.
Gameplay regressions often sit above unit tests and below a clean bug report. The Harness is designed to preserve the path, state and comparison around a failure so the team can investigate the same event instead of trying to recreate it from memory.
Intermittent failures
A bug appears once, then disappears before the team can inspect the state that caused it.
Weak failure evidence
A screenshot or tester note shows the symptom without preserving the run that produced it.
Limited QA capacity
Important systemic behaviour competes with feature work for scarce manual testing time.
THE WORKFLOW CHANGE
Run → checkpoint → replay → compare → preserve.
The goal is not more automation for its own sake. It is a controlled gameplay loop that can show what happened, under which build and inputs, and whether the result repeated under the declared comparison rule.
- 01RUN
Start from a known build, configuration and initial state.
- 02CHECKPOINT
Capture a restorable branch point with provenance.
- 03REPLAY
Apply the same timed inputs from the same declared start.
- 04COMPARE
Use an explicit state, event, hash or bounded visual rule.
- 05PRESERVE
Keep matches, divergences, crashes and uncertainty as evidence.
BOUNDED CAPABILITIES
Engineering primitives, not an “AI tests any game” claim.
Capability support is discovered or declared per runtime. Unsupported operations are treated as unsupported rather than silently downgraded into weaker evidence.
Controlled runs + replay
Define the start state, inputs, timing and comparison rule so a valuable gameplay flow can be re-run under known conditions, with frame stepping where the runtime exposes it.
Checkpoint + branch
Save a meaningful branch point, restore it, verify the restore and continue with alternative actions where the runtime supports it.
Structured failure evidence
Preserve run identity, build/runtime context, input timeline, structured observations, comparisons and failure artifacts.
Bounded exploration
Explore from verified checkpoints under explicit budgets, keeping EQUIVALENT, DIFFERENT and UNCERTAIN states distinct.
Transition mapping
Store meaningful state → action → result transitions in a machine-readable form that can grow into useful maps.
Local worker isolation
Run independent local workers without sharing mutable game state unintentionally, then aggregate the evidence.
WHO IT IS FOR
Teams with a real gameplay QA problem and a runtime we can instrument.
The strongest fit is a technical team that can point to a valuable flow, intermittent failure or state-space problem and provide a bounded build/runtime for the proof.
Gameplay + QA engineers
Teams spending time reproducing stateful, timing-sensitive or intermittent gameplay failures by hand.
Indie + mid-size studios
Teams that need useful gameplay automation without first building a large internal simulation platform.
Systemic games
Roguelikes, simulations, strategy, sandbox and other games where branching state creates expensive regression space.
Engine + tooling teams
Teams that want gameplay-level evidence to complement unit, integration and CI checks rather than replace them.
DESIGN PARTNER PILOT
Prove one valuable QA slice for £2,500 fixed.
The first engagement is intentionally narrow. The objective is to prove that the Harness can create useful, reproducible evidence around a real gameplay problem without pretending the whole game is already automated.
DESIGN PARTNER PILOT£2,500fixed · larger integrations quoted after discovery
- 01
Technical fit
Confirm the build/runtime can expose the control, checkpoint and state signals needed for the target QA problem.
- 02
Connect one build
Add the smallest useful adapter, bridge or instrumentation path around one game build and one runtime.
- 03
Automate the valuable slice
Target approximately 3–5 high-value flows or one clearly defined hard-to-reproduce problem area.
- 04
Prove the loop
Exercise checkpoint/replay, comparison and structured evidence where technically supported.
- 05
Deliver the path forward
Return the evidence, findings, limits and a scoped recommendation for wider integration—or stop if the fit is weak.
INTEGRATION MODEL
Connect to the game you actually have.
The reusable core stays separate from runtime-specific control and game-specific knowledge. That keeps the pilot honest about which capabilities come from the Harness and which require integration with your build.
Harness core
Reusable run, checkpoint, comparison, evidence and exploration mechanics.
Runtime adapter
Translates generic Harness operations into the controls the engine, emulator or browser runtime actually supports.
Game-specific layer
Keeps controls, probes, state identity and assertions for your build outside the reusable core.
Evidence boundary
Direct structured state is preferred; visual or AI interpretation stays explicitly labelled when used.
Internal proving workNot customer case studies
CURRENT PROOF BOUNDARY
The system has been proved on controlled workloads before being sold as a broad product.
Current internal/proving work covers deterministic run and replay control, checkpoint save/restore verification, structured evidence, isolated local workers, bounded checkpoint exploration, state identity and transition mapping. Browser integration patterns have also been reused across Cade-controlled proving games.
Those workloads are engineering evidence for the Harness. They are not external client results, testimonials or proof of universal compatibility.
TECHNICAL BOUNDARIES
What Cade Labs will not promise.
No universal game compatibilityNo automatic understanding of every mechanicNo universal determinism claimNo production-scale distributed execution claimNo complete-game mapping promiseNo AI system deciding whether evidence is true
FAQ
Technical fit before bigger promises.
Does it work with every game?
No. Compatibility depends on the runtime, the control and state interfaces available, and the QA goal. The pilot starts with a bounded technical fit check.
Is this just AI playing the game?
No. Core execution, replay, checkpointing, state comparison and evidence capture do not depend on continuous AI calls. AI can assist later with prioritisation or interpretation, but it does not decide whether evidence is true.
Do we replace our existing test stack?
No. The Harness is intended to complement unit, integration and CI tests by exercising gameplay-level flows and preserving evidence around them.
What do you need from our team?
A bounded test build or runnable environment, the target QA problem, and enough access or instrumentation to control the game and observe the state required for the agreed proof.
What happens if the game is a poor fit?
The technical fit check should surface that early. The Design Partner Pilot is deliberately bounded so a weak fit does not get pushed into a larger implementation.
Is this a self-service SaaS product?
Not currently. The commercial model is implementation-led: Cade Labs configures the Harness around a real game, runtime and QA problem.
Bring the gameplay flow your team is tired of reproducing by hand.
We will start by checking whether the game/runtime is a sensible fit, then scope the smallest useful proof around it.
Discuss a £2,500 Design Partner PilotCade Labs responds within two working days.