Why do modern games take so long to reset the current level after failing?

Question

While recently playing a game I kept failing at, I realized that I don't fully understand why I need to wait for the level to reset at all. Taking time to load a new level makes sense to me - assets need to be loaded, maybe some computation needs to be performed. But if the game was already mostly in the state I wanted it to be in, the level is likely already in the memory, what does the machine spend its time on? At first I thought it's because it's more convenient to just load everything from scratch as opposed to implementing better reset routines, but it doesn't make sense because pretty much every game does it this way. Which brings me to the question: why do modern games take so long to reset the current level after failing?

Answer 1

As I mentioned in a comment above, we can't really say much specific about "all modern games" as a group, since each game is made in potentially very different and idiosyncratic ways, and the details of each one are usually known only to the folks who worked on that specific title.

So the best general answer, as unsatisfying as it is, is probably what you already said in your question:

it's more convenient to just load everything from scratch as opposed to implementing better reset routines

This isn't to say "devs are lazy", but a combination of two things:

• Implementing a minimal state reset, while potentially possible in many game frameworks, can be much more complex in practice than it may seem conceptually, potentially adding many person-weeks of development investment and bug-fixing.

• Time spent on such a feature is time not spent on other areas of the game, like polishing core gameplay. So at some point, teams need to prioritize: what will give more bang for our buck in terms of making the game more enjoyable? Shaving 2 seconds off the load screen, or adding a new player ability or cool boss battle or maybe even a whole new chapter of gameplay?

I know it may seem unreasonable that such a feature could be so expensive that the trade-offs could be so steep, but the complexity can creep in sneakily, similar to what I describe in the latter half of this answer about implementing checkpoint saving.

A system that resets the state of all game entities and systems in the level can end up needing knowledge of every one of those entities and systems so it can reach into them and wind them back — or all those entities and systems need to be set up in a way that's aware of the reset system, so they can handle resetting themselves. That adds friction whenever you want to add or change content and rules in the game.

If a game entity was destroyed, we need to know to re-create it, and we also need to know which other entities had been referencing that entity, so we can re-wire their references to point to the newly instantiated successor. That's non-trivial to do automatically, and usually needs special mark-up or manual scripts to support.

And if any of that goes wrong — say a junior programmer adds a new variable on an enemy class and forgets to correctly set it up to be rewound, or a level designer sets up a puzzle script and makes an error hooking up the reset event — now you have a subtle bug that only shows up if the player dies and restarts the level in a very specific place. This massively multiplies the surface area for potential bugs and the number of testing permutations you need to go through after any change to be sure you've covered every contingency.

That's all cost. Development time spent that doesn't necessarily make the gameplay any more fun, or the graphics any more beautiful, or the story any more compelling. Only the small subset of players who die in exactly that spot get to see any benefit at all from those extra hours. 😥

Now much like my earlier save answer, one could reasonably object that it's possible to sensibly plan and build a well-desined level loading and state management system in a way that makes this kind of state reset "easy", but I'll let you in on a dirty secret of game development:

A lot of our tech is neither sensibly planned nor well designed for the tasks we're putting it to. 😅

It's not that folks making games are lazy or unskilled, it's just that games are a moving target — so the requirements by the time we ship can be wildly different than the requirements we knew at the start — and we're often subject to outside pressures that are antagonistic to software engineering best practices.

I've worked on sequels that, by fiat of upper management, were forced to be built on the same underlying engine as the previous 5 games in the franchise, a mountain of technical debt that had been accreting for over a decade. A level reloading system that was plenty fast two console generations ago when our asset budgets were a fraction of what they are today might now be straining under HD textures and high res meshes that weren't even an imaginable possibility when it was first designed. But now years of critical code all depend on it, and ripping it all out and replacing it might be a months-long task with unknown ripple effects on everything else in the engine — too risky for most game development timelines.

So sometimes you have to make tough prioritization calls, and say "we estimate players are only going to die and reset once every ~20 minutes on average, so instead of spending time saving 2 seconds every 20 minutes, we're going to spend that same effort making the 20 minutes of play in between more awesome, so it's worth 2 extra seconds to wait for"

That's not the right call for every game. In some games resets are much more common, and that can shift the priority scales toward favouring fast reload and spending the time and money to make that happen, even if it means sacrifices elsewhere. Limbo is one such game built around repeated, instructive failure, and I recall the devs giving a GDC talk specifically mentioning the need to optimize reload times in the game for that reason.

So I hope that gives some context about why it's not always as simple as "just reset the state" and why sometimes games have to focus on other priorities.