Game QA for Godot and Unity

Connect your GitHub repo. We build your game, play it with bots, and hunt for crashes, leaks, softlocks, balance holes and visual bugs. You get bug reports you can repeat.

This is early access. Request access.

Bugs it has found

Each step below caught real bugs in a real Godot 4 project that the other steps missed.

• Rounding errors in pathfinding.
• Barrels facing backwards.
• Stale UI nodes left on screen.
• Nodes that were never freed.
• A disk write on every kill.
• Maps that could not be won.

How it works

1. Sign in with GitHub and pick the repo.
2. We detect Godot or Unity.
3. Pick a depth: Quick (15 min), Standard (1 hour) or Deep (6 hours).
4. Watch a live log while it runs.
5. Read the report.

The phases

• Recon. We find the engine and its version, map the project, and turn your design doc into a checklist. A clean import is the first gate.
• Build and static checks. We import the project in Godot or compile it in Unity for each target. We also scan for things that hurt in long sessions: allocations every frame, disk writes on frequent events, lists that only grow, signals never disconnected, float equality checks, and difficulty formulas with no upper limit.
• Your existing tests. We run GUT, gdUnit or the Unity Test Framework. If you have none, we add a small test harness in a qa/ folder.
• Rules and edge cases. Tests for ties and same-frame conflicts, an in-game economy that never goes negative or charges twice, pause and resume, save and load (including corrupt and old saves), min and max values, cooldowns, speed-up modes that skip through walls, and the same seed giving the same result.
• Bot playthroughs. A "decent, not perfect" bot plays like a person would, using only human actions. It plays every level, difficulty and free or paid state, with at least four seeds, and reports win rates. It flags pay-to-win, levels that are too easy and difficulty spikes. A fuzz bot also plays each level for 10 minutes or more.
• Visual tour. Screenshots at phone, tablet and desktop shapes. A vision review looks for clipped or overlapping UI, unreadable text, wrong orientation, flickering surfaces and UI under notches.
• Memory and long runs. We check for leaks on exit, visit every screen and level 300 times or more, and run a long game at top speed for 30 to 120 minutes. Memory is sampled and graphed. We also check how often save files are written.
• Platform builds. An Android debug build on an emulator with logs, an exported iOS project, and a check of the package: size, permissions, and test ad and purchase ids.

The report

• A one-paragraph verdict and a scorecard.
• Findings sorted by severity: Blocker, Major, Minor and Note.
• Each finding has evidence, steps to repeat it, the root cause (file and line) and a patch.
• A balance appendix, and a list of what was not tested.
• Optional GitHub issues and a draft pull request.

No evidence means no finding. We only work on our own branch, compiler-dev/qa-<run-id>, never on your default branch. We read your code from a read-only clone, with no secrets and no network except package mirrors.

Re-runs on every push

Turn on re-runs and each push to your repo starts a new run. The report shows what changed since the last run: what is fixed, what is new and what is still open.

Depths

Pricing

Early access. Prepaid credits only. There is no free run and no free credit.

Request access