QA Testing for Soft-Lock and Dead-End Detection

A soft-lock is the cruelest bug because the game does not crash, does not error, and gives the player no signal that anything is wrong, it simply becomes impossible to win. The player wanders, retries, reloads, and slowly realizes they sold the key item, used the only bomb on the wrong wall, or saved in a room they can no longer leave. Unlike a crash, nothing flags it for you, and the player may sink hours before giving up. This post covers how to think about soft-locks, where dead ends hide in resources and progression, and how to test for and defend against unwinnable states.

Understand how soft-locks differ from crashes

Crashes announce themselves: the game stops, often with a log or a stack trace, and your reporting pipeline catches it. Soft-locks are silent. The game continues running perfectly while the player's situation has quietly become hopeless. This makes them uniquely hard to detect, because no automated alarm fires and the player may not even realize they are stuck for a long time, assuming instead that they have missed something obvious. By the time they conclude the game is broken, they have wasted significant time and trust, and they often blame themselves before they blame you.

Because nothing flags a soft-lock automatically, you have to go looking for them deliberately, reasoning about your own systems rather than waiting for an error. The mental model is to ask, for every progression gate, what does the player need to pass it, and is there any sequence of legal actions that destroys or bypasses that need without satisfying it. A soft-lock is almost always a missing guard: a resource that can be consumed before it is required, a door that assumes a key the player could have skipped, a save allowed in a state the player cannot escape.

Map required resources and gates

The backbone of soft-lock testing is a map of your progression gates and what each one requires. List every locked door, scripted barrier, mandatory item, required ability, and consumable that the critical path depends on. For each, identify what the player must possess or have done to pass it. This map is your search space: a soft-lock lives wherever a required resource can be lost, consumed, sold, missed, or skipped before the gate that needs it, leaving the player past the point of acquiring it again with no way forward.

Pay particular attention to one-time and consumable resources on the critical path, because they are the richest source of soft-locks. A key item that can be sold to a merchant, a single explosive needed to open a mandatory wall but usable elsewhere, a limited currency required for a story purchase, an NPC who only appears once. For each, ask what happens if the player uses it wrongly or wastes it. The safest design keeps critical-path resources non-consumable, non-sellable, or replenishable, but where that is not the case, every such resource needs a test that deliberately misuses it.

Test the destructive and out-of-order paths

Soft-lock testing means playing adversarially, doing the things a normal completion run never does. Sell or drop items you are about to need. Use consumables in the wrong place. Approach areas out of the intended order if the game allows it. Trigger events in unexpected sequences, leave a scripted scene early, or kill an NPC you were meant to talk to. The goal is to find the action sequence that strands you. Open-world and non-linear games multiply these paths enormously, so focus first on the critical path and the resources it cannot do without.

Saving is its own minefield. Test saving in every place a player can reach, especially right after committing a resource and in confined or dangerous spots, then reload and confirm the state is still winnable. A save made in a sealed room with no exit, or after using the last resource needed to leave, is a classic unwinnable save, and a single autosave at the wrong moment can trap a player permanently. If you allow manual saves anywhere, the burden is on you to prove no reachable state is a dead end, which is exactly what this testing establishes.

Build recovery so nobody is truly trapped

You will not find every soft-lock by testing, so design safety nets that make stuck states recoverable. Multiple rolling autosave slots let a player roll back from a bad save instead of losing everything. A way to leave any area, a reset-to-checkpoint option, or an unstuck command that returns the player to safe ground turns a permanent trap into a minor annoyance. Critical-path resources that regenerate or can be reacquired remove whole categories of soft-lock. These nets cost little and convert your worst, most rage-inducing bugs into recoverable hiccups.

Recovery features need testing too, because a broken safety net gives false confidence. Confirm autosaves actually rotate and are not all written at the same doomed moment, that the unstuck command places the player somewhere genuinely safe and winnable, and that a checkpoint reset restores enough state to continue. Test these from the exact stuck states you discovered while playing adversarially. A reset-to-checkpoint that drops the player right back into the unwinnable configuration is no recovery at all, and players will report it as the game being broken twice over.

Setting it up with Bugnet

The defining problem with soft-locks is that nothing tells you they happened, so you depend on players to report them, and the report is usually a vague stuck and cannot progress. Bugnet's in-game report button lets the player flag it the moment they give up, and it captures game state automatically, their location, inventory, quest flags, and progression markers if you surface them. That snapshot is exactly what you need to reconstruct the dead end: you can see they no longer hold the key item and stand at the door that needs it, turning a mystery into a clear reproduction.

Because a soft-lock from a specific design flaw traps every player who takes that path identically, the reports cluster. Bugnet folds duplicate occurrences into one issue with a count, so a single missable item shows up as one urgent item with a real measure of how many players it stranded. Add a custom field for the area or quest id and you can filter the dashboard to find clusters of stuck reports pointing at one gate, then verify your fix or recovery option resolves it. Captured progression state is the difference between guessing and knowing where players get trapped.

Make dead-end hunting a discipline

Soft-locks reward systematic paranoia. Keep your progression-gate and critical-resource map current as content changes, and whenever a designer adds a gate or makes a resource consumable, ask immediately whether it creates a new trap. Add debug tools that let testers grant or remove items and jump to gates instantly, so checking a suspect gate does not require a full playthrough. Run an adversarial pass, deliberately misusing resources and saving in odd places, at every milestone where progression content changed, because that is when new dead ends appear.

The cultural shift that prevents soft-locks is designing for recovery from the start rather than assuming players will behave. Prefer non-consumable critical-path items, autosave generously across rotating slots, and give players a way out of any space. Pair that with adversarial testing and a reporting pipeline that captures progression state, and the silent killer becomes a manageable, detectable class of bug. Players forgive almost anything except being trapped for hours with no way forward, so eliminating dead ends protects the trust that keeps them playing to the end.

Soft-locks never announce themselves. Map your gates, play adversarially against your own resources, and give every player a recovery path out of any state.