Every time I attempted to make a web game using ECS, I landed on crashes at runtime.
What’s missing for us to be able to build a game for WEB using unity ECS, Jobs and Burst ?
Is the issue the rendering ? will WebGPU help ?
Is it burst ?
Is it due to multithreading not being natively supported on all web browsers ?
Are there any ETA on when those missing piece would become available ?
Is there a work around like (disabeling burst and/or jobs, use the non hybrid renderer) to at least be able to make a functional demo even if it’s not full perf ?
Entities has had some on/off issues with web builds, probably because it isn’t nearly as well exercised as for other platforms. In principle it’s supposed to work, albeit with little to no benefit due to it running only singlethreaded, non-bursted code.
No. Work is ongoing. In large parts it really depends on browser / webassembly supporting all required technical features from what I understand, so parts of it is not in Unity’s hands.
You can scrape some more info here and there in some long-running threads but … that’s the gist of it.
Sure. For one, use the latest Unity 6, this should build fine again with subscenes (there was a serialization issue and I believe it got fixed in 20f1).
If you make a simple test with a subscene and a boilerplate system, not using any Jobs or Burst features or any assets initially (other than built-in primitives), you should be able to build and run it. If even the minimal test doesn’t build and run, try a non-DOTS project first to see if you have any general build issues.
Then you can start adding to it but you will need to frequently build and test on the web (this is generally true for web dev as it is such a finicky platform of platforms on platforms).
Make sure you test on Chrome and Firefox at a minimum. And consider the general platform limitations. Devs sometimes have issues because they use the regular “quality” URP renderer, not the one for mobile with tuned down quality.
Personally I wouldn’t recommend Web-DOTS at this point unless you like to work with what I would call an experimental feature.
There are a number of components to ECS that all have issues with the web.
Burst/Jobs: no multithreading on web, so performance will be significantly less than other platforms.
Subscene Loading: they tend to have trouble with the web because the web has its own file system management (there are no local files), and changes are often made without testing on the web. I’ll make sure this gets looked into if it’s currently broken.
Graphics: the entity renderer makes use of compute shaders, so this will only potentially work with WebGPU (though work on it for WebGPU has not been started).
It is definitely a goal to get ECS working with web, at least in some form, even if limited to WebGPU and the performance isn’t as good as other platforms. But we are not there yet. For graphics, WebGPU is in active development, entity graphics will be looked at with that. There continues to be research into C# multithreading, which will be a huge win for the web but has some very difficult challenges.
Any chance Unity can poke Google or other authorities to push multithreading on web? Feels like this is currently the bottleneck in implementing more advanced features.
WASM does support multithreading, and Unity can do native C/C++ multithreading with it. The issue is with C# garbage collection with multithreading, which doesn’t work because of WASM security policies. It is an active area of research involving Google, and I will be the first to throw a party when it gets figured out.
Project Tiny is no longer in development and there are no plans on bringing it back. For the record, Project Tiny did not solve the C# multithreading problem. It did allow for very small builds by only supporting a limited set of features, but C# multithreading was not part of it. There are some other efforts going on to help with the build size issue, including the WASM stripping tool that’s being developed and should ship soon. And C# and/or Burst multithreading will come at some point, it is a very important performance tool.
Could Unity make progress even with some constraints re GC? It seems as though everything re Burst and WASM is on hold until everything is aligned. The C# engine already has several different GC options with tradeoffs - perhaps this could also work here.
The concern is that waiting is that new issues will be discovered on the web platform that will then cause more reworking in other areas. Perhaps its better to publish Burst/Threads to WASM as experimental (eg - short hangs with synchronised GC, or we run in sandbox with relaxed security policy), and then find what else breaks on ECS, WebGPU, WASM so it gets into the fix pipeline etc.
Use Unity 2023.2.20f1 (the last vesion supported ECS for web as far as i know)
Instead of graphics package use Graphics.RenderMeshXXX API
And you will be good
I know that the official stance is that the job system and C# multithreading doesn’t work on Web, but if you enable C++ multithtreading and use the Job System only to compile jobs that would be Burst-compiled on any other platforms multithreading absolutely does work(*), the performance gains are amazing and we’re using it on Web.
Our working assumption is that this is because the core of the Job Manager is C++ anyway, and HPC# code that can be Burst-compiled has no significant interaction with the GC, added to the fact that on Web the GC can only run at the end of the frame anyway. Note also that you must have exception call stacks disabled for this to work or you will die when il2cpp allocates strings for the exception call stack on a job thread.
Note that the official stance is that you can’t do this, and I can understand why that would be the official stance given the number of ways “full C#” multithreading doesn’t work because of the GC. Although I haven’t heard any official statement that there’s a problem apart from the GC.
(Also please note that we use Burst (on other platforms) and the Job System extensively, but NOT actual ECS, so ymmv.)
(*) “Works” is defined as “we haven’t yet been able to trace any crashes to it, and thus it is no less stable than any of the other part of the giant-tech-stach-of-layers-of-abstracted-nonsense-on-top-of-nonsense that a modern web browser is.” Some of this last comment may be driven by spending last Friday tracing all the way up through levelDB, indexedDB, emscripten and IDBFS, attempting to understand why modern browsers have built a filesystem that is marginally worse at dealing with large files than AmigaOS was.
