Timeline for ECS being 'ready'?

First off, I don't post a lot in this forum, I mostly lurk here and fiddle with the ECS on my own. In all of the discussions happening on this forum the fact that the ECS is 'not ready' or that you should 'wait a year or two', etc. is repeated a lot. Yes, the ECS is still in its infancy, I'm fully aware of this.

There's so much missing at the moment that it's pretty hard to use the ECS for a serious game, or even plan things like potential asset store assets around it. When a lot of these missing things are requested/asked about, people from the Unity team tend to say 'yes we want to do this', 'it's planned for the future', etc. That's great to know... but it'd be nice to actually have a roadmap, timeline, etc. Just something to go on.

Edit:

I mean the list of 'missing' stuff from the ECS is pretty long:

* Physics
* Animation
* Prefabs
* Scenes
* Audio
* Rendering
* Networking
* etc...

Basically everything except the 'core' loop is missing (and that is still heavily being worked on as far as I can tell). And then we've not even touched on things like a fully built collections library, fixes for dealing with the inability to keep reference types on non-shared components, etc...

 

Well there are already games using it: https://forum.unity.com/threads/unity-ecs-and-job-system-in-production.561229/
And asset store assets using it: https://forum.unity.com/threads/wip-vegetation-studio-professional.538451/

So it's ready now. Will it be improved forever? I'd expect so. I don't know about timelines. I just expect everything to just be worked on in due time. Curious to know if there will be a roadmap for it.

 

I was not trying to say you can not make anything with the ECS, but if you set out to build a big complex game today in pure ECS you'd run into pretty massive roadblocks. And without ANY form of roadmap... it's pretty hard to gauge when it's gonna be usable for the more general case of making a game.

If you compare what GO/MB can do vs. Pure ECS now (minus performance of course), it's pretty obvious a lot of stuff is lacking from the ECS.

 

I am aware, I'm just adding support for roadmap + extra information you may have missed as you mentioned you don't frequent the forums much.

I'd like a roadmap. My own use of ECS is built around "what data needs optimisations" instead of using it for the Unity regular OOP stuff that's missing. In this respect it can be used now very well. As for if I use it in other ways, well it looks like we will both have to wait.

Hope that Unite LA will reveal more information and unity staff post about it. I don't want to guess

 

Actually the really 'big complex games' using Unity I examined so far didn't use GameObjects or MonoBehaviours alot but build there own much more data oriented entity systems.

 

This is why there's "ECS Hybrid", it's pretty much the best of both world. I haven't had a single scenario in "Hybrid" so far where I had a brick wall in front of me. Sure if you want to go full "Pure" ECS you'll have some roadblocks, but nothing stops you from going hybrid and changing your systems (like physics) when Unity will release more systems compatible with Pure ECS. Depending on what you're making, a lot of your systems will run in a "Pure" ECS sense where you can use Jobs and Burst Compile them.

I would suggest you try ECS, there's a weird view going around the forums that because there isn't much out yet using ECS that it's borderline unusable. Eizenhorn is the perfect example of what you can achieve with ECS at such an early stage.

 

Not trying to derail here, apologies if so, but when using Hybrid ECS my understanding was that you don't get most of the ECS benefits.

Is it possible to use Hybrid, alongside some pure ECS systems?

 

ECS is not exclusive, you can use it alongside anything, so long as you are aware of how both sides can communicate. Hybrid communicates with everything, but it's really only for the ECS and not the performance aspect.

 

Ya if you approach it as what high level features are built on ECS, it doesn't look that appealing.

But I think most aren't going at it that way. Our approach is jobs/burst/native containers are an obvious win for a lot of things. ECS is another tool on top of those. Sometimes it's for performance, sometimes it's just certain features that make things easier. JobComponentSystem just for the dependency management of jobs is worth it. Jobs/containers are built around a flow with sync points, and the ECS command buffers support that nicely.

So if you are using jobs, then a lot of things just work better if you also use ECS at least some parts of it.

 

For me, hybrid is just a way I can start moving my codebase over until such a time Unity make more native ECS systems to replace the existing non ECS ones.

 

I understand the ability to create and work with entities from data or traditional components on Game objects. But how do you go the other way?

I guess, if you were to construct a pure ECS system utilizing jobs and burst, or what have you, and you use this system to end up with data that will say, provide a final position to move an object; how do you connect that entity to its owning game object to use that data?

It seems like if you want to do that, you need to use mostly ECS, and use its mesh renderer and transform system and things like that.

For instance, as a simple example, could I make a component that attaches to a game object (Gameobjectentity) that creates an entity storing the objects position, and a system that uses these entities alongside another component that requests the entity move .The system then tries to move these entities based on if the position is taken or free.

In this scenario, once the "hybrid" entity knows its final position, how would you apply that data to the game object? And could the system itself that does the calculations be jobsystem/burst compatible to be very fast with tons of entities?

 

Anything MonoBehaviour related, like applying a force on a rigidbody, can be done on the main thread in a System assuming the GO has the GameObjectEntity component attached to it. You don't really get performance benefit but that's where the hybrid part comes in as far as I understand it.

So using your example, once you know the final position of a GO you could apply it directly to the Position component of the GO-Entity and as long as the GO has the Position Wrapper and the CopyTransformToGameObject wrapper attached to the GO.

But really you can just inject any MonoBehaviour in a system.

 

As far as I understood it: yes, you could have an ECS system set up that does not deal with GameObjects at all (alongside a bunch of GameObjects) and you'd get the performance benefits for that system.

 

Here's what I personally do :
ECS :
Procedurally generate stuff in parallel with a chain of CompoentSystem / JobComponentSystem until ready to render, completely working with my own pure data components.

Monobehaviour :
The last system, on main thread, builds the final meshes and assigns those meshes to a gameobject "renderer", from a pool. The pool is a gameobject too.

So pure ECS is doing all the data crunching, noise generation, splitting and merging nodes, this kind of stuff, and the gameobject is just a renderer.

That works great (and fast), and I would not have been able to code that in a safe way without the ECS cause I had 0 multithread coding experience - more importantly I would not have been able to debug it