Skip to content

Resting, Regrouping, and Recompiling

I took Monday off to decompress. I had pushed out the changes for the Glimmerstalker and was feeling a bit burnt out on everything. Instead of working on the game, I took the evening to play some games and relax. It was very nice! It was back at it again on Tuesday though with a team call to regroup then onto trying to make a web build.

The Team Call

It had been a while since we actually had a call with everyone on it. Normally, we just chat and update via Discord but it is nicer/easier sometimes to just talk. The main focus of the call was to make sure we are all on the same page and to regroup since the bulk of the systems were now in place.

Here is a quick overview of some of the things we talked about (I'm writing this a couple of days later so I'm sure I am missing some things)

Icons

We needed to lock down what icon style we were going to go with. We have been running with some pretty terrible placeholder icons for quite a while and the last attempt we made was before the Atmosphereâ„¢ was put in, so they didn't quite match.

Andrew threw out some initial ideas, based in a similar style to the spell energy/soulstone UI he made. He went with (or I pushed him into...unclear) a more sketchy look, as it seemed to fit better with the overall aesthetic. Below is one of the earlier iterations. I think the new one looks much better.

Image showing one of the original designs for the new spell energy UI and the final one we settled on

Anyway, in keeping with the more white-lined sketch motif, Andrew presented some potential ideas for the Warmth spell. We all seemed to like the center icon the best, at least the fire part of it.

Image with a variety of flame designs for the Warmth spell icon

So, Andrew cleaned it up and it is looking pretty snazzy!

Image of the new flame design for the Warmth spell

Here it is in game, along with some others he made up in the same style.

Screenshot of all the new spell icons in game

They are all looking really good!

Soulstone

The soulstone is the crystal that the magic user stores energy in and casts from. We had a placeholder in there of a raw chunk of crystal but we always wanted it to be more refined. The characters in the world would want to make their primary fuel source more functional and/or prettier than just a jagged piece of rock.

Andrew was playing around with some different shapes and we all liked this one the best. Obviously it doesn't have the actual soulstone in the middle yet but the shape is neat.

Screenshot of the new, work-in-progress clasp for the soulstone

Web build

We decided we should probably figure out what it would take to publish our game as a web build. Better to do it now so we can pivot if needed, rather than finding problems the day before we go to submit it. I'll discuss this more later.

Tuning

Now that we had (almost) all of the big systems in, we really needed to start actually tuning the game to be more representative of how we expect the final game to play. We talked about several strategies for tuning, like each taking a stab at it then comparing, but we decided to just have another call on Sunday where we take turns playing the game and seeing what needs to be adjusted. The first person to play will probably have the most work, since they'll be establishing a baseline for the rest of the tuning.

Snow manager

I was able to wrap up a bug we found with the Snow Manager. Somewhere along the line it stopped spawning snow, which meant certain death on the trail. I discovered that this was due to the terrain and was the same problem I talked about previously where the Crew and Glimmerstalker would periodically move to the world origin. I fixed that bug and reworked the overall structure to be cleaner and (hopefully) more reliable.

Web Build

The next thing I tackled was trying to get our game built as a web-based game. We knew Unity supported publishing a WebGL build but we did not know what that actually entailed. So, following this tutorial by Max O'Didily I was able to successfully create a web build. Woohoo!

I thought everything was fine. The build succeeded and it uploaded to Itch without errors. However, when I actually went to preview the Itch page the game failed to load.

Screenshot of the file too large error message on Itch

I thought this was weird because on the upload page it said the max file size was 1GB and our game was only ~550MB (yeah, we'll get to that in a few...), so why did it say that the file size was too big? After some digging around on the internet, I saw a passing comment that there was a limit on how big a single file inside the zip could be. This led to me rooting around in the build files to see what might be a likely culprit.

It was pretty easy to find. The Web.data.unityweb file was 501MB, the bulk of the game size. I still didn't know why it was "too big". More digging online and I found the Itch documentation for zip files.

Screenshot of the zip file requirements from the Itch documentation

The important line in there is:

The size any single extracted file should not be greater than 200MB

Welp, that file was definitely larger than 200MB. Now, to figure out what is driving up the file size. Through some very cryptic Unity forum posts, I was able to find that the Unity Editor Log contains a "build report" for each build and it breaks down the assets that were included in the build. It also has a nice summary by type at the beginning. The log can be accessed by clicking the three dots if the top-right of the Unity console and selecting "Open Editor Log".

Screenshot of where to find the editor logs in Unity

In the log, you can search for build report until you find the one you are looking for. It will have all of the past builds as well, until the log is cleared (I don't know if it cleans itself up or not). When I found my build, it showed a whopping 719MB just for textures, which it was able to compress down to ~500MB, That is bonkers.

Screenshot of the initial build report with excessive texture sizes

Scrolling down from the summary, it shows all of the assets, using the file size as the order. I found that the textures from some rocks from an asset pack was accounting for a massive chunk of the size. These were tiny rocks just dotted about for visual flair. We decided to try removing the rocks and rebuilding and that cut the build size in half. Crazy that just a few assets could affect that much!

Screenshot of the reduced build report after removing asset pack rocks

This got us close to the 200MB file limit but still not quite there. We still have to add in music/SFX, icons, and some VFX, so I don't know if we'll be able to crunch it down enough to get a web build out. I think if we did, the main problem will probably be the assets from the asset packs (like the buildings and trees). Those might be more difficult to reduce the size of, compared to our custom textures. Almost all of our custom textures in Substance Painter, so we can easily export them at a lower resolution. We may end up quickly modeling replacements for the asset pack stuff just to have more control over the sizing of things. Now we know more what to look for!

For now, we will just move forward with a downloadable build and once we get the game tuned and the missing pieces added, we can take another pass at optimization. We'll definitely have to sacrifice some quality if we want to support the web build, which is fine because the game is pretty dark most of the time, so higher fidelity textures are less useful any way. We would also really, really like to have a web build. It gives better visibility in the jam and means it will be more likely to be rated.