Loading Questions

We’ve all been there. Maybe you just entered a new shrine in Breath of the Wild or you got enough moons to go to the next kingdom in Super Mario Odyssey. Whatever game it is, you press the confirm button, eager to see what’s next, only to be met with a mostly blank screen and the words:

Now loading…

Slumping back in your seat (assuming you’re not playing at a rooftop party and sitting on the parapet), you glare intently at the message, brow furrowed. After a long and agonizing five seconds, you can’t help but wonder, “what on earth is taking so long?”

And I intend to answer just that, and many more questions, in the following article! No waiting necessary!

What is Loading And Why Do We Do It?

Let’s start with the basics. As you’re no doubt already aware, games are computer programs, and computer programs process information. Heck, computer programs themselves are information. All of this information, from the code itself to the models and textures, starts off stored on the disc, cartridge, game card, or system storage. To use this information, the system needs to copy it from storage into the system’s memory.

But why can’t the game just use the information while it’s still on the disc? To understand that, I need to explain the memory hierarchy. Memory is divided into multiple tiers: registers, caches, R.A.M., and storage.

Tape? Wouldn't make more sense to solder the hard drives together?

The fastest form of memory is the register. Registers are tiny memory units built into the C.P.U. When I say small, I mean only large enough to store one value per register. When someone refers to a processor as 8-bit, 32-bit, etc., they’re typically referring to the size of its registers (more on that here).

Next are the C.P.U. caches. Caches are larger groups of memory most often integrated into the C.P.U. Unlike registers, however, they exist outside the processor’s core, making them slightly slower. Caches are often themselves divided hierarchically, usually from levels one to three with each level getting increasingly large but also increasingly distant from the C.P.U. Caches top out at a few megabytes in size.

Up next is perhaps the most versatile level of memory: Random Access Memory (R.A.M.). R.A.M. is completely separate from the C.P.U., instead being connected to the motherboard. It’s also comparatively massive, with modern measurements being in terms of gigabytes.

Lastly is the game’s file system, which is stored on a disc, a cartridge, or in the system’s internal storage device. This is typically what people are referring to when they talk about a game’s R.O.M. and—as mentioned before—is the collection of all of the game’s code and assets. Additionally, save data, D.L.C., or patches may be stored in system storage.

So with all of that out of the way, let’s get back to the question of “what is loading”? Simply put, loading refers to the process of fetching data from the disc/game card and storing it in R.A.M. But why do we bother? Well, the further from the C.P.U. you get, the slower each level of memory is. This is for a couple of reasons. First, the higher tiers of memory, such as the caches, use better quality hardware that’s faster but much more expensive. Secondly, information has to travel through each level to reach the C.P.U., so to load something from the game card, it first has to travel to R.A.M., then through each cache, before being processed and sent back out to one of the caches, which can be quite time consuming.

Simply put, loading refers to the process of fetching data from the disc/game card and storing it in R.A.M.

To put it another way, imagine you’re having a snack while watching a movie. Your hands are like registers: they hold relatively little, but are close to your mouth. The cache is like a bowl of popcorn or chips on your coffee table: you have to lean forward a bit to grab a handful of chips, but it holds more than you can with your hands. R.A.M. is like your pantry or perhaps a root cellar: you’ll have to get up and walk across the house to get something from there but it can hold much more food. Last in this analogy is reading from the disc, which is akin to hopping in your car and driving to the store. As you can imagine, doing that every time you wanted a handful of salted carbs wouldn’t be an efficient use of time.

This is also why games usually can’t get away with loading everything all at once at startup and never reading from the disc again. Simply put, there isn’t enough room in the system’s R.A.M. Case-in-point, the Switch has somewhere around three G.B. of R.A.M. (at least available to games), while Breath of the Wild takes up thirteen G.B. of the Switch’s internal storage. Keep in mind that’s thirteen G.B. of compressed data, once those assets have been restored to a usable state, they take up even more room. Also worth noting is that the Wii U (which Breath of the Wild was also released on, in case you forgot) only had one G.B. of usable R.A.M. Yeesh!

Games usually can’t get away with loading everything all at once.  Case-in-point, the Switch has somewhere around three G.B. of R.A.M., while Breath of the Wild takes up thirteen G.B. of the Switch’s internal storage.

How Does Hardware Affect Load Times?

Back when it was first revealed that the Switch was going to use cartridges instead of optical media, you may have heard that one of the advantages of this choice was faster load times. So what about optical media, such as D.V.D.s, makes them slower?

This one’s actually fairly simple. Cartridges, S.D. cards, and other solid state media can be read faster than discs due to the fact they lack moving parts. Not only does the disc itself move, but the laser and light receptor that read it also must move into position, a process known as tracking. As you can imagine, finding the right place takes more time, as does the rate at which the disc spins. Fun fact; the Wii spun its discs much faster than regular optical drives to mitigate this issue, which is why Wii consoles’ disc drives tend to wear out.

This leads to another question, however: why do old cartridge games load near instantaneously while modern ones can take several seconds? Well, if you’ve ever taken a class on computer architecture, you’ve probably seen this graph.

Every year, the gap between processors and memory grows Moore and Moore.

While this is a comparison of C.P.U. and R.A.M. speeds, the fact that I’m trying to make is that these technologies don’t develop at the same rate. While I wasn’t able to scrounge up hard numbers to compare R.A.M. and storage access times, chances are a similar trend is in effect. Moreover, games on the N.E.S., Super Nintendo, and N64 were working with significantly less memory and storage space than modern games, resulting in a much smaller workload.

Will We Ever Be Rid of Loading?

Pfft! No. Well, not anytime soon, at least. While it is true that solid-state drives and media are decreasing load times, they’re still orders of magnitude slower than R.A.M. Even if mass storage did somehow manage to catch up to R.A.M., enough to make it feasible to cutout the middle man, it would require a radical shift in the design paradigm of computers. For reference, the current model, the von Neumann Architecture, has been in use since the 1940’s. Between getting mass storage hardware up to par, developing a new architecture, and convincing the market at large to abandon the previous, well-entrenched model and adopt a new one, I honestly doubt I’ll see such a thing take off in my lifetime.

But just because we’re stuck with loading doesn’t mean we’re stuck waiting. While we typically think of loading as something that forces us to stare at a blank screen or hints we’ve read 42,895 times, many games actually have it happen behind the scenes as you play. If developers know before hand where the player will/can go at any given point in the game, they can predict what data must be loaded next and when.

One of my favorite examples of this is in Luigi’s Mansion. Upon entering a room, the game loads all of the rooms adjacent to it and unloads rooms that are no longer immediately accessible. This is a fairly simple task because each room only has a set number of exits, which means the game knows exactly which rooms the player can reach from the one they’ve just entered. All of this is done in the background, allowing the player to explore the entire mansion without ever encountering a load screen.

I'll confess, hallways have me a bit perplexed.  Probably have loading triggers at certain points, or something.
As the player moves from from one room to another, the game unloads rooms that aren’t immediately accessible and loads the rooms that are now connected to current room. Note how rooms that are adjacent in space but not connected by a doorway aren’t affected.

It’s also useful to disguise load screens. While this is solely conjecture, it’s quite possible that the reason the mirror warp animation in Luigi’s Mansion is so agonizingly long is because it’s actually a load screen in disguise. Food for thought…

So hopefully, next time you’re staring at a load screen, you’ll know why. Loading is a necessary part of making games work and—despite what that agonizing seven second wait may imply— is a subject that often gets a lot of attention during development. Of course, knowing all this doesn’t make it any less frustrating…

Oh by the way, I’d like to thank my fellow Crew members, Scott and Simeon, for suggesting this topic to me. I really enjoy getting to discuss the technical side of games here on the blog, so if there’s anything you’re wondering about how games or consoles work, leave a comment or email me at glen@sgcampbell.info and maybe I’ll write an article about it.

The following two tabs change content below.


Blog Writer/Tech Guy/Pedant
Glen is a lifelong Nintendo fan, having been first introduced to Mario around the age of three while at a friend's house. Since then, he's learned the dark art of computer programming, gotten a masters in computer science, and dreams of someday starting his own game studio. He got this position by writing essays in the YouTube comment section.

Latest posts by Glen (see all)