[nkkollaw]

Well, first of all it's so awesome to get a reply from someone who actually works there! :-)

I understand what you're saying. Of course, we're aware of the overhead compared to just including an image with a HTML tag, it was just a test to see if we could make the thing work with the minimum amount of complexity possible.

For us, it's not important to support mobile browsers: the latest desktop browsers would suffice. However, we can't build for the web without a 10-second delay before the image is shown.

What we're looking to achieve is to use Unity for native games as well as very simple animations for the web (a 2D landscape with parallax, at the moment), so that we have only 1 editor, and 1 technology to learn.

I'm also not the person who will actually build the product, I'm just helping out with research and I'm not extremely familiar with WASM and similar. What is a JavaScript release build? Is that a way of exporting the project that would allow us to eliminate that 10-second delay?

[Kiwikwi]

FWIW, I don't see a 10 second delay. I see a delay of roughly 2.5 seconds (Firefox; Chrome is a bit slower), followed by a Unity splash screen (which you can disable once you buy a license). But the delay obviously depends on the speed of the user's machine and network.

The startup overhead is mostly downloading and parsing of the JavaScript. (WebAssembly basically reduces both by being more compact and easier to parse, but it requires browser support.)

Be sure to read the WebGL section of the manual thoroughly, as it contains several tips on reducing this overhead. Also, the overhead varies a lot depending on the browser, so be sure to test all the major ones (Edge, Chrome, Firefox, Safari).

A classic pitfall is to have collider on some of your game objects, even though the game isn't physics driven. This forces Unity to include the entire physics system in the build.

Even if some systems, like physics, can be removed if not used, Unity is still a full-blown 3D game engine. It can of course also do 2D, but it'll almost inevitably have a higher overhead than a dedicated 2D WebGL engine.

You can also consider showing your own loading screen before/on top of the Unity WebGL player, which can camouflage the load time.

[nkkollaw]

> FWIW, I don't see a 10 second delay. I see a delay of roughly 2.5 seconds (Firefox; Chrome is a bit slower), followed by a Unity splash screen (which you can disable once you buy a license). But the delay obviously depends on the speed of the user's machine and network.

I don't know if it's barely downloading. Looking at the Dev tools, it looks like it downloads assets, then takes a good while to parse them.

> Even if some systems, like physics, can be removed if not used, Unity is still a full-blown 3D game engine. It can of course also do 2D, but it'll almost inevitably have a higher overhead than a dedicated 2D WebGL engine.

So, there's no way to not "load" the 3D component or other components besides physics, or is there?

[Kiwikwi]

Unity will automatically exclude the things that can be excluded. See "Strip Engine Code" at https://docs.unity3d.com/Manual/webgl-building.html

This only goes so far. E.g. Unity doesn't have a separate 2D renderer, so your 2D game will use the 3D renderer. (But obviously, a 2D game won't include any 3D materials etc.)