Couldn't all games avoid post-start loading?

Question

Just as giant open world games load massive maps dynamically, couldn't we load separate maps, menus, and virtually any interface or 3D setting via that same dynamic loading method? Without changing the environment, it seem like interfaces and various locations within the game could all be loaded dynamically the same way massive open world maps are loaded as you walk through them.

Why isn't this done? I see so many modern games where you have to wait a minute or more while the match / map / level is loading. I know there's a latency involved with connecting peers, but that doesn't take more than a few moments in my experience. What issues exists with this concept to stop it from being used to eliminate loading time involved with loading map / level / interface data?

Answer 1

The answer is yes, this could be done, in most cases, at least to some extent.

The reasons it isn't done are many:

• It requires time and money to do it right.
• The amount of bugs that pass testing will be higher
• Load times are accepted by the users.
• There can be other reasons for load times, such as balancing server load.
• Generic solutions that can be bought off the shelf are more compatible with "load all at once".

Answer 2

If your menus have a ton of assets, those assets take time to load. You also have no idea what order people will navigate your menu. They could click options -> back -> credits, or credits -> back -> start game in rapid succession. So there's no reasonable streaming strategy.

In an open world game, you know the player won't move faster than some certain speed, so you know you don't need to load the detailed versions of faraway locations until they are approaching them.

Answer 3

A big factor in the feasibility of such a solution is the predictability of what needs loading. If the player loads entirely new levels with no way of anticipating what they will choose, a completely seamless solution is just not possible. For example, when the player may select any level in the game to play from, or if they have freedom to teleport to completely different areas in open world games.

Some Halo games start loading the selected level in the background while setting up multiplayer games. This reduces waiting time when the players are ready to start, and is probably the closest one can get to such a solution when the player can freely choose different levels with completely different assets.

Of course, you said "without changing the environment", but I just wanted to bring up the Halo example, as it's something I'd like to see more of.

Within a continuous campaign, or whenever the developer has a lot of control over the player's location, such a solution is certainly viable, just as you say. Naughty Dog likes to do away with loading times, with Jak and Daxter famously having no loading times on the PS2, and Uncharted games having a single loading time at the beginning.

However, to many, loading time just isn't a problem that needs solving. Or it's a problem that's very low on developers' priorities, when there's always more that could be done between now and release date.

Answer 4

Time.

You need time to save time. Or you need money to make up for the lack of time. In any case, "No loading time!" is a feature that only those who have the luxury to afford it can offer. It takes very careful planning, and you need to understand very well what you're doing and not all game developers have the resources to put on it.

Answer 5

Ultimately, it's limited resources.

Open-world games and especially MMOs are heavily crafted toward predictability - you always know what data you need to load well in advance. You can see this in the architecture of the worlds - anytime there's a lot of resources that need to be loaded, you have some way of preventing the user from seeing the stuff that isn't loaded yet. The most common way is gates and entrances that block your view into the next area for the crucial few seconds needed for the loading. Most MMOs also use less detailed models and textures, which shortens load times considerably.

Some things are still unpredictable, even with careful design. For example, there may be custom banners worn by players, that are only shown once the relevant data has been sent to your computer over the network. Of course, most games try to limit this to make it cheaper (e.g. Diablo III's banners are simple compositions, easy to send as few bytes of data). But ultimately, sometimes you just have to wait for data to come by. And you need to show something while the loading is in progress - in many games, this can cause a break in immersion as you see a grey, low-detail model shown while waiting for the data to be loaded.

And with all this, loading like this is a solved problem(TM), but that doesn't make it easy. It costs a lot of resources and time, both in optimizing the resources and their utilization to ensure a smooth playing experience, and in the code itself - asynchronous code is hard. It can also mean a lessened game experience even if everything goes right - it means that you have to ensure you don't cross the bandwidth capabilities of your lowest common denominator, so you need to lower the quality of models and textures, or make them less varied, and the geometry of your worlds is severely limited. If you don't, the game will be quite unplayable - while I remember people who played games that took 10 minutes (or even longer!) to load a map, simply because their computer wasn't quite up to the task, the game itself run fine after that. If it had seamless loading instead, the game would just freeze or show ugly textures and models all the time while waiting for the data to be loaded. Deferred loading isn't a win-win, it's a trade-off as most things in engineering :)

Answer 6

One reason dynamic loading isn't always the ideal solution that other answers haven't really considered I think is also pop-in and other graphical artifacts.

The prediction of what to load and what not to load often fails, and it can be a detracting experience when it does. One of the worst examples of this was in Rage by id Software. At least in the early versions, the megatexture systems made it so that even something like spinning around too quickly made enourmous amounts of texture and even geometry artifacts appear before slowly fading away.

These issues just aren't a problem is everything is preloaded.

Something to consider isn't necesarily what to load, but what to unload. When you've only got so much budget for space, when you load new things, what are the old ones to remove? How certain are you that those assets aren't going to be in use within the next few seconds? These are difficult problems to solve.

If every gameplay state is small enough to fit inside a common system budget, then every advantage is apparent, instead of loading, you just go straight into a level and things fade in as you play. But, as the main answers suggest, the loading time for a small game wouldn't be too extensive to worry about anyway.

I think it's worth thinking about the reasoning why dynamic loading systems were created originally, being that you know that several of your gameplay states may be too large for a common system and a game of that size just isn't possible to preload entirely.

Answer 7

One common reason is that it isn't always equally easy to determine if a resource is going to be needed in the near future.

Since you used terrain paging as an example, I will continue with that.

It's perfectly reasonable if you're in a given map grid to load all adjoining map grids in the background. You know the user can, at best, enter one of those. When they do, you can unload the ones no longer adjoining and load the ones that now are. This you have noted.

Now imagine fast travel. There is absolutely no way to predict where the user may choose to go. They have (usually) almost the entire map to choose from. Pre-loading all possible fast travel locations would take far too much memory (you might as well load the whole map into memory in the first place) and far too much time (assuming you did not have the whole map pre-loaded). When would this happen? When they open the fast travel dialog? The problem would only become several times worse!

This is why even most games with "no-load" terrain paging still have load screens on fast travel. It's also why, if you move fast enough, you can sometimes trigger loading screens in even games with no-load maps (I recall having done this in TES Oblivion).

Now imagine this applied to game resources in general, where relationships are often not obvious. You will end up having to either load all possible options, or start guessing what the user is going to do. Guessing is costly (both in development and CPU) and a complex mess to program. Specific examples:

• Save files: you would need to load every save file before the user reaches the save screen, or guess which file they might load (latest 5, etc.).
• UI: Many strategy games change their UI depending on your faction. You would need to load every possible UI design before the user started their game.
• Game world: in procedurally generated games, like Minecraft or RTS games like Civilization, the world doesn't exist until viewed, to varying extents. Pre-loading this is impossible since they did not exist to begin with; pre-calculating them could at best be done similarly to pre-loading, and is not applicable in the RTS case.

There might be ways around some of these issues, but that costs real life money to figure out. Most gamers accept reasonable loading screens and, if anything, tend to be willing to spend more on hardware to mitigate them. It's seen as a hardware issue, not a game issue, unless unusually excessive or otherwise disruptive (like loading in the middle of levels).

And keep in mind, background loading is not free. There is usually minimal impact from the modern use of background-loading terrain and some model files, but if you're suddenly guessing about many different resources, especially if you don't have reliable metrics and have to unload many resources and load superfluous ones, you can grind the system into dust.

The idea of background loading is to use the dead cycles for a better use, but there are only so many dead cycles to use. The same goes for memory - pre-loading can substantially increase the memory usage of a game. With a loading screen, you get to dump the existing resources. No such luxury with background loading, meaning it could double the memory requirement of the game on that count alone.

Answer 8

This is a common issue stemming from the fact that games are soft-realtime products, where a late delivery of content is not as useful as an on-time delivery (contrast with hard-realtime, like the cars in computers, where a late delivery can be no better than no delivery at all). You have to decide what to load and where.

Sometimes, the late deliveries are particularly bad. For example, if you are permitted to run around in a world before all of the walls are loaded, you can get behind a wall that you could never have gotten behind if the game loaded the walls before letting you move. It is not always easy to tell when you can get away with a "lazy" loading of content, and when you have to guarantee that the content is fully loaded.

Dynamic loading is also far more complicated. You constantly have to consider what to do if the resource has not yet loaded. This is a drain on development resources. It's far easier to develop when you can rely on the resources to exist.

The latencies are also not always acceptable. I've heard of cases in Starcraft where you would "warm up" your game by loading a map that has a side effect of caching every dynamically loaded model/image. You would then exit, and play the game normally. For the elite gamers, this minimized stuttering of the GUI which actually affected their gameplay. Trying to prove out which latencies will be acceptable to users and which will not is tricky.