Loading Bar For Game and Level Loading Progress #161
Assignees
Labels
scope:small
A small and well-defined task
Comments
bors bot
added a commit
that referenced
this issue
Jul 29, 2022
164: Implement Load Progress Tracking r=zicklag a=zicklag Loading screen still needs to be implemented. This PR implements a solution for tracking the load progress of game assets. This works towards #161, but it doesn't implement the UI yet, just the load progress tracking. It allows us to get the load progress for both `GameMeta` and `LevelMeta` and adds logic to wait until game and level assets are loaded before starting the game/level. This time period should be replaced with a loading screen in a subsequent PR. #### Why This is So Complicated Tracking the loading progress for the game is not trivial due to the fact that we have _several_ different kinds of asset and handles referenced throughout the `GameMeta` struct at many different levels of struct nesting. My initial thought was to add a simple function where I simply manually return all the `HandleId`s in the various different parts of the `GameMeta` struct in a vector. This instantly became very difficult because of how spread out between types the handles are. There wasn't a good way to know if I had gotten all the handles, and if we added more handles later, we would have to remember to update the list which would be horrible to manage and would almost surely become out of date. Instead, in this PR I added a `HasLoadProgress` trait that we use a custom derive macro to derive on `GameMeta` and all of the structs that it contains. This ensures that _all_ of the handles contained in the `GameMeta` struct will be properly evaluated when checking load progress and it doesn't require difficult manual listing of handles. The cost is that we write a macro and add a macro crate to our codebase, but this took me less than a day, and it is a relatively simple macro. I think it turned out rather elegant and I don't know of any other reasonable alternative at this point, but let me know if you have other thoughts! Co-authored-by: Zicklag <[email protected]>
|
Removing from 0.0.4 for now because loading times, even on web are so far small enough that you'd hardly see the loading bar, and we fixed the issue of things popping up one sprite at a time by making sure it was all loaded before starting the level. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
While it isn't a big deal on native yet, loading assets over the network on WASM builds has a measurable delay which causes things like the menu or fighter sprites to start off invisible and then pop up after the menu/game starts.
This is also going to be important for scripting because while we execute script functions synchronously during the game update, we have to load script modules asynchronously, possibly loading modules over the network. At least in native builds, while we are loading modules over the network, we are unable to run scripts. ( This could probably be worked around, but not easily )
The easiest solution is just to load all of our script modules asynchronously before the game starts, so that we don't have to worry about wanting to run scripts while we are in the middle of loading them.
We should have a loading progress bar displayed in two places:
We can use the same UI widget that we use for the life bars to render the progress bar.
Alternatives & Prior Art
No response
The text was updated successfully, but these errors were encountered: