My company is trying to evaluate the feasibility of using Unity for web game development. Currently, things aren’t looking good – even on very fast computers, there is a 5+ second load time for an empty Unity project. This is due to the huge amount of code bloat that is the Unity engine. Considering many of our Flash games (what we want to migrate from) take < 1 second to load, this is unacceptable.
So, I’ve been crossing my fingers for wasm support so that I’m not forced to figure out a different platform to make games in. I saw Mozilla’s announcement that they plan to release it in March 2017. Great news! I can wait that long.
To do my due diligence, though, I wanted to see how much things speed up when I export our test game in wasm. I couldn’t find an option to do this in the Unity editor (is there one?), but I did find your AngryBots demo online.
You quite handily give me an option to switch between a wasm version and an asm.js version. Awesome. I started running them and comparing the timing between the two. Here are my results:
Web Assembly
17.93 seconds in all for wasm
12.09 seconds for wasm to see Unity Personal Edition screen
5.28 seconds for wasm to go from UPE screen to gameplay
asm.js
7.61 seconds in all for asm.js version
So wasm is taking about 2.5x longer than asm.js. That’s a terrible sign… maybe that empty gray screen time period before seeing the Unity logo (12+ seconds) is a temporary thing? Because with asm.js you see the Unity logo immediately. That makes wasm slightly faster, but not much.
I just took a look at the demo the WebAssembly team put up, and I think that the main issue here is that the WASM demo they put up is not as optimized as the asm.js version they linked to (which I put up on Unity WebGL Player - AngryBots WebGL Demo).
In the wasm version, the wasm code itself is served uncompressed (When you will build wasm with Unity, it will always compress it for you).
In the wasm version, the web server is not configured to handle compression on the server side (so it needs to decompress everything in JS).
The wasm version is built with Unity Personal Addition, hence the delay for the splash screen
In the version I put up, I carefully adjusted all the textures to use crunch compression, thus reducing the data size of the build by half. In the wasm version they did not do that, resulting in a download size over twice as big.
So the real difference here is in downloading the files, due to how the build was made. Currently, wasm should start up faster then asm.js in the latest Firefox Nightly. In Chrome it is indeed slower atm, I hope that they can still improve that before release.
Okay, thanks, that makes sense. So will wasm help with that ~5 seconds of “compile” time where the browser is crunching all that JS code? Even with an empty project we’re looking at that long of a wait to play a Unity game.
Since we have 30+ games on our website and the user is expected to go between multiple games in a session, this load time adds up. Even if we could just load the main Unity code once and then only load our game code each time would make a big difference.
In Firefox, WASM will improve that time. In Chrome, it is currently slower - I hope that they will find ways to optimize that before release. I have not yet had a chance to test other browser’s implementations.
Roughly half for firefox still holds true for the current builds. But that is half of the complete time between the first JS on the main html being called, and the first line of Unity user code in the first scene being called, so not just code parsing (but testing on a local machine, so not including network downloading). But as I wrote, I don’t have numbers for other browsers just yet.