The situation you describe isn’t actually soft locking. What you’re describing is the player getting, to use the highly technical term, stuck. That said, there are a lot of possible situations where the player achieves a state where they cannot play the game. While the overall result might look similar, the causes are usually very different and thus require different sorts of solutions.
#1: Freeze or Hard Lock
This occurs when all visible activity for the game stops - no more screen updates, input doesn’t work, nothing at all. Hard locks usually occur when the game has crashed and can’t clean up the rest of the program. Instead, it just sits there in system memory, forever unchanged until you reset the device or externally terminate it. The solution to this is to find the code that was executing while it crashed and either fix the code itself so it doesn’t crash, or fix the circumstances that caused the code to crash (e.g. invalid asset data).
#2: Soft Lock
A soft lock occurs when the game is unresponsive and unplayable, but the screen continues to update. Animations still play, sound still plays, UI still updates, timers may still tick down, but the game will not respond to any player input. This is usually caused by individual systems in the game turning player control/input off in order to make sure that they don’t do weird stuff during transitions (e.g. after entering a new zone but before the zone is fully loaded and ready, or not letting players move their characters in the background while opening up a UI menu) and then missing a case to turn it back on again. The solution to soft locks like this is usually to figure out what was locking player input and finding the corresponding case where control should be returned to the player.
#3: Stuck
Sometimes, when navigating the game environments, players will get stuck on things. This means that they’ll be trapped in the level somewhere and be unable to move. Maybe that’s because the world geometry has put them into a perpetually-falling state so they don’t have any control, or because they’ve somehow clipped into a part of the level that should not be accessible. Large 3D environments are especially known for this problem occurring quite often. This also applies to players falling out of the world or getting stuck outside of the world (e.g. behind walls) where they might be able to move, but cannot play the game. We have a couple of ways to solve this problem. Obviously, the first fix is to have level design fix the offending level geometry so that the player can’t get stuck there anymore. However, this can become problematic in games with really large environments, because testing every square inch of every environment in an open-world game like Horizon Zero Dawn or Breath of the Wild is a monstrous task for QA. Often we have a secondary solution for getting stuck in games like this - we try to store the last known “good” position for the player and then teleport the player to that position if they get stuck. If that doesn’t work (e.g. the last known good position isn’t so good), we can teleport the player to their respawn location as if they had died.
#4: Broken
Often in games the player is required to accomplish certain tasks or acquire certain items to progress. If those tasks are not marked as complete or those items are not obtainable, the player is barred from progressing. In this case, we call it a broken state - the game can be played but cannot be completed. Something necessary for the player to continue in the game is somehow unobtainable. The solution to this is usually to figure out what the player is missing from the criteria and track down what was supposed to grant the missing element to the player. It’s usually something small, like a bad set of conditions, an improper quest trigger, or just a misspelling of a particular quest variable name.
Each of these kinds of problems will usually cause our game to fail certification (though some small amount of broken content is generally acceptable if they are small enough and aren’t on the game’s critical path) if discovered, so they are all pretty high priority fixes when we find them. Each type of fail state generally falls to different disciplines on the team - freezes and soft locks are usually handled by programmers while stuck or broken bugs are often handled by designers due to their common causes.
The FANTa Project is currently on hiatus while I am crunching at work too busy.
[What is the FANTa project?] [Git the FANTa Project]
Got a burning question you want answered?
- Short questions: Ask a Game Dev on Twitter
- Long questions: Ask a Game Dev on Tumblr
- Frequent Questions: The FAQ