Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

I definitely will add additional keyboard support in the future thank you for the tip.
Thank you for the debug output. That definitely points to something I was not expecting. But Hopefully it will help me run down the bug.

Per your question. Although I am using threaded loading internally. In reality threaded loading is not possible. This version of Godot is using the Single Threaded Web build of Godot.  Though I am pretty sure my Background loading models does print that it is using a thread. In reality the code detects it is a web build and knows it cannot use a thread. I need to modify that print statement as it is misleading. Though, on a desktop version it would use threads. So unfortunately any loading is actually done on the main thread and will cause stuttering. I do think I could have loaded the entirety of the ship in a single scene. But I still need to test that theory and see if it holds for a phone, as I am hoping to also target smart phones. Another thing I would like to try in the near future is to get scenes to be sufficiently chunked by making many sub scenes and then see if I can load the dependencies first at a rate of 1 dependency per frame, as that may let me do some preloading and simulate it being a background thread. Definitely more work to be done in that area.

(+1)

Oh okay, it does make a lot of sense ! That's quite clever to switch depending on the export type !

Since all part of the ship share most of their textures and shapes, it might work to simply load everything up at the beginning and simply removing unneeded area from the node tree with "remove_child" at runtime an putting them back on the tree as needed, no ? As such, unneeded area don't have any impact on processing time while staying in memory for quick loading. I guess it really depends on how low of a device you want to support.


Why did you chose to stay away from multi-threaded web export ? They seems fine now on Godot 4.3 & 4.4. It also looks like most major hosts now support SharedArray Buffer. Is there an additional issue with multi-threaded web that I do not know about ?


Thanks a lot for all these details !

(1 edit) (+1)

That is a really good idea about holding scenes via reference but not adding them to the tree until they are needed. That is a smart simple solution. For some reason I did not consider that. This conversation has been very helpful for future optimizations and improvements.  I will definitely try the off tree technique for future optimization tricks.
I choose to avoid the multi-threaded export because of our experiences in the past year with them. Safari is definitely still a problem with SharedArray support at least on iOS. Most non-mainline (e.g. things like googles search browser on android, or other embeded browsers, not chrome, which for some reason many people actually use) browsers also do not support Shared Array support.  I also saw Firefox break Shared Array support 3 times in the last year. 

Oh and now I remember cross-origin isolation. I would like to be able to have the games be-able to call home to our website to check for news updates. I also would like the potential for multiplayer support in the future. I do not know for sure that all of this conflicts with Cross-Origin Isolation, but it seemed to be causing me problems. By not needing  to meet cross-origin isolation requirements, I can have the game check for news content on our site and ideally in the future add a server that would allow for dynamic multiplayer akin to No-Man's Sky. At least those are my wild plans...
Thank you for the discussion.

I found another reason for why we went Single Threaded rather than muti-threaded. We have been working to integrate the Terrain 3D addon into our web projects. It now supports the web but currently only supports the single threaded version of Godot in the web. Now hilariously we are not using any Terrain 3D in this project. So I may simple remove and disable that to have a multi-threaded version.

I do not yet have the new build ready yet, but I have been working on my framework for the last week to re-write it to better handle loading and scene swapping. Your discussions with me really helped guide this re-design. I now have it smoothly supporting loading and swapping of scenes both single and multi-threaded. I also implemented your concept of Hot Scenes which I have named Stored Scenes, and now the framework can load multiple scenes into memory, while only assigning 1 as the current scene. It can also swap scenes in a single frame if the scene is a Stored Scene. This should make loading much faster even in a single threaded environment. Also finally I made sure that if an error in scene loading does occur, we now catch the error as best I can to let the user know and take them to an exit screen.

Again I just wanted to say thank you for helping me think through a better way to design our game framework and I hope it will result in better games from us in the future.