A large broken save is evidence, not an explanation
When a save fails to load, a quest disappears, or a migration violates a game rule, the first artifact may be enormous: hundreds of fields, nested collections, a long action history, a content snapshot, and an environment that no longer exists. That artifact is valuable because it reproduces the problem. It is difficult because it gives a developer far more information than they can reason about at once. Reading it line by line often produces guesses rather than an explanation.
Delta debugging changes the objective. Instead of asking a person to spot the one relevant value, ask a deterministic predicate whether a candidate still demonstrates the failure. Then remove or simplify parts of the state while the predicate remains true. The final result is a minimal regression case: small enough to review, stable enough to replay, and explicit about the invariant that remains broken.
Minimal does not mean visually tiny or universally smallest. The useful goal is a materially reduced counterexample under a bounded cost. A reducer can stop when no whole group can be removed, when an execution budget is exhausted, or when the fixture is understandable enough to become a regression test. The preserved property matters more than an abstract optimum.
Establish reproducibility before reduction
Reduction only works when the failure is repeatable. First capture the precise predicate: does the current loader throw a classified error, does an invariant return false, does a resulting state differ semantically from the expected outcome, or does an action sequence produce an invalid grant? Avoid using a vague predicate such as “the game looks wrong.” The predicate must return the same answer for the same inputs, or the reducer will chase noise.
Record the environment alongside the candidate: application build or commit, migration version, adapter version, content and configuration snapshot, deterministic seed, platform assumptions, and starting fixture hash. If a live clock, random source, remote configuration fetch, or background worker can change the result, replace it with a deterministic test boundary or record it as an explicit limitation. The reducer must not secretly test a new environment on every attempt.
For action-sequence failures, preserve the initial state and the ordered actions separately. A final state may hide the operation that produced it. A sequence fixture can express “start from this profile, perform these seven requests, then the invariant fails.” That separation allows the reducer to shrink fields, collections, and actions without confusing one kind of evidence for another.
Reduce fields and collections in partitions
Start with coarse partitions. Divide the top-level save into field groups, remove one group from a working copy, and run the predicate. If the failure persists, keep the removal; if it disappears, restore the group and subdivide it. This is more efficient than deleting one field at a time from a large object. Continue into nested records and collections once a relevant region is identified.
Collections need special care. Inventory items, quest records, counters, and event history may refer to each other. Removing one entry can change list indexes, capacity rules, or aggregate balances. Normalize ordering where order is not meaningful, preserve stable identifiers where references require them, and state whether a missing item should be absent, null, or represented by an explicit legacy fallback. A reducer should not turn a real migration defect into a parser error caused by malformed test input.
Use value shrinking after structural reduction. Move integers toward zero or an important boundary, shorten strings, replace a long identifier with a safe test identifier, and reduce timestamps to a stable epoch only when their exact value is not the condition under test. Each simplification must keep the predicate true. This often reveals that an apparent complex profile bug is really “one retired item ID plus a full inventory” or “one negative counter after a skipped version.”
Reduce action sequences without changing their meaning
Some failures emerge only after time: a purchase retry after a reconnect, a save after a configuration update, or a migration after an interrupted tutorial. Apply the same partitioning idea to actions. Remove a contiguous half of the sequence, replay, and keep the removal if the invariant still fails. Then subdivide. Preserve required setup actions, but challenge incidental navigation, repeated reads, and unrelated mutations.
Actions should have stable parameters and result expectations. A reducer that replaces every request with a fresh random transaction ID is no longer testing the original retry semantics. A reducer that removes the initial feature-flag load may alter the configuration context. Record action identity, relevant inputs, trusted versus untrusted source, and the point at which the invariant is checked. This makes the final sequence useful to both developers and QA.
When a sequence depends on concurrency, choose a deterministic schedule. Record the order in which workers or simulated clients reach critical boundaries. If the failure only occurs under a race, a test may need a controlled barrier rather than timing-dependent sleep calls. The aim is not to pretend concurrency is simple; it is to make the observed interleaving reproducible enough to reason about.
Preserve the violated invariant in the final artifact
A small fixture without an assertion becomes another mysterious file. Store the violated invariant beside the fixture in clear terms: duplicate entitlement for one transaction identity, unknown catalogue reference after migration, negative currency, inaccessible completed quest, or semantic mismatch after a round trip. Include the expected classification and the observed one. The fixture should fail for a reason, not merely because a function returns false.
Compare before and after state semantically. A raw diff may contain rewritten timestamps, reordered arrays, generated IDs, or serialization formatting. A semantic diff highlights values that affect the invariant. It can report that an item changed from a valid legacy fallback to an unknown ID, or that a balance was incremented twice for the same ledger key. Keep the normalizer narrow and documented; a broad normalizer can erase the very defect the reducer is meant to preserve.
Write a replay manifest with the fixture path, source hash, reduced hash, environment fingerprint, deterministic seed, action sequence if any, predicate name, and expected result. This manifest lets another person rerun the case without access to the original oversized state. It also makes the fixture suitable for CI, where a minimized case should be fast and clear rather than dependent on a private local machine.
Know when reduction should stop
Every predicate run costs time. Some migrations are slow; some scenarios need service adapters; some failure conditions are flaky until an environment is fixed. Set budgets for attempts, wall time, and artifact count. Stop when the fixture is small enough to explain the issue, when no partition can be removed without losing the failure, or when the remaining work requires domain judgment rather than mechanical shrinking.
Reduction has limits. It cannot decide whether a legacy item should map to a replacement, whether a retired quest needs compensation, or whether a saved value is legal in a redesigned economy. Those are product decisions. It also cannot safely reduce encrypted or sensitive data by copying it into broad tooling. In those cases, create a synthetic equivalent that preserves the structural condition, or keep the restricted investigation within the appropriate access boundary.
Do not publish a raw player state as a regression fixture. Strip names, contact information, receipt data, device identifiers, access tokens, and any field not needed for the predicate. A minimal fixture is an opportunity to improve privacy as well as diagnosability. The final artifact should be safe to include in the project’s test corpus and useful enough to prevent recurrence.
Practical checklist
- Define a deterministic failure predicate before removing any state.
- Record the application, adapter, content, configuration, seed, and fixture environment.
- Keep initial state and action sequence separate when behavior unfolds over time.
- Reduce top-level groups first, then nested fields, collections, and values.
- Preserve references and structural validity while challenging semantic relevance.
- Use a controlled concurrency schedule instead of timing-dependent retries.
- Store the violated invariant, expected classification, semantic diff, and replay manifest with the result.
- Stop at a useful bounded counterexample; do not optimize indefinitely for theoretical minimality.
- Redact or synthesize sensitive data before a fixture enters routine tests.
Frequently asked questions
Is delta debugging only for crashes?
No. The predicate can be a crash, but it can also be a violated game invariant, a wrong entitlement count, a failed save-load round trip, a rejected migration classification, or a mismatch between expected and observed state. It is most useful whenever a complex input reliably produces an outcome that should not occur.
What if the failure is intermittent?
First reduce the nondeterminism. Fix seeds, capture configuration, isolate time and network boundaries, and control concurrency. If the outcome remains probabilistic, use a threshold-based predicate only with care and record that limitation. A stable smaller scenario is usually more valuable than a large flaky fixture.
Can a reducer run against production data?
Routine reduction should not. Use synthetic or redacted fixtures and a controlled environment. A restricted incident investigation may need protected evidence, but that is a separate operational process with access controls, retention rules, and review. Do not make the regression suite a copy of player data.
What does Persistium claim here?
Persistium is in development as a local-first reliability product family. This note presents a generally useful reduction workflow and does not claim that a public product automatically diagnoses arbitrary saves, has observed customer failures, or operates a hosted analysis service.
