I spent the last couple of days looking at the new ECS introduced by Unity. In general I don’t think its anything new, and they were already using Component based architecture. I think the biggest architecture change is that they are shifting where you put your Update call. Another change that that they are introducing is that they are replacing GameObject and Component with something that is super light weight (as struct).
TL;DR; They are taking the property of GameObject/Component and moving it into Entity/ComponentData, and moving all logic into System with fancy selector to run logic on ComponentData.
Before you keep reading. I am in no way a Unity expert and might not line up with what you think.
- Entity/ComponentData is light weight and easier to make thread safe.
- Seems to make Batch processing much simpler.
- Not bound by OO inheritance limitation.
- Not immediately obvious what Entity is representing. Specially when you are reading other peoples code.
- Hard to tell which logic is going to run. I had to look at each System one by one and create a map.
Disadvantage can be solved by having a good dock, but who wants to write more doc? Component comes and goes in an entity system, so I’m not sure if there is any easy way to represent this.
The technology works from a library perspective but so much is missing in terms of Unity integration. You can go with the hybrid approach and call it integrated, but then you are only using S part of the new ECS.
I’ll be playing around with ECS+JobSystem for the next few days to see what kind of performance I can pull out of this thing. I’m going through some unity courses on Udemy so I’ll probably try modifying the content of those to use ECS.