Ask HN: Is it possible to use Unity on the web in 2018?
4 comments
A few comments (Disclaimer: I work at Unity):
-As others said, with Unity, you get a full game engine cross compiled to JavaScript/WASM, which has more overhead then simply rendering an image by other means (like img tag).
-We don't officially support mobiles for the Unity WebGL build target, because we believe that the platform (browsers and hardware) is not yet ready for this use case (running a full game engine compiled to the web) yet. That said, you might get better results with simpler engines which do support mobiles.
-WASM support on iOS is currently broken, so this probably would not work regardless of engine used: https://bugs.webkit.org/show_bug.cgi?id=181781#c4
(Try making a JavaScript release build instead)
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?
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?
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.
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.
> 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?
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?
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.)
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.)
WebGL has its share of issues but Unity's WebGL support is probably not great either. I have successfully implemented complex WebGL-based applications with https://www.blend4web.com/en/
Other WebGL solutions like https://playcanvas.com/ and https://www.soft8soft.com/ seem to be promising, as well.
TL;DR: To deploy on mobile, you should compile your Unity project as an app.
Per the manual: "Mobile devices are not supported by Unity WebGL." (https://docs.unity3d.com/Manual/webgl-gettingstarted.html)
You're not just rendering a picture, you're running a full-fledged high-end game engine, in JavaScript (meaning a ~50% slowdown), and using that to render a picture. It is to be expected that even high-end phones will struggle with that.
Unity WebGL is intended to be used as a frictionless way of distributing games to desktop users (think sites like Kongregate). On mobile, the respective app stores arguably already provides a similarly frictionless distribution option... so just build your project as an app.
Alternatively, you can look into lightweight engines that specifically target WebGL. These will usually run just fine on mobile, though they obviously don't offer the same feature set as Unity.
Per the manual: "Mobile devices are not supported by Unity WebGL." (https://docs.unity3d.com/Manual/webgl-gettingstarted.html)
You're not just rendering a picture, you're running a full-fledged high-end game engine, in JavaScript (meaning a ~50% slowdown), and using that to render a picture. It is to be expected that even high-end phones will struggle with that.
Unity WebGL is intended to be used as a frictionless way of distributing games to desktop users (think sites like Kongregate). On mobile, the respective app stores arguably already provides a similarly frictionless distribution option... so just build your project as an app.
Alternatively, you can look into lightweight engines that specifically target WebGL. These will usually run just fine on mobile, though they obviously don't offer the same feature set as Unity.
Sorry, it seemed from my comment that we care about mobile, but we'd be happy if this worked on the desktop.
I'm wondering if we can optimize the full-fledged high-end game engine so that some components that are not used are not loaded.
I'm wondering if we can optimize the full-fledged high-end game engine so that some components that are not used are not loaded.
if you used a "WebGL 1st" engine it would probably work. Unity is "compiling" it's project for WebGl so that's one big process that can easily break.
Yes we don't understand. We're also exporting with WebAssemly support instead of AMS. The thing loads fine, then gets stuck: http://countryfortress.com/LamaExampleWebAssembly/.
By "webgl-first" you mean three.js or D3? We use Unity for iOS and Android, and we were looking to use a single tool for everything (if possible, of course). Is there any way to turn a simple Unity project into something that won't bring the browser to its knees?
By "webgl-first" you mean three.js or D3? We use Unity for iOS and Android, and we were looking to use a single tool for everything (if possible, of course). Is there any way to turn a simple Unity project into something that won't bring the browser to its knees?
We are testing with a 2D picure of a lama. Why would it get stuck?
I can't stop myself from thinking that WebGL is being purposily boycotted by Apple and Google, because I have a powerful phone that does very complicated and CPU-intensive stuff and I can't believe it struggles with a picture.
This is the URL: http://countryfortress.com/LamaExampleWebAssembly/