What is the logic behind the 'Loading' scenes in games?

Question

I'm making my first game, it's a tower defense type of game, using Unity game engine and taking Fieldrunners as a reference. I would like to know more about the functionality behind 'Loading' scenes in games.

Until now I am instantiating/creating objects at run time and I'm not facing any delay or similar issues doing so. So what are 'Loading' scenes in other games used for? Is there some functionality or instantiation of specific objects for the next round or stage? If yes why do I need them if I'm not getting any delays?

Answer 1

Basically, I'd say that during the "Loading" process the game tries to load and precompute all operations that cannot be done in runtime. For example, retrieving images (to be used as textures) for the hard drive is usually a slow process. On the "Loading" step these images can be copied to RAM memory, which is muuuuch faster access storage, enabling real-time access to images on run time.

Answer 2

A loading screen can also be used as a "cut scene" (http://en.wikipedia.org/wiki/Cutscene) to give the user a chance to catch their breath, to learn more about your game story & features, or to try to sell them a paid version/in-app purchase

Answer 3

I think games modern should have been able to ditch loading screens.

I'm guessing the real reason that we still have loading screens is that most games are designed to run on Xbox 360 hardware. As such they will be limited in the amount of ram they can load stuff into and how much threading they can do. If you don't have enough ram then you will need to be dropping a lot of stuff out of memory and then reloading it from disk. Also it's just easier to load everything at once.

There are also times when things like the harddrive might stall. What happens if the user is running antivirus in the background. If your not preloading stuff then you might have to have the game pause while it waits for that mesh to load or having things spontaneously appear.

Games like Skyrim can provide you with a wide open world that you can run across as much as you want but as soon as you open a door to load a relatively small dungeon you get stuck with a loading screen.

About the only reason I could see the dungeon load screen being needed is if they use some extra heavy prebaked lighting used for indoor scenes which if fairly large to load (made from 1 giant mesh or has detailed lightmaps) or needs some calculations to be done at runtime. I believe the Skyrim dungeons are just built from modular meshes rather than one giant mesh (at least I think Oblivion's where).

There's no real reason to load more than the stuff you can actually see when entering the level. The same way games don't render stuff you can see, you can cull what you actually need to be loaded straight away. You can also stick in a lot of dummy place-holder objects. Then you can use threading to asynchronously load objects in surrounding areas, their meshes, the textures and so on as the player moves around the environment.

The way I would ditch loading screens is as follows:

1. Load the basic game world properties. Global scripts.

2. Load the player's position.

3. Load the gridcell/BSP node of that position.

4. Load just the bounding boxes of the objects in that cell.

5. Work out what would actually be rendered (tests on the bounding boxes, maybe occlusion rendering tests)

6. Load the meshes of the stuff that is rendered.

7. Load the materials the textures of the meshes.

8. Preform more tests to see if more regions are visible and need to be loaded (ie query a render a whole grid cell as a giant cube).

9. Once everything visible is loaded start rendering.

10. Load the rest of stuff in the cells and Load more stuff as required. Load nearby regions and do some basic prediction on the players movements to choose which regions need to be loaded first. Keep going until memory fills.

There are some other things that need to be taken into account. For example some stuff needs to be loaded even though it isn't visible. For example an enemy that is standing behind the player outside of the region would need to be active so they can run toward the player and attack them. Possibly the occlusion test stuff is unessential since you will immediately want to load anything near so its there when the player moves and it becomes visible but it could shave off a second to get straight to the render (but if time is that close then you are likely to get problems with stuff appearing).

If possible those steps should be started before they are required, threaded off in the background. For example if you are at the main menu of the game then it should start to preload the starting area the loads after you choose "New Game" (or as soon as the menu appears) and the last save for continue. Other saves can preload when you move the mouse over them. As you approach a dungeon door, it should start to load the next level (although if you can do that then you don't need a special dungeon door since they are really only to trigger a loading screen). Load in the background while the video plays. That way you wouldn't even need a short initial loading screen.

You can skip a lot of that if you don't mind stuff 'popping' into existence. Something like Second Life just leaves you with stuff appearing, since its being retrieved from the internet there's not much you can do about that. Assassin's creed has that effect where stuff whooshes into the scene so you might be able to get away with stuff for artistic reasons.

Answer 4

In Unity, scenes are a combination of multiple game objects. So if you don't want to specify all your gameobjects separately and load them one by one, you can simply load a complete scene.

When loading a scene in Unity, the already existing objects are trashed and therefore a whole new level is loaded. You can indicate which objects you want to keep with the DontDestroyOnLoad method.

In your build settings when publishing a game, you can also indicate which scenes are used in your game and include them in your current build. This makes it possible to make a distinction between multiple platforms that contain different levels, but the same code logic.

Unity specific questions can be asked on the unity answers forum as well. These users are more specified to Unity, instead of overall questions on game engines.

Answer 5

A 3D graphics scene takes time to set up, and maintaining it can push a computer beyond its limits. The contents require extensive memory. The visible contents require extensive time. And as the observer zooms out and looks at the horizon, an awful lot of the total contents can become visible. (Ever notice how some games work better if you don't zoom out too far? Ever notice how some games don't let you zoom out too far or look at the horizon?)

The solution is to set up individual scenes with limited contents. Now the game works fine until the observer leaves one scene for another. At that point, the old scene is discarded and a new scene is set up, which takes time (and a loading screen to try to keep the user from getting bored). 3D engines usually try to do as much work as possible during the set up to make the graphics as smooth as possible later.

I have seen games that seem to allow rapid, free movement and zooms over an entire world. There's probably a lot of genius and a lot of laborious programming and artistry there; they didn't just download some free graphics software.