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?

  • 17
    \$\begingroup\$ Note that in many 'seamless' open world games, there are loading times when the player moves to an unpredictable location. One can walk from one end of New York to the other in The Division without sering a loading screen- while fast travel to a location requires loading. It's all about knowing what to load next. \$\endgroup\$
    – Felsir
    Commented Apr 27, 2016 at 9:55
  • 2
    \$\begingroup\$ @Felsir Dungeon Siege did it the same way. \$\endgroup\$ Commented Apr 27, 2016 at 14:08
  • \$\begingroup\$ As an example, Batman Arkham Origins uses loading screens just before cutscenes and when entering entirely new areas. Its story-driven, progressive nature lends itself well, and gives the user a natural break. This works especially well due to the very expansive areas with very high-definition assets. It would be very time-consuming to code and test this feature for little benefit. \$\endgroup\$ Commented Apr 27, 2016 at 19:06
  • \$\begingroup\$ bring your RAM up to 128gb. Create a 64gb or so RAM drive, load your game onto the RAM drive. Load times will be so quick you will barely notice them. I upgraded to an SSD and most load time shorten dramatically. Upgrading the video card, especially to more video RAM. \$\endgroup\$
    – cybernard
    Commented Apr 28, 2016 at 4:32
  • 1
    \$\begingroup\$ Async loading takes time, which can vary based on CPU and disk speed. You can't always be sure things will be loaded by the time you need them. \$\endgroup\$
    – Alan Wolfe
    Commented Apr 28, 2016 at 14:02

8 Answers 8


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".
  • \$\begingroup\$ As a follow up to the 'balancing server load' point, a lot of Online games coming into the market today feature a central 'hub' area that is unique to you and no on else can access. Quite often, these areas are placed behind a load zone or a slow walking area (for example, the BOO in 'The Division') so that they can safety take you off the instance you were previously in and place you in your own private instance. \$\endgroup\$
    – SGR
    Commented Apr 27, 2016 at 13:55
  • 9
    \$\begingroup\$ There's also the issue of memory. It might not be possible to load an existing level whilst keeping the current one in memory (particularly for consoles or portable devices), so you have to use a loading screen \$\endgroup\$
    – Jezzamon
    Commented Apr 28, 2016 at 1:48
  • \$\begingroup\$ @Jezzamon I'm thinking the entirety of the Skyrim map is never all kept in memory at any one given time. Maybe Im wrong? But if not, why would any other situation be inapplicable with the dynamic loading strategies of massive open world game maps? \$\endgroup\$
    – J.Todd
    Commented Apr 28, 2016 at 8:10
  • 1
    \$\begingroup\$ Virtually nobody rolls their own game engine from scratch anymore. They buy an engine (Unreal, Unity, CryEngine) and a bunch of middleware and glue it together. The base engines aren't usually set up to stream-in content on a continuous basis, or to restart without re-loading. Think of how many times you've died in a game only to be faced with a 60 second load time, despite the fact the assets and level were already loaded. The reasons @Peter gave are also the reasons you don't see games that let you start playing them while you are still downloading the assets very often. \$\endgroup\$
    – Tom B
    Commented Apr 28, 2016 at 14:36
  • 2
    \$\begingroup\$ @Viziionary Levels normally reuse textures a lot, and a different level uses a different set of textures. A dungeon level will use lots of dungeon wall textures, a desert level will use sand and desert rock textures, a mountain level will use rock, grass and snow textures, etc. For games where this holds true, unloading half a level when the same textures are used all over the level will only free a small fraction of the memory used (or it will unload textures which you still need). \$\endgroup\$
    – Peter
    Commented Apr 29, 2016 at 14:43

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.

  • \$\begingroup\$ Why not prioritize loading heavy/often accessed menu? In any RPG, if I open the menu, it s 90% of the time to equip something I found, or use a item. You could start by thoses menu. Or start with the menu that take 5min to load, and drop the loading if the user exit the menu. \$\endgroup\$
    – DrakaSAN
    Commented Apr 27, 2016 at 7:04
  • 1
    \$\begingroup\$ @DrakaSAN But that is often optimized. Even the original Diablo showed you the inventory at the drop of the hat. The "wait for everything" approach seems to have had a major resurgence with modern consoles, which were very limited in memory compared to a PC. And since so many games that are on both PC and console are ported console->PC, some console limitations are inherited in the process. Compare Diablo III or Divinity with Skyrim or Dark Souls - the differences are rather obvious. \$\endgroup\$
    – Luaan
    Commented Apr 27, 2016 at 8:39
  • 2
    \$\begingroup\$ Are slow loading menus a real problem in gaming? No. \$\endgroup\$
    – Alan B
    Commented Apr 27, 2016 at 12:22
  • \$\begingroup\$ @AlanB only if the only way to access consumables are through that menu. See Destiny on the Xbox 360/PS3 and how long it takes to use an Ammo Pack compared to the XB1/PS4 versions. \$\endgroup\$
    – SGR
    Commented Apr 27, 2016 at 13:57
  • 1
    \$\begingroup\$ @SGR I was about to use Destiny on PS4 as an example of a menu with unacceptably long loading times, I can't imagine how much worse it is on last gen consoles. \$\endgroup\$ Commented Apr 27, 2016 at 14:12

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.

  • 3
    \$\begingroup\$ Jak and Daxter do have loading times. They're just hidden behind doors, in a similar method to ME1 elevators and how they hide loading times. \$\endgroup\$
    – Nzall
    Commented Apr 27, 2016 at 11:04
  • 2
    \$\begingroup\$ But loading times hidden behind S-curve halls and such doesn't feel like load times. \$\endgroup\$
    – Almo
    Commented Apr 27, 2016 at 12:30
  • \$\begingroup\$ If I understand right, open world maps like Skyrim arent loaded into memory, just the pieces the user needs to see immediately, so couldnt you pre-load in small starting portions of all (20?) maps? With proper optimization of map data it seems like the actual RAM used isnt much of a problem in terms of modern RAM amount, even on mobile. Its the video card's rendering power that bottlenecks most games I think.. I just seems like you could load the starting areas of all those halo maps for the user, then render the selected one while dropping the rest from memory. \$\endgroup\$
    – J.Todd
    Commented Apr 28, 2016 at 12:38
  • 3
    \$\begingroup\$ The maps aren't what takes forever to load - it's the enormous textures, model files, shader programs, etc which are specific to a level or area. \$\endgroup\$
    – Tom B
    Commented Apr 28, 2016 at 14:29


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.


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 :)


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.


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.


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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .