What is a minimal reproduction case for a game bug?

A minimal reproduction case is the smallest set of steps that triggers the bug. Instead of describing an entire play session, a minimal repro isolates the specific conditions needed. For example, instead of 'play through levels 1-5 and the boss breaks,' a minimal repro might be 'load the boss fight save file, equip the fire sword, use the special attack.' Fewer steps means faster debugging.

How do you report bugs that happen randomly in games?

For intermittent bugs, include the frequency (e.g., 'happens about 1 in 5 attempts'), the exact conditions you were testing under, and any pattern you noticed. If the game uses a random seed, include it. If you can trigger the bug more often under specific conditions like low frame rate, high entity count, or specific hardware, note those. Attach any log files from sessions where the bug occurred.

How to Write Reproducible Bug Reports for Games

Quick answer: A reproducible bug report provides enough information for a developer to trigger the same bug on their own machine. This requires a known starting state, numbered steps that describe exactly what to do, the expected outcome, and the actual outcome.

This reproducible bug reports guide for games covers everything you need to know. The most valuable bug report is one that a developer can reproduce on the first try. When reproduction succeeds immediately, debugging begins immediately. When it does not, the developer enters a time-consuming loop of guessing, testing, and asking for more information. This guide covers the specific techniques that make game bug reports reproducible: establishing starting states, building minimal repro cases, recording game state, working with seed values, and using input replay systems.

Start from a Known State

Every reproducible bug report begins with a state that the developer can reach without ambiguity. This is the single most common failure point in bug reports: the reporter assumes the developer knows what state the game was in when the bug occurred, but the developer has no way to know.

A known starting state is one that can be reached in a deterministic, documented way. Good starting states include: the main menu after a fresh game launch, a specific save file attached to the report, the beginning of a named level, or a specific checkpoint. Bad starting states include: “I was playing for about an hour,” “somewhere in the middle of the forest level,” or “after doing a bunch of quests.”

If the bug requires a specific game state that takes time to reach — a particular inventory configuration, a quest flag that is set after completing a storyline, or a specific character build — attach a save file. A save file is the most reliable way to communicate game state because it is exact. No amount of written description can match the precision of the actual data file that the game will load.

// Good: starts from a state the developer can immediately reach
//
// Steps to reproduce:
// 1. Load the attached save file "bug_repro_boss_fight.sav"
// 2. Enter the boss arena through the north door
// 3. Use the ice spell on the boss during its charge attack
// 4. Boss freezes in mid-air and never lands
//
// Bad: starting state is ambiguous
//
// Steps to reproduce:
// 1. Play until you reach the boss
// 2. Use ice spell
// 3. Boss gets stuck

Build a Minimal Reproduction Case

A minimal repro case is the shortest possible sequence of steps that triggers the bug. Testers often report bugs with all the context of their play session, including steps that are irrelevant to the issue. A ten-step reproduction that could be reduced to three steps wastes the developer’s time on the seven unnecessary steps and obscures the actual trigger.

To build a minimal repro, work backward from the bug. Start by asking: “What was the last thing I did before the bug appeared?” Then: “Can I trigger the bug without the step before that?” Keep removing steps until the bug no longer occurs, then add the last removed step back. The result is the minimal set of conditions needed.

For example, if a bug occurs after the player picks up an item, equips it, enters a new zone, talks to an NPC, and opens their inventory, test whether the bug still occurs if you skip the NPC conversation. If it does, remove that step. Can you trigger it without entering the new zone? If yes, remove that step too. Eventually you discover that the bug occurs whenever the player equips the item and opens their inventory, regardless of zone or NPC state. That two-step repro is far more useful than the original five-step sequence.

Recording Game State

Games are stateful systems. The same inputs can produce different results depending on the current game state: what items the player has, what enemies are alive, what quests are active, what random events have occurred. This is what makes game bugs harder to reproduce than web application bugs, where the state is largely captured by the URL and a few cookies.

The most effective way to capture game state is to attach a save file to the report. If your game supports quicksave, instruct testers to quicksave immediately before attempting to reproduce a bug. The save file captures everything: player position, inventory, quest flags, world state, NPC positions, and all the other variables that might be relevant.

If save files are not practical — for example, in a multiplayer game or a game without save functionality — log the essential state variables at the time of the report. At minimum, log the player’s position and current level, active game mode, time elapsed since the session started, and any recently triggered events. This gives the developer enough context to approximate the game state even without an exact save file.

Working with Seed Values

Many games use procedural generation, randomized loot, or randomized enemy behavior. When a bug occurs in a randomized system, the specific random values that were generated can be essential for reproduction. If the game uses a seeded random number generator, the seed value is the key to recreating the exact same sequence of random events.

# Display the current seed for the player to include in reports

var current_seed: int

func _ready() -> void:
    current_seed = Time.get_unix_time_from_system()
    seed(current_seed)
    print("Game seed: ", current_seed)

func get_seed_for_report() -> int:
    # Include this in the bug report metadata
    return current_seed

When a tester includes the seed value in their bug report, the developer can initialize the game with the same seed and get the same procedural generation, the same loot drops, and the same enemy behavior. This transforms a seemingly random bug into a deterministic one.

If your game does not currently expose seed values, consider adding a debug overlay or a field in the bug report form that displays the current seed. For procedurally generated levels, also log the generation parameters (difficulty setting, biome type, player level at generation time) so the developer can recreate the same level without needing the exact seed.

Input Replay for Complex Scenarios

Some bugs are triggered by a specific sequence of inputs that is difficult to describe in text. Fighting game combos, precise movement sequences, or rapid menu navigation can all trigger edge cases that are nearly impossible to reproduce from written steps alone. Input replay systems solve this problem by recording every input event with its timestamp and allowing exact playback.

An input replay recording captures every key press, mouse movement, and controller input at the frame level. When a developer loads the recording, the game plays back the exact same inputs and ideally produces the exact same result. This is the gold standard for bug reproduction because it eliminates all human variability from the process.

Building a full input replay system is a significant engineering investment, but even a simplified version that records just the key inputs (button presses and their frame numbers, without analog stick positions) can be useful for many types of bugs. Some engines and frameworks provide replay recording as a built-in feature; check your engine’s documentation before building one from scratch.

“We added a ten-second input replay buffer that saves automatically with every bug report. The number of cannot-reproduce closures dropped by 60 percent in the first month. Turns out, most of our hard-to-reproduce bugs were just hard to describe.”

Handling Intermittent Bugs

Not every bug can be reproduced on demand. Intermittent bugs — those that occur sometimes but not always under the same conditions — require a different reporting approach. Instead of providing exact steps, focus on providing probability and conditions.

Report the frequency: “This occurs approximately 1 in 5 attempts.” Report the conditions you tested under: “I tested in the cave area with 10+ enemies spawned, at 30 FPS on a GTX 1060.” Report any patterns you noticed: “It seems to happen more often when there are many particle effects active.” And report the total attempts: “I tried 20 times and saw the bug 4 times.”

This information helps the developer estimate how much testing time they need to allocate for reproduction and gives them clues about the underlying cause. A bug that correlates with high entity counts suggests a race condition or memory issue. A bug that correlates with low frame rate suggests a timing-dependent code path.

Related Issues

For the mechanics of writing clear reproduction steps, see how to write good bug reports for game development. If you are dealing with bugs you cannot reproduce at all, our guide on remote debugging game issues you cannot reproduce covers techniques for investigating from logs and telemetry. For playtester-focused guidance, read bug reporting etiquette for game playtesters.

Before submitting a bug report, try to reproduce the bug yourself one more time following only the steps you wrote down. If you cannot reproduce it from your own instructions, the developer will not be able to either.