So I'm working on my first hobby game where I have to implement a proper asset loading system, in my previous projects I have had no problem fitting everything in memory at once. In this, I have estimated that VRAM will most likely be a limiting factor that makes that approach impossible. Though fitting it all in system RAM should not be an issue.

Now, I do not need every art asset loaded at once of course, and determining and limiting what needs to be loaded and what does not is not really what I wonder here. Instead I'm unsure on how to go about designing a proper asset loading system.

While I try to eliminate loading screens, beyond an initial, altogether by being smart about what is loaded and what is not the game still nicely needs to handle the sudden need for an unloaded art asset. Perhaps an object that requires it is suddenly spawned by an in-game event. The way I would like to handle this from the users perspective is to simply pause the game until it is loaded and pop up a "Loading" text on the screen.

I have two possible implementations in mind for this:

1. Finish executing the current frame, render the game state with the "Loading" text and do not do another update until the asset(s) are done loading asynchoniously. This does pose the limitation that any assets cannot be used in the frame they are requested as they may not have loaded yet, which can be an issue as the heaviest of them are both used for graphical and gameplay data.

2. Have the game-loop execute in a seperate thread, and pause that thread whenever an unloaded asset is used. The seperate rendering thread needs to handle this correctly (note that I already have a seperate rendering thread). This should pose few issues, but feels overly complicated for such a task.

So how do games usually do this?

Finally, I'm wondering if it is a good idea to have each State (ie startup menu, game running and the like) provide a seperate "loading state" that they enter when they want to show the user that they are loading something? It feels like it should not be their concern, but each state may need to show different loading screens and at least one of the different "loading screens" will need graphical information for the current game state.

How I Would Do It:

Don't load everything into ram at once, bad idea.

Instead convert all assets to raw format and store in a compressed archive system for latter access.

Then using a virtual filesystem linked to your archive system, load each asset only when you need it.

Physfs is great for this, check it out.

I don't think giving you thousand of lines of code will help you, might only confuse you more. Instead you should impliment your own system, that way you learn what is going on.

In regards to your comment on state loading, that is what most commercial games do.

If you store all data in raw format you will not need another synchronise loading thread. The time it takes to load raw data is insignificant on modern systems, and one thread should do.

I should add that a lot of the data is algorithimcally generated at runtime, in some cases the parameters used by the fairly time-consuming algorithm is not known until the last moment.

Instead I'm unsure on how to go about designing a proper asset loading system.

...

The way I would like to handle this from the users perspective is to simply pause the game until it is loaded and pop up a "Loading" text on the screen.

I don't think it's 'proper' at all. This means once in a while players will have to stop and wait for disk asset to load, looking at "Loading" on the screen all the time. If this happens more than once during the game, I'd start cursing.

"Jump jump action! LOADING...FUCK! Action again! Shoot! Dodge! LOADING...#!@$!"

You might say, "but oh it's quick so user probably won't even see it". Don't assume so. File IO is one of the slowest IO operation. If user's computer is set to sleep the hard-drive after 5 minutes, then it has to wait until the hard drive spins again. What was a 10ms operation before becomes 5000ms.

What's wrong with loading screens?

What's wrong with loading screens?

Wont really work well at all for the game I'm designing. As it is a space-strategy game with a fair bit of ground action, and as the gameplay is planned showing loading screens at any time except game startup would very much interupt the flow of the game. The planets themselves need a fair bit of detail due to the zoom allowed, enough that I cannot fit all of them inte video memory except on high-end vide cards. Fitting them all into system RAM is both trivial and required, as they affect gameplay as well as their apperance.

Having low-resolution versions of them, for display purposes, makes it possible to view them all at a high level of zoom. Selectily loading them into VRAM as the player zooms in on a region is fairly straighforward and any latency from that can be hidden. It is rather the sudden unanticipated need for new data (ie, some event suddenly creates a new planet somewhere and it's height and terrainmap needs to be generated with an algorithm) that would prompt the "Loading" text, and given that there will be very few instances where the game cannot predict what data it will need ahead of time the player will only very rarely see the "Loading" text at all.

The regular textures that represent plain images will be few in number and most fairly low in resolution.

[quote name='PAndersson' timestamp='1357167726' post='5016884']
As it is a space-strategy game with a fair bit of ground action, and as the gameplay is planned showing loading screens at any time except game startup would very much interupt the flow of the game.
[/quote]

But this is exactly what you were trying to do. Having the word "Loading.." with the background of the game is not much different than a designated Loading screen. It becomes the loading screens.

It is rather the sudden unanticipated need for new data (ie, some event suddenly creates a new planet somewhere and it's height and terrainmap needs to be generated with an algorithm) that would prompt the "Loading" text, and given that there will be very few instances where the game cannot predict what data it will need ahead of time the player will only very rarely see the "Loading" text at all.

[/quote]

Depending on these unanticipated events, I'd try to hide the loading using some kind of animation. For example, if a new planet is born, instead of showing "Loading...", show a specialized screen, like "Dam da dum dum! A new planet is born!! Explore it for new resources!" showing some quick animation that users can't cancel out -- during which the loading takes place.

I didn't read everyones reply, so sorry if this has already been said.

The way i've done this in the past is to have a game thread and a load boss thread and a number of load worker threads.

The game thread queues up assets ids that need to be loaded (newly visible stuff in an oct-tree), then passes that queue over to the load boss.

The boss thread knows how many worker threads are available, and gives each worker a thing to load. When the thing is loaded, the worker thread

signals the boss thread, who gives the worker the next thing in the queue. Once the entire queue is processed and all worker threads are asleep the loader thread lets the game thread know that it is safe to proceed.

How much loading time you have will greatly depend on how large the chunks you request are. Take a look at "Jack and Daxter", the whole world is constantly streaming in and out. Now, there are some edge cases where you can run into an area that causes another are to be visible and end up in a situation where the game needs to load; when that happens jack trips, falls and gets up. This animation is enough to load in the missing assets and is pretty damn funny. If that had been a "Please wait, loading" screen, the whole thing would have been a lot more frustrating.