# Why do games seemingly reload the entire level when restarting a level?

Is the data really modified that much during play?

I'm assuming the longish pause between restarting a level is the entire level reloading. But it seems to me that a well implemented system should just be able to 'ping' back to the start of the level.

It's more noticeable on consoles, but its not unnoticeable on PC games.

• The answer to that depends very much on the game, on the developers, their habits and experience and many more factors. The only correct answer on a general level would be: sometimes it is modified much, sometimes not, sometimes stuff is streamed in and thus the beginning is not in memory any more, and sometimes games already do "ping" back to the level start, and games that don't sometimes have good reasons why they can't do it and sometimes it's just because it's not implemented well enough. – Christian Jul 18 '13 at 10:26
• Generally speaking, it's just a lot easier reload the level (which puts everything at its initial state) rather than undo everything the player did. That's the case in my experience anyway. – Benjamin Danger Johnson Jul 18 '13 at 22:14
• The question isn't black&white. How much state is reloaded? Plenty of games reload entire texture sets for no good reason. Sure, going from level 5 to level 6 may mean loading new textures, but that doesn't mean you should do that every time you (re)start level 6. – MSalters Jul 18 '13 at 23:53
• @MSalters It'll mostly be about game state rather than resources, you may not need to reload a common usage texure, but more the enemy that you already killed - the object for it needs to be destroyed and reloaded in it's starting state (even if his texture is still nicely stored in memory.) – Tom 'Blue' Piddock Jul 19 '13 at 9:49
• I think somebody's been playing Wing Commander III on a legacy system. – Erik Reppen Jul 19 '13 at 22:46

## 6 Answers

Well now - what a simple but interesting question to tackle.

When reloading a level there are so many factors that need to be taken into account that the answer can go many ways.

If your level state contains a large list of assets it can be more practical to start from a clean slate when reloading a level back to a save/mission state as this maintains the accurate state of the level upon reloading but doesn't take a lot of processing. However it is more efficient to reset the assets alone if there are only a few to take into account - making sure you can restart the action quickly on these smaller levels. The latter is especially so when you don't need to preserve anything in the scene or it isn't affected by your choices in game - if you didn't need dead bodies to be preserved from your first run through a village they would not need to be reloaded on your way back through that level, thus conserving processor time and save/mission state access time.

A good example to think of would be a First Person Shooter that used terrain destruction / bullet decals that had a persistant state during that playthrough but wouldn't stay if you restarted that checkpoint or level.

If you were to rewind the level instead of destroy and reload it you would have to trace each and every state changed. If you shot a hole in the wall with a rocket you would generate terrain gibs from the pieces falling off the wall, the model of the wall would change to produce the hole and you would have particle effects that had been generated to make it look pretty. To clean this up by rewinding it back to a "restartable" state you would have to:

• Remove any dynamically generated gibs for that wall (but not remove ones from the state you loaded)
• Remove the particle effect for the dust from the bullet hole
• Replace / repair the wall to get rid of the holes you created
• Reset the player ammo
• Etc...

With so many resources to trace for rewinding a level it is often less processor intensive to simply destroy the entire level and reload all the assets again in their default or mission specific states. Having to reset specific objects involves searching a list of the objects in the scene and then accessing their properties to reset them. Instead of that bullet hole in the wall being repaired by cleaning up, you don't need to caluclate any clean up actions, just delete the whole level from memory and reload it from scratch.

This means reloading a level is dones from one state object (a save game file or a mission script) and not needing dynamic caluclations. For consoles this is exacerbated by the loading times involved with discs. It also helps PC games as it can take into account computers that won't have the procesing power to make the loading times acceptable.

So for large content levels - Loading a single state instead of calculating and "rewinding" one:

• Is less processor intensive
• Is more efficient on lower tier machines
• Enables a mission script and save file to be used in the same manner (potentially use the same loading system to load a save state or a mission checkpoint state when restarting the level)
• Means you have less work as a developer to reset a level - It is far easier to program a full reload from session data than track and rewind. This is probably the most influencial point

However, as a counter example a fighting game (great real life example being Street Fighter 4) may not need to reload all that many assets in order to restart a level. The 2 players, environment state for the level and simple level timers are mostly static and not dynamic (the players health will always respawn at 100% each round, timers reset to 90 seconds and the level has no bullet holes [or does it!]) and so resetting the level is a matter of putting the fighters to full health and putting the environment back to its original positions (like onlookers in some of the levels.)

So for a fighting game when doing a rematch (not going from round to round) you need to:

• Reset Health and energy to Max or defaults (always the same per character)
• Reset Timer
• Reset Character starting positions
• Reset Terrain to default state (no bullet holes to fix or reload!)

And that's the entire list essentially - meaning that a quick state reset instead of a full level reload is more feasible. This can also be shown by the loading time when you initially start the match. It takes a long time to load all the character and level models but only a few processor ticks to reset the character starting positions between matches with an already loaded model.

It's important to note that this is also a more in demand requirement of fighting games as their players tend to want to get back in the action incredibly quickly as matches can typically only last a minute - emphasising that this answer is very much dependant on the game and genre. FPS's demand more dynamic assets while Fighters demand quick repeatable action.

I hope this has shed some light on your question.

• Great answer... the cynical side of me, would put your: "less work for devs' point higher up the list...but perhaps its the engine's implementation that could be better. – Mesh Jul 18 '13 at 12:45
• Also, what about bug recovery? An NPC not moving because of a bug in the physical system, a memory leak etc. Even if the game is thoroughly tested, such things still happen and there must be a way to reset the game into a known and working state. – Sulthan Jul 18 '13 at 17:17
• Less work is an enviable goal to achieve, not a subject of shame. You could spend a week to build a rewind system and a month getting all the bugs out, or reload and get onto other features =) – Patrick Hughes Jul 18 '13 at 17:45
• I think cost is the most important argument here. Unless reloading a level happens a lot and becomes a major annoyance to the user there is no incentive to write optimized code to make a reload faster. It just costs less to reuse the code for a normal load. – orlp Jul 19 '13 at 5:44
• +1 I just want to clarify that reloading a level and loading a level - if the reload throws everything out and starts with a fresh load - requires no new code to be written to accomplish the game play goal. A rewind system is a completely new set of code which is non-trivial, and because it is dependent on a variable state it is extremely difficult to debug. Example: "Bug Fix: Restarting a level after dropping a helmet on top of a bomb after a missile explodes within 200 pixels of water no longer causes a crash to desktop." In short, you'd have to have a REALLY good reason to bother. – BrianH Jul 19 '13 at 17:16

To clarify the existing answers against your question about consoles: they don't have enough memory to store both the starting state and current state for larger complex games.

A game could store the level and initial state separately so that just the state could be restreamed in, and this is very likely what many games do. Even streaming just that is going to be quite a bit slower than if it had been kept in memory, though.

The "best" current-gen console has only 512MB of memory shared between CPU data and graphics. That is tiny. One of the current headaches of console development is trying to fit in games that meet today's quality levels with such small amounts of memory. Kilobyte counting can become important, especially close to the ship date. Storing a copy of the initial state of a level is some amount of data that could be done without, allowing more memory to be used for things that make the game more interesting during play rather than simply making level reloading faster.

Ideally, the player spends more time playing the game than dying and restarting, so optimizing for a better experience during play makes more sense.

Things might change drastically with the next-gen consoles and their 8GB of memory. Or they might stay the same, with simply higher-resolution models and materials and great numbers of active in-game objects. Time will tell. Given that PC games typically target machines with 2GB of RAM and 512MB of VRAM (though many scale to much larger values), the 8GB of the new consoles is pretty luxurious as far as minimum baselines go. We'll likely see a transition to games demanding a 64-bit CPU/OS and 4-8GB of RAM with 1-2GB of VRAM in the years coming up soon. Storing multiple states in memory for fast snapshotting should be a lot easier then.

• +1 Fantastic information and a great explanation as to why consoles are markedly slower at reloading. – Tom 'Blue' Piddock Jul 19 '13 at 8:01

I disagree with much of Blue's answer, I do not believe there is a technical case for not resetting levels - I certainly never encountered one. Level loading is almost always slower than level resetting, in fact I find it difficult to conceive of an occasion when it wouldn't be. In most cases games could offer effectively instant level loading if the devs chose to.

The real answer is, as suggested, it's easier and quicker. Repeated loading of levels is something that a game requires anyway so repurposing this into a level restart is relatively straight forward. Resetting requires complex new pathways with a great deal of potential for new bugs and memory leaks and it requires a decent investment of developer time. In a some cases it may also push memory limits. Since games are rarely developed with a surfeit of developer time, items such as level resetting have a regrettable tendency to get dropped along the way, particularly if the game architecture isn't the best built in the first place.

While I suppose one could come up with a situation where "rewinding" was necessary for resetting, in fact most games need only store the original state, provide an effective means to reset completely to that state for retained objects and a means to flag objects to abandon on reset. Game state information also needs to be stored and restorable. This kind of information is typically relatively light on memory compared to the requirements for an entire level so doing this removes the need for slow, expensive loading of data from disk (including large items like textures and models) and substitutes it for a rapid, in-memory pass of the scene.

• You might want to check out Sean's answer for an example of a technical case where you might want to reload a level over "resetting" it – SpartanDonut Jul 18 '13 at 20:59

To allow for large levels or seamless level game play, even with limited memory (memory is always too small, the question is if you hit the limit in RAM first, or on the graphics card) there is another strategy:

Only have the part of the level in memory, that the player needs currently or will need in a few seconds. Models, textures, sound samples, ... that are probably not needed anymore are removed from memory.

Dungeon Siege comes to mind (developers once claimed, that memory management took more processing power than the actual game play), most MMORPGS do it, Shooters with an open environment have to do it, ... In these cases, the start of the level (or even a respawn point 30 seconds ago) might not be (completely) in memory anymore.

Often a fresh reload is the easiest way, the cheapest way, and perhaps the fastest way.

Edit: Here is a paper about the loading mechanisms of Dungeon Siege: The Continuous World of Dungeon Siege

• Good point, I didn't think about continuous or seamless levels. That would need a completely different level loading system. – Tom 'Blue' Piddock Jul 19 '13 at 8:08

With Sean and Blue's excellent answers regarding physical platform limitations and pro-con decisions, I'm going to expand a comment into a different approach:

## Why You Should Probably Just Completely Reload The Level

So you've got your loadLevel() call working perfectly, yay! You stream in a level file information, and step through building the world based on it, creating objects and loading textures and sounds as you go. Then, when it's all done - or done "enough" to let the play start, you call startPlay() and your world is revealed and your music begins to play.

Now when you are done with the level, or escape to the menu, or exit the game, you call unloadLevel() to free up all the resources and memory you've been holding onto to allow a smooth experience.

Now, what happens when you want to add a "Restart Level" feature? Well...

unloadLevel(currentLevel);
loadLevel(currentLevel);
startPlay();


And you are done! No new code, just a few simple function calls at most, and you've already written and debugged all that so now your new shiny Restart Feature is crossed off your list, and probably never to be encountered again - cruftless, non-rusting code is the best kind! Move the code into a restartCurrentLevel() function and you can fold that code away and never look at it again - maybe after making sure there is a level to restart, of course :)

But then you wonder if this isn't a waste, unloading things you are just about to reload again anyway. Well, if your levels and resources are small then the most you have to gain is a few spare seconds of load time each time "Restart" is called even on slow systems (and maybe older smartphones), so who cares? "Premature optimization", you've got better things to do with your time.

Ah, but now your levels are growing and your textures are becoming more detailed and the soundtrack got ripped in 512kbps with separate channels for every voice and musical layer (it seemed like a good idea at the time, though you can't remember why...) and something about "state-origin dependent voxel ray tracing multidimensional Fourier transform matrices" which you think is just totally made up and not a real thing, and level loading actually takes a while now and its beginning to annoy you. You've even tested with real people and they actually show a distaste for the waiting times as its worse than similar games (you aren't expecting an MMORPG capital city with 100 players to fully load in <2 seconds, are you?), and it's a problem.

So how do you optimize? Well, if level re-loading is a problem, then isn't level loading a problem? If you think it's just reloading, why on earth are people reloading your level so much more often than they just load the level in the first place? Sounds like a game play problem, not a code-engineering problem. Who thinks its fun to reload a level over and over and over again, and just wishes it was faster instead of entirely avoidable?

Fix the real problem first!

But lets say your game is designed so you are supposed to restart at least occasionally, and the load time is long enough that its OK to do once and utterly unavoidable, but you don't want to have to do it again. What kind of game is this, anyway? Seems like a bit of a weird problem...maybe a high-resolution Portal-like game where its assumed you are going to mess up the puzzle repeatedly?

First of all, you have to realize that this isn't going to be trivial. You are going to have to write completely new, untested code, and it's "state-dependent" so that you might not even know what is or isn't going to be reused between level plays. Are there random elements, spawns, variable textures (do your skeletons only sometimes wear armor?), or other changing elements in your level? Are there things that vary with the player, like an outfit or customized model or colors/doors/traps?

You are going to be doing comparisons, and lots of them. You are going to be looping through level elements, comparing what will be needed versus what is loaded right now (what do you do with stuff that was loaded for the last level but not for this one - release them or hold on to prevent a future load?). If this is really a big deal for your game you are probably going to want to change your load/unload code to see if something is already loaded before loading it (making the code multipurpose but potentially introducing new bugs to previously working features, and functions that carefully release resources that aren't going to be in use in the near future). Sigh.

No matter what you do, even if your game is simple, you are going to get into obscure bugs that are based upon level/player state when a level was restarted that doesn't happen to you load the level the first time. So you get to write game updates with text like:

"Dropping a helmet on a bomb onto a tile that had a missile explode near it that was also within 200 pixels of water will no longer corrupt your game data or cause the game to crash."

## The Real Reason Most Games Don't Bother

Have you ever noticed that most people just paint or drywall over their existing walls instead of stripping down to a base layer, or lay carpet right on top of hardwood floors instead of pulling them up?

The simple fact is that it's all more work for minimal reward. Painting over your existing walls works fine most of the time, and the value of ripping up hardwood floors is often minimal or nonexistent.

The same is true in software, from games to multimedia Power Point Presentations - if all you do is shave a few seconds off a loading screen people spend 1% of their time looking at, then that better be incredibly trivial to do or you are getting a very poor return on your invested time.

And so most games don't bother, and I have trouble thinking of very many games where loading screens made an otherwise good game less worthwhile, except a few extreme examples; the extreme examples are where optimizing for faster level loading makes sense, and that's a tiny fractions of games that make it to the public, and probably even a smaller fractions of games that no one ever sees because they never get released.

Because it's harder to develop the opposite behavior which is all about keeping the static game data (such as textures, geology information, unaffected mobs) in memory and reloading only the dynamic data (such as player position, player stats, quest status, inventory).

Since it costs more money and time, game developers generally don't do that.

• This doesn't cover the situations where the opposite must occur due to the genre of game or individual demands. Such as Prince of Persia needing to record game state in order to use a particular game mechanic and the fighting game examples I gave that need to be able to reload individual item/level/character states in order to reset for halfway through a match to start the next round or restart the match to start the next game. These are needed in order to meet the demands of the game at hand and so it is neccessary for game developers to spend more time and money. – Tom 'Blue' Piddock Jul 22 '13 at 9:34
• If the opposite occurs in a specific game, the question above is invalid for that game. Because the loading time will be fast in the game that the opposite occurs in. I just answered the question for the situation that it applies to (which is the games that loads whole level from scratch) – Xtro Jul 22 '13 at 14:37
• If the opposite occurs where the premise of the question could have happened it is always worth noting it and why. Missing out information or leaving out details as to why a situation or solution has come to be is never benefitial. Saying there is no need for detail is a little counter intuitive as there would not be a question in the first place if the person wasn't seeking detail. If you are able to provide more details always strive to do so as it helps others learn more about a subject as a whole and take what the need from the deatil. – Tom 'Blue' Piddock Jul 22 '13 at 15:54
• so, your reaction is for my first line of answer which is about "no need for details" right? if I remove that line, would you take -1 point back ? – Xtro Jul 22 '13 at 17:11
• Funnily enough - yes. Never discourage detail where it is possible to give it and you'll generally find your answers are gain much greater appreciation. – Tom 'Blue' Piddock Jul 25 '13 at 13:52