When is it best to load screens in mobile games?

Question

In the develpment of a mobile game, is it a good to load all the screens at the start of the game, or destroy and create new ones during the game? I am doing the second thing, because I suppose that the first one consumes a lot of memory, what's recommended?

Answer 1

This totally depends on the nature of your game, and how much data is actually on each screen. My approach to this would be as follows: avoid premature optimization. With that said, let me elaborate a little, and explain how I've managed this in some of the games I've written for mobile devices.

I typically load textures as they are needed, because most (if not all) mobile devices have very limited memory. In order to keep performance high, I try to keep these textures around as long as possible, if there is a reasonable chance I'll need it again. A quick example:

I have a texture that is my pause screen. It has some button looking things, that have hotspots around these "buttons" and a few blank areas where I draw text. The first time the pause action is invoked, I pull up the texture and draw it, then when they resume I keep it around, in the event that they pause again. Now, if memory became an issue in this game, I'd ditch the pause menu texture when they resume, so far, its not been a problem.

Answer 2

Mobile devices are a lot more memory constrained than desktop platforms, so usually it is better to build screens on demand during the game. It's the usual efficiency tradeoff though, between processor usage and memory consumption.

Answer 3

Not sure what you mean by loading screens, but I'll try to answer for the general case of loading any asset / data.

The trade off basically comes down to efficiency and simplicity. Loading all assets up front is very simple because you never have to worry about whether something is loaded or not. You can handle dependencies (for example, a 3d model might depend on textures) explicitly in this case and avoid the complication altogether. However, you'll be loading things that may not be required at all, which incurs unnecessary load time and memory footprint.

If you load things as needed, you can potentially yield a better experience, because the user will only be forced to wait for as many assets to load as are actually required, and these loading times may be stretched out over several short periods. Additionally, you can keep your memory footprint to a bare minimum. However, you have some additional complications:

• What do you do when two independent things require the same resource? You need to both make sure that this resource isn't loaded twice and ensure that when one of these things no longer needs it that it isn't actually unloaded.

• You'll potentially need to have some checks to make sure that all loading is in before you continue. This might be additionally complicated by the fact that some things can only be done by one thread or another. If you only use one thread, you'll have to make sure that thread can service any code required to load assets during the loading period (for example, loading a texture into video memory can generally only be done by one specific thread.)

Some or all of this may not be relevant, depending largely on your context. So I would say that if you aren't in a situation that you need to be conservative about memory or long load times that you load everything up front and you won't ever need to worry about it. If, on the other hand, you feel the need to reduce or segment load screens / times or need to use the least amount of memory possible, design a system to allow you to load things at different times. Just be aware that the latter can come with some obnoxious complications.