Is there a list of Unity features that do not work in ECS yet?

I just think it would be handy to have a list of Unity features not yet in ECS that the community could maybe write solutions or work arounds for.

It could also work like an ECS roadmap giving developers an idea of what is in the works or already in the latest version.

 

I would say "everything" pretty much, as ECS will need it's own versions of things. Think your post is about a year early

 

I agree, the Job System is used in some things by now, but ECS is still its own thing. We have the core system and we can build around and that's pretty much it.

 

Like @hippocoder said, pretty much 'everything' doesnt work with ECS. More specifically, everything that was in some way related to gameobjects, (old) components and monobehaviours. That means:

• Physics
• Animation (both mecanim and playables)
• Skinned meshes
• UI
• Prefabs
• Particle systems
• Terrain system
• Timeline
• UNET HLAPI and all other asset store networking solutions
• etc...

APIs that didn't rely on any specific monobehaviour types like the UNET LLAPI, navmesh LLAPI, and the Graphics.DrawX stuff should still be mostly fine (i think), but they might need more direct support for native containers and new math types to avoid unneccessary conversions

Don't let this discourage you, though. The ECS is one of the best things to ever happen to Unity, in my opinion. It'll allow us to rebuild a much superior engine based on all the knowledge of what went wrong and what went right that Unity has accumulated over the years, but could never put in practice because the changes would've broken too many things

 

For me, it's intriguing and a great time to be a Unity developer. ECS is a big part of my plans

 

You spoke my mind.

 

You might be confused about ECS and threaded Jobs? Currently pretty much everything works in ECS (as in working in the system (S) and being able to be represented as a component (C) and therefore lives on the entity (E)) because the existence of ComponentArray so you can inject and use every existing MonoBehaviour in ComponentSystem. (Even GameObject injection is internally ComponentArray<Transform>)

But in jobs pretty much everything does not work. It is rather a threading problem than ECS. Things that works in jobs is currently Transform which you have TransformAccess/Array.

And then we have a semi-threaded approach like calculating things in jobs with NativeArray and after it is done use that directly as an input for Unity's function, so we don't have to copying data. I think is coming soon for Graphics.DrawMesh/Instanced.

 

Well I've been trying a lot of ECS solutions in the past, but I never really found one I liked. On top of it the Unity implementation is super optimized and made to work with multithreaded Jobs. It'll probably also be super convenient for multiplayer and other types of data streaming. I'm actually looking forward to their Multiplayer FPS example with pure ECS.

 

Studying how the team will implement the netcode for an fps game will be pretty interesting. as all networking archetypes have their own flair when it comes to handling them.

 

For me the data sync approach is always one of the most interesting part of any networked game. For the ECS where the state of an object is defined by pure component data this should feel really natural. Also interested in how they are going to do lag compensation / prediction / extrapolation etc.

 

For the networking, the current implementation of ECS is a piece of cake. All data live in structs and structs lives in chunks of linear memory. You just need to copy from the memory and send over the wire this. You can already do it without much effort, just using serialization features (which are'nt complete yet).

What I'm looking for is if Unity team will stick with some protobuf, if they will extend UNET LLAPI to work with ECS out of the box or if they are going for a different approach.