Optimising File Size & Render Performance

The telemetry was indicating that a lot of players were churning out before they got to the game itself, so there was some optimisation that needed to occur across a few areas:

• A more obvious 'Join' button (changed it to animate)
• Make it more obvious what the game looked like before the player joined (added an 'Attract Mode' to the main menu)
• Tweaking of the text on the main screen to make it clearer what the bots checkbox did
• New layout to tidy up the front menu
• Improved download time by ~40%
• Improved runtime performance and removed a lot of of visual artefacts in-game

Attract Mode & File Size

It was fairly clear that because I had suppressed a loading bar, that the time from clicking play within itch.io to the time of the main menu appearing needed some work. After stripping a lot of unused art assets out, I also did a lot of texture evaluation to see the size of the resulting texel density on screen.

Not surprisingly, a lot of the 2048x2048 textures are absolutely identical (because it's a top-down game) at 256x256 or 512x512. So, this was a sizeable portion of the file size.

In fact, I managed to save so much space doing this that I was able to inject another 500kb for some main menu music, to help draw attention to the screen (remember, the game runs in a web browser, it is competing for attention with the rest of the user's desktop).

Visual Artefacting

There was a shader issue due to webgl being a headache, so I had to quickly refactor the dynamic objects shader. While this technically makes it no longer a pixel shader (so it renders really fast but the lighting is now vertex based), given the temporary art the game has right now, this was a fair trade.

I had also used an ambient occlusion baking solution to help ground a lot of the temporary map art together, giving it a bit more of a gritty aesthetic. While this did impact the look of the game in a way that made it 'more gritty', it did require a lot of textures. I had batched them all into 4x maps per texture (splitting rgba for efficiency), but moving parts of the map etc would require extensive rebaking.

It was easiest to just kill that, and instead utilise realtime shadows again. Although I previously had realtime shadows on, the game used to be lit exclusively via the torches on the weapons (giving it a more horror aesthetic). Since, again, temporary art is in use - it was time to utilise a blurry low quality main-light shadow solution. The game was not really hurting the render thread anyway, so this seemed like a solid trade.

Also, realtime shadows don't hit download size. Light maps do.

While I'm awaiting sufficient player throughput to validate the top of funnel  telemetry, it is (in general) never a bad time to optimise file size and to decrease the time it takes the user to get into a play session.