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.
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:
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:
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:
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.
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.
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.
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
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:
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."
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.
