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?

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

• I know that this is not specifically what you're asking for, but my advice for what should be happening during the loading screen is: Something Interesting! :) Entertain the player with a bit of story (like a cutscene), a minigame, or maybe already show a menu insofar possible. – Bart van Heukelom Jul 27 '10 at 9:03

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.

You need to be "Reticulating Splines"

• Haha, nice reference :) – Bryan Denny Jul 22 '10 at 17:47
• Although this is obviously a joke, +1 for referencing a great example of keeping players occupied during loading. Such a simple technique that involves no more effort than adding nonsense text. "Don't Starve" is another example of a game that does this well, and also coincidentally (or not) also involves "Reticulating": dont-starve-game.wikia.com/wiki/World_Generation_Screen – twiz May 15 '14 at 20:11

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.

• I can agree entirely there. I don't think it's going to have been done well if it jumps like that. – The Communist Duck Aug 6 '10 at 18:14

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.

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 some pseudo code for showing a progress bar in a loading screen:



{
}

{
mProgress += 1;

mDone = true;
}

{
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 <

• Wow, APB load screens look really cool :) – Bryan Denny Jul 22 '10 at 18:58
• If you indent your code with four spaces instead of using the <pre><code> tags, you will be able to use < instead of != without breaking the formatting. – mmyers Aug 6 '10 at 15:30
• mmyers, yeah, but that's a big pain in the ass. Why isn't there just a custom code tag? – Srekel Aug 7 '10 at 11:27

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.

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.

• Of course, it the loader is loading asynchronously, you should be able to poll it's progress so you can more accurately update the percentage. That way the player knows that if it does get stuck at a percentage something is actually wrong. Also, like I said in other places, please don't update the animation without actually checking with your loading thread whether it's still running, or you'll be happily spinning while the game effectively crashed. – Kaj Aug 7 '10 at 6:46

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.