Automated testing took releases from monthly to weekly
The problem
Every title had to be verified by a human playing it end to end. That does not scale, it never catches the case nobody thought to try, and it made testing — not building — the thing setting the release schedule. At one title a month that is merely painful; against a weekly deadline it is impossible.
The insight
If you cannot debug it, prove it before it ships
The instinct on a constrained target with no debugger and no test framework is to test by playing. It does not scale, and it never catches the case you did not think to try. So the emulator became the test harness: a script drives the running build frame by frame, patches the input read directly rather than faking a controller, and asserts against live memory. Level generators were rewritten so they cannot emit a level without first proving it solvable — an unshippable level stops being a bug you hope to catch and becomes a state the generator cannot reach. Once verification is automatic the constraint moves off correctness and onto design, which is the only reason the cadence is survivable at all.
What we built
- Headless harnesses that drive the running build frame by frame, patch the input read directly, and assert against live memory rather than screenshots
- Level generators that prove solvability before emitting a level, making an unshippable level unreachable rather than merely unlikely
- Physics and behaviour contracts expressed as executable test suites, run against the real runtime instead of a model of it
- Regression runs that replay full playthroughs after every change, catching the bug a human would only hit on a lucky run
- A reusable engine and asset toolchain, so a new title starts from a proven base instead of a blank file
- A repeatable release pipeline: build, package, store page, and trailer
Have something with a domain problem underneath it?
Describe it and you will get a straight answer about whether we can help and what it would take.
Start a conversation