After making my first game, the only thing I focused on was publishing it on itch.io and calling it a day. However, one barrier that I didn't acknowledge at the time was the sluggish nature of some gamers. Let me explain.
When heading to the itch.io page, not many people want to go ahead and download an actual game. It has become a sort of unmentioned bad impression on playtesters if your game is not HTML5 compatible.
Well today, before publishing to itch.io, I came across an issue building my WebGL project and thought to review some of the common problems that occur when publishing your WebGL build.
Table of Contents
- The Difference Between WebGL Build vs. Windows Build
- Unity's Build Settings
- Web Browser Features
- Further Resources & Settings
The Difference Between WebGL Build vs. Windows Build
From my knowledge, the WebGL platform is the way for your game to be cross-platform and playable without needing to go the extra mile of downloading the game. The game is embedded within the web browser, so you can play your game right on your web server! There are many hurdles of figuring out if your game is formatted the correct way during game development, and WebGL is a platform to render your game the same way across all platforms.
In more professional terms, WebGL is a JavaScript API used to render any 3D or 2D game without download right on your web browser. The JavaScript code and shader code is oftentimes pre-written within the engine you use. In my case, I will be focusing more on how Unity WebGL works and some small fixes that I made which makes it easier for you to test your own WebGL build.
Unity's Build Settings
Texture Compression: the range of techniques for reducing the memory output of your textures by removing excess and removable data.
If you head to File > Build Settings > Player Settings, you will find the field of settings that mainly handles texture compression format for your WebGL build. Should you come across an error I found when running my game, this section will be very helpful.
Texture compression in WebGL is the way to create builds for several platforms while keeping the texture compression that the devices can support in mind. Since each desktop and mobile device will have different texture compression formats, there can be a conflict. However, we want to use compressed textures on all platforms, so we need to support each device's supported texture compression format. Therefore, to run on all devices and their compressed textures, we must target a Compression Format which is most appropriate.
Compression Format: Determines how Unity compresses files during the build step.
Unity by default sets their Compression Format to "gzip." This is due to Gzip files being faster to build and natively supported by all browsers over HTTP and HTTPS. However, Gzip files are comparatively bigger than Brotli files, which is the next Compression method you can use.
Brotli compression offers the best compression ratios and smaller compressed files compared to its alternative gzip. However, the build times are often longer to compress, which increases wait times when releasing your final build.
Lastly, you can choose neither. Having Disabled compression is targeted for developers who are building their own compression through scripts. This option is not recommended if you are not using static compression on your server and typically is the cause for errors and long waiting times for build downloads.
Texture compression is necessary due to the limited amount of space, memory, and time that each of our devices have. Since textures take such large binary files that impact game performance, we want to limit this as much as possible and this is where compression comes in.
Decompression Fallback: Determines how Unity processes downloaded files when the build runs in the browser.
This option in Player Settings > Publishing Settings enables Unity to automatically embed your JavaScript decompressor into the build. The decompressor coincides with the compression method that you decide from before. Otherwise, the decompressor decompresses the content automatically if the browser doesn't.
If enabled, Unity adds the .unityweb extension to your build files. This is helpful if you don't know much about server configuration or if it is unavailable. Despite this, enabling this feature causes a larger loader size and is less efficient.
This is why Unity typically leaves this feature disabled by default. Due to this, your build files will include an extension corresponding to your compression method.
Web Browser Features
Sometimes when playing your game on your web browser, frame rates can be incomparably slow to your Game View playthrough. One reason can of course be due to any game feature you have taking a long time to process. Any issue related to game features can be viewed from your Profiler window within Unity.
However, another fix can be going to your web browser's settings. If you go to your system settings, you may find a feature called "Use hardware acceleration when available." This feature allows any application to have hardware performing tasks more efficiently than exclusively through your CPU. This exchanges your tasks that are handled in your CPU to other areas such as GPUs, DSPs, and sound cards.
From this feature, game performance becomes more smooth. However, if slow performance, freezing, or crashing persists, you should keep it disabled.
That is essentially the main features to look for when building games in Unity. It can be daunting, but I hope this helps in some way for Unity developers building a WebGL game. Thanks for reading!
Further Resources & References
- Unity WebGL Documentation
- Texture Compression in WebGL
- An Introduction to Texture Compression in Unity
- Hardware Acceleration
- Some further configuration you can implement is within your own web browser. In order for browsers to decompress any Unity build file when downloading, you must alter your web server to serve the compressed files within the targeted HTTP headers. In other words, this process is called native browser decompression. Since it is faster than any JavaScript decompression fallback, this is oftentimes a more effective way of reducing your application's startup time. Since the process is very complex, I will leave the link here for further reading.
Top comments (1)
Agreed 😃 Not only making things easier when your game has web build, it would also solve the security risk from running random .exe from the internet, many people are wary of running executables from developers they aren't familiar with.