Splatterface Games · internal tooling

“Looks right” is not a verification result.

GameQA is a regression-verification harness for game builds. You capture a golden sample once — a known-good build driven by a fixed input stream — then replay that stream against every new build. GameQA compares the digital record field-for-field and reports the first divergence, not a resemblance score.

See it catch a defect ↓

The problem

Every build is a chance to regress — and most game-testing tooling answers a weaker question than the one you're asking. Screenshot diffing says two frames resemble each other within a tolerance. Record/replay tools prove inputs can be fed back, not that outputs stayed the same. A green suite exit code says nothing about where behavior drifted. And "close enough" is exactly where the bugs that matter hide.

A run isn't verified because it looked right. It's verified because every observed value in a declared domain matched the golden sample — and the harness can point at the exact tick, pixel, or sample where it first didn't.

The brief: regression QA an agent can drive end-to-end over JSON, and a human can inspect afterward — same run IDs, same evidence.

What it does differently

GameQA treats a game as a deterministic machine under observation, not a video feed.

How it works

How it compares

Tool classWhat it answersWhere GameQA differs
Screenshot diffing
(Percy, Chromatic)
Do rendered frames look alike within tolerance?Whether the machine did the same thing — exact pixels, palettes, state, events, audio; visual resemblance can't promote semantic coverage.
Record/replay & input playersCan the same inputs be fed back?Whether they were applied identically — acknowledgements, ordering, and timing are compared, not just replayed.
Bespoke per-project harnessesDoes this one build behave?A common job model across builds and targets via declared capabilities; nothing project-specific leaks into the contract.
CI test runnersDid the suite exit 0?Clock/field/tick semantics, first-divergence forensics, insufficient-evidence as an explicit verdict.

What it proved on real work

GameQA was exercised against a live project — a golden sample captured from a reference build, replayed against a reimplemented candidate. These are observed results, not marketing numbers:

None of these passes claim whole-game parity — partial coverage is reported as such. That honesty is the point.

Under the hood

What a report looks like

Condensed from a real first-divergence report — fixture mutation detected at the correct location.

Repository ↗
$ gameqa compare --golden 0f3a1c --candidate bc35cd9 --domain exact

verdict        divergent
stream         game.state
first_divergence
  event        40824
  field        timer_clock
  expected     0x0000000005e2f1a0
  actual       0x0000000005e2f1b8  (24 ticks early)
coverage       46867/46867 records inspected · 0 missing · 0 extra
provenance     golden manifest 9cf36ac2… · capture gameqa-host-capture@bc35cd9
replay         gameqa run --timeline t_88214 --build candidate-2026-09-11 --report first-divergence