Dueling Dice QA case study
Follow a real Godot release test from a frame spike through a fix, a packaged retest and a ship-readiness report.
See how a release test turns a frame spike into a measured fix and a clear list of work remaining. This case study follows Dueling Dice, a Godot dice battler, through source playtesting, profiling, a Windows re-export and a manual package retest.
22 pages, 3.5 MiB. Screenshots, frame measurements, fixes, 16 test conclusions and a two-page ship-readiness assessment. Recorded 26 September 2026.
What the test found
Repeated visits to the setup screen caused long frames. A controlled source profile identified synchronous roster-texture loading as the largest measured setup cost. Keeping those textures alive across screen changes reduced warm setup peaks from 109-138 ms to about 24-25 ms on the test machine.
That improvement had a cost: 62.875 MiB of retained texture memory. The report keeps the tradeoff visible and calls for a check on minimum-spec hardware.
| Test | Recorded result | What it establishes |
|---|---|---|
| Gameplay regression gate | 840 checks passed on the export engine | The tested assertions and complete process log were clean. |
| Reusable source scenario | 46 checks passed | Normal boot, repeated navigation, representative turns and pause/resume passed in the instrumented source run. |
| Visible package retest | Five menu cycles and match turns, with no issues reported | The operator completed the declared manual sequence in the actual Windows build. |
| Package frame capture | 7,175 presents; p99 21.85 ms; peak 126.03 ms | Two intervals exceeded 100 ms. No per-action markers established their cause. |
These measurements cover one high-end Windows machine. Source frame intervals and package presentation intervals come from different runs and are reported separately.
What the conclusion adds
A passing checklist does not answer every release question. Each test conclusion records what passed, whether its fix was verified, what remains and the evidence needed to finish.
The ship-readiness section identifies outstanding package matches, save/reload checks, hardware coverage and a longer soak. It also separates the resolved source-menu hitch from the remaining startup spikes and headless shutdown finding. The report explains what would change its recommendation from HOLD to READY.
One attempted manual capture did not produce a visible window for the operator. Its record stays incomplete. A separate retest started after the operator confirmed a visible, interactive window. This distinction keeps a running process from being mistaken for a completed playtest.
Apply the workflow to your game
Use a game-owned GDScript scenario for actions and assertions, retain logs and raw frame samples, and record manual results against named checks. Compare compatible runs and keep the final package’s identity with the report.
The Game QA and reports guide describes the scenario API, capture workflow and report format. This case study uses the QA feature preview, which is not included in the published Swallowtail 1.0.1 binaries. The report is available to download now.
Download details
The PDF retains technical context, build hashes and relative evidence paths. Raw logs, saves, machine-local paths from the companion scenario report, and the game executable are not included in this download.
Report SHA-256:
63a63d94553cc7915bee59957e4a13890f42d8b145ca0e17d6b77bd47e39e288