What all should be happening during the "Loading" screen?

Question

Do I just need to be creating instances of all of my graphics into memory that are loaded from file? What is the best way to handle this? Do I just need some sort of assets manager that creates these graphic instances during the loading screen and is then referred to later?

What are common things that need to be pre-loaded in games? How much should I pre-load?

Is it worth showing some sort of progress bar? How can I keep load times short? What should the loading screen look like?

What are some good examples of loading screens? Any code examples?

Specifically, my game is for Andriod (Java/mobile), but feel free to make your answers generic.

Answer 1

The typical things to pre-load is anything that you're going to need in realtime. Save for concepts like clipmaps and megatextures (where the idea is to load the parts you need, and iteratively update it as you move around in the world), you're going to want to keep everything you need for your level/area/whatever in memory rather than on disk. IO is sloooow, and you don't want to load your textures when you turn the corner and it is about to be displayed. And by everything, I mean textures, sounds, meshes, meta data... everything.

If you can show a progress bar (i.e. you have an accurate mapping of loading steps to percentage), then by all means show it. If not, at least show something, like a short text message or a loading indicator, which is updated after each step so you can at least tell something is happening.

If there's something which you know will be needed, but not right away, you can load it in the background, and stall the game (not great, but make sure it rarely happens) if it's needed too early. This will help you keep the load time down. I don't know much about android development, or if it'll be to much for the device to handle alongside the game, but it's usually rather light on the CPU so there shouldn't be a big problem there.

Answer 2

You need to be "Reticulating Splines"

Answer 3

Depends if you're going for one loading screen and instant level transitions or multiple loads.
I would say that the latter would be better on memory.
Something like:
//First loading screen
Load menu layouts or whatever
Load GUI assets
Show something to pass the time
Switch to menu

//In between levels
Remove any graphics specific to the last level - get rid of something that isn't going to reappear like a boss.
Load level graphics that haven't already been loaded
Again, show progress or something to pass the time

And when you're loading, make sure not to have a black screen. Or for that matter, a static screen. Many a time have I seen a static image for a while at the start of an app, and immediately thought it had crashed.
A good way to get the player involved simply would be a nicely drawn background of a scene in the game, or some storyline reference; a loading bar with/without percentage, as long as it isn't a static 'Loading'; and then maybe some information.

Answer 4

On iphone and Android platforms, you must load all textures and sounds. Loading textures and sounds is really slow on old phones as iphone 2G, 3G or G1. You can't do it in the game.

Answer 5

As others have said, if you can load all of a level's data before you start playing it, then you'll have much better performance. It's a common source of hitches in frame time to load assets during gameplay.

Common things to do during a loading screen is a static background image, a very simple level, some tips and tricks on how to play, quick animations, etc.

Here's the loading screen for APB. Pretty freaking cool. :) http://www.youtube.com/watch?v=p5STix1t_1E&feature=related

Here's some pseudo code for showing a progress bar in a loading screen:

LoadScreen::Init()
{
  mAssetsToLoad.add("Background.png");
  mAssetsToLoad.add("Player.png");
}

LoadScreen::Update()
{
  mProgress += 1;
  mAssetManager.load(mAssetsToLoad.top());
  mAssetsToLoad.pop();

  if mAssetsToLoad.empty()
    mDone = true;
}


LoadScreen::Draw()
{
  for( int i = 0; i != mProgress; ++i)
  {
     Vector2 pos(i*mProgressPartTexture.Width, 100);
     DrawProgressBarPart(pos, mProgressPartTexture);
  }
}

Ugh, forced to use != because it broke off the code rendering when I used <

Answer 6

Loading screens can be used to hide pretty much anything; loading of assets, any connections it needs to make (tcp, etc), populating maps with game objects, and initialization.

The way I tend to go about things is to have some sort of asset manager (or maybe a manager for each asset types - sounds, graphics, etc.) and have them load what is going to be used into memory. Then just have your game pull references out of the managers.

Showing a progress bar, determining what to preload, etc. seem to be dependent on your project, it's loading times and your tastes. Progress bars are nice if they're accurate and it's a long load (it's nice to know how long you need to wait).

With that said, on my android phone I tend to favor apps that have their own custom, tastefully done loading screen. It doesn't need a bar, but animation tells the user the programs working. I believe android has a default bar you can use, which does the job fine.

Here's a SO question that might interest you.

Answer 7

It's worth noting that the platforms with quality control requirements (e.g. X360, PS3, DS, etc.) will all require you to have some form of animation in your loading screen (or in fact any screen which remains static for more than a few seconds).

This is because otherwise the user may think that your game has crashed, when in fact it is just taking a long time to load. Even where this is not a requirement, I'd certainly advise it.

Any form of animation is fine, but a simple progress bar may not be the best, as any large steps in the loading may result in the progress bar not moving at all for a while, meaning the screen is just as static as if there were no bar at all. Better to show some continually moving image, like a rotating icon, in addition to a progress indicator.

Answer 8

For the loading screens in Conquest, I went with a little bit of mission description (what game type it was, as well as a little bit of storyline for the mission), and some basic help on the commands.

In the background, I was loading sounds. The graphics were all loaded on demand, and that seemed to work pretty well for our game, but sounds were a bear, so I preloaded all of the sounds needed for the mission. The Loading/Start button is disabled until everything's loaded, but I don't have any type of animation (which would be a good thing to add).

This is our first game, so we're still learning a lot, but this has worked out OK for us so far.