Skip to main content

Browse GamesGame JamsUpload GameWinter Sale 2025Developer LogsCommunity
On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
FurAune301 days ago (1 edit) (+1)

Great entry !

I really liked how the sensory overload built up little by little until you have so many things to manage at the end ! My only complaint on the subject was that maybe the first failures could happen a little bit faster.

The tutorial at the beginning was a nice addition : I had no issues figuring basic mechanics thanks to it. I could instead spend my time figuring out instead how the heck to keep that ship on course !

The graphics and sound design was neat, coherent and well fit together. Maybe adding more FX & SFX when everything goes wrong could be nice to stress the player out even more !

A minor complaint is that only QWERTY keyboard is supported, which is a shame since it is quite easy to do in Godot by setting configuring the actions in the Input Map with "Physical Keycode" instead of "Keycode" or "Key label".


I sadly was not able to complete the game since I had a crash that made the game freeze while loading into a sector near the end. It seems to be related to audio as you can see in the log below:


In conclusion a great entry and a fun 15 mins, congrats !


EDIT: one question I have for you however is why so many loading screens ? Is loading the next area in the background with  

ResourceLoader.load_threaded_request

while in a sector in-between two area not good enough ? That could have made the gameplay even more tense without all the micro-pauses due to loadings.

Reply
FeralHarmony301 days ago (1 edit)

Wow, thank you for the valuable feedback, especially the comment about only having QWERTY support.  It's too easy to have tunnel-vision and forget such an important, but easily overlooked accessibility issue.  We will definitely carry that lesson forward with us for future projects and ALSO will include that fix after the jam when we provide an updated version.  Accessibility is critical.  Thank you for taking time to try our game and I'm glad that you enjoyed what you could.  

Reply
FeralBytes301 days ago

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.

Reply
FurAune301 days ago(+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 !

Reply
FeralBytes301 days ago (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.

Reply
FeralBytes286 days ago

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.

Reply
AboutFAQBlogContact us
Copyright © 2025 itch corp · Directory · Terms · Privacy · Cookies