Loading system

[micca]

I'm interested in the theory of making a loading system. I'm not talking about save/load system, but a loading system like a loading screen but ingame, when you need to generate a huge amount of objects, scripts, units, etc.

I've seen it in Mineralz and wonder how and why is this made. Maybe I can make this to reduce initial lag of my maps.

 

[Dr Super Good]

I've seen it in Mineralz and wonder how and why is this made.

The issue is that using object types that have not previously been used cause asset stalls while the required data is loaded from storage and processed. These stalls can be multiple frames and loading many such object types can cause a significant freeze. Additionally generating a lot of objects or applying complex logic like for random map generation might also cause significant freezes and performance issues. To hide these, a fake loading screen is used where the player will be unable to tell that Warcraft III is running at a significantly lower framerate than usual. Additionally even if the player was willing to suffer a low frame rate the map might not be playable yet as it has not finished being initialized. If one shoved all the loading to map initialization without staggering then one would get "waiting for player" dialogs appearing due to differences with client performance.

The modern Lua approach to create these is to use coroutines to perform the load actions with yield calls to apply a delay. The coroutine is periodically resumed, e.g. 10 times a second, until it is done. By spreading yield calls about one can assure that complex logic or object type loading happens smoothly over an extended period of time minimizing frame rate drop. This is not easilly possible in JASS as there is no such fine control on yielding and resuming threads meaning one would have to create an unmaintainable mess of code specified to run at different times.

The current approach is to either use TriggerSleepAction or several triggers set to run at different times, eg every 0.5 seconds. Only after the final one is finished is the loading screen removed. Due to fragmenting loading as well as the course granularity it can be annoying to write and maintain such loading as well spread the loading out enough that frame drops or even waiting for player does not noticeably occur.