Polish

We’re getting really close to finishing this thing - the only remaining tasks are to make and implement the cutscenes, add the odd asset, comb through the text to ensure consistency and tone, and, of course, to name the game.

While Sara’s working on cutscenes, I’m trying to do some optimization to make the game load more smoothly, especially on mobile. Before tonight, loading on mobile took what felt like forever, including about 5 seconds where the screen was just blank. That feels bad.

My assumption was that the issue is the immediate loading of all rooms when the master controller is ready. That’s a blocking operation, and loading all four rooms at once like that is bound to be slow. But before I started in on that, I looked for lower-hanging fruit.

While I don’t have a good measure of load times at this stage, I am using exported and packaged file size as a proxy. When I started, the zipped game was 13969895 bytes (~13.3MB).

First off, I went through the whole project and removed unused assets. Super simple, super easy win - I removed ~813KB from the packaged file with no change at all to the resulting program.

Next, I read Godot’s docs on audio files, as I noticed that the sound effects were well within the top 20 largest files (as revealed by ls -laS */*/* | head -20). Turns out, Godot offers the ability to compress and flatten files on import, making a signifant different for the wav files I’m using for sound effects. Cutting out the stero channel and using Godot’s compression removed another ~740KB from the packaged game. Great!

A little more looking at the largest files in the game (this time excluding audio files with a | grep -v audio chained in the middle of the above command) revealed that the three files related to the backpack in the living room were unexpectled large - every other image asset except the background/cutscenes were under 100k bytes. Upon inspection, it turns out those image files were huge, and were being scaled by a factor of ~.126 in-engine to get them to fit in the room. I copied the scaling factor for all three into GIMP and exported the downsized images, and another ~962KB were saved. Excellent!

Finally, to address the initial loading time - Godot’s docs suggested using preload instead of load for static resources to load them with the scene. Since all four rooms need to be loaded when the game starts, this seemed sane to me - no reason to load one scene, then load four more immediately. Doing this actually increased the size of the exported game slightly (~1.7KB), but it loaded noticably faster being served from my desktop to my phone.

So, overall, I shaved off ~18% of the final file size. But how did it perform? Before uploading the game to itch, I grabbed a profile of the current build loading on my desktop, paying special attention to the time taken by the function call that starts the game (and the time between the loading spinner and the first room actually appearing). My inital sample was 1.78s of black screen while the game started itself. I then uploaded the new build and tried it, with an encounraging 1.14s as the result. That’s a 35% reduction in blank screen time!

But of course that’s not good enough.

Next I’m going to experiment with Godot’s threaded loading example found here. With any luck, I can use the intro cutscenes to hide the background loading, and have all the rooms ready to go before you even see the bedroom. In that case, the initial blocking load need only be the cutscenes themselves, and they should be comparitively small (and fast) when measured against what we’re doing now, which is loading the entire game up front.