# 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.

- **Read the launch QA report**:
  22 pages, 3.5 MiB. Screenshots, frame measurements, fixes, 16 test conclusions and a
  two-page ship-readiness assessment. Recorded 26 September 2026.


[Download the PDF](https://regiellis.github.io/godot-mcp-go/reports/dueling-dice-launch-qa-2026-09-26.pdf)


> **A dated test record**
>
> The report recommends **HOLD final sign-off** for the tested build. It records the
> evidence available on that date, including unfinished checks and unresolved findings.
> It is not a statement about the game's current release status.


## 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](https://regiellis.github.io/godot-mcp-go/docs/game-qa) 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:

```text
63a63d94553cc7915bee59957e4a13890f42d8b145ca0e17d6b77bd47e39e288
```