This is where the unfortunately-chosen name "Entity-Component-Systems" (ECS) comes back to bite us. Unity's GameObjects are Entity-Component (EC): you have an Entity (GameObject), onto which you attach Components (MonoBehavior). Unreal is similar: you have an Entity (UActor), onto which you attach Components (UActorComponent), though you can also have plenty of code living outside the UActorComponent system in Unreal. Entities are objects, and Components are code/data.
Entity-Compontity-System (ECS) uses these nouns differently; an Entity ends up being little more than an identifier for a large number of Components, which are data structures, and Systems are the code that modify groups of Components. "System" here is a noun, not a descriptor of the practice. The usual analogy is similar to a relational database (in fact, the point of the system is to achieve wide-scale performance like RDSes do): Entities are rows, identified by a primary key, Components are columns, and Systems are the SELECT/INSERT/UPDATE/DELETE queries which acts on the data.
Unity has a new-ish ECS framework under the DOTS initiative; Unreal has no parallel. Very few games are using these.
In unity the methods "Update", "Start" and so on are the system part of ECS. That you write their implementations alongside the data doesn't really matter.
ECS has come to mean a very particular style of architecture. It's not a great name, but it's what the industry has converged on. Naming things is hard.
Unity's MonoBehavior framework uses GameObjects and Components. You don't have to squint hard to see that it contains Entities, Components, and arguably Systems. However ECS has come to mean an architecture that is quite different from MonoBehavior. So different infact that Unity is writing an ECS framework called DOTS!
Both DOTS and MonoBehaviors containing entities, components, and functions that operate on them. However the two Unity systems are extremely different. MonoBehaviors are not an ECS.
ECS is fundamentally about having id references and components being attached to entities via such references instead of pointers or inheritance or other clunkier systems. This lets you write systems that can query components and entities. Both Unity and Unreal uses this architecture for their standard workflows.
Then some people started talking about a single implementation style of ECS as if that was all ECS is, Unity DOTS is an example of that, but the base Unity is still ECS at its core.
Strong disagree. I suspect the number of people in the world who agree with your definition is vanishingly small.
Unreal's framework is a mix of inheritance and components. It's clunky AF. AActor I'm looking at you!
Neither Unreal nor Unity provide a mechanism to cleanly query such as "give me all gameobjects in the world contain this set of components". And they definitely don't provide a mechanism to perform that query quickly.
Unity will let you search from components within a GameObject, in children, or in scene. These queries are also slow as fuck and should generally be avoided.
The type of code you write in Unity and in a Bevy-style ECS is quite different. I think ECS is overrated in some ways as it's actually pretty difficult and non-obvious how to accomplish a lot of tasks.
I don't love the name ECS. It's just not a great name. However I've come to terms with it. ECS has colloquially come to mean something that is extremely distinct from MonoBehaviors. You're welcome to keep fighting the community accepted definition if you want. I don't think it's useful or helpful to do so.
No, ECS is a relatively new term. It wasn't used 15 or even 10 years ago. Unity never once used ECS to refer to their MonoBehavior framework.
"Component Systems" were popularized ~20 years ago. I'd consider Unity MonoBehaviors a typical Component implementation. Scott Bilas's 2002 GDC presentation "A Data-Driven Game Object System" helped evangelize the idea.
ECS is a new term that implies a handful of implementation details. The name is somewhat confusing, but it's not redefining a previously popular term.
I believe the first time ECS made an appearance at GDC was Blizzard's stellar 2017 talk "Overwatch Gameplay Architecture and Netcode". The term went mainstream in the years after this.
I'm only a hobbyist game dev, but I've always understood EC separately from ECS.
EC was the answer to God objects and deep, inflexible inheritance hierarchies.
Among other things, ECS is partially a performance play - it's more cache friendly. I'm not sure what all the tradeoffs are though, I've only really used EC.
The major difference between a true ECS paradigm and MonoBehaviours (EC minus S) is that Systems aren’t local, ie you can select and aggregate various entities and change their states based on the results of your aggregations.
A proper system, for example, would be able to add a new enemy entity every 5 seconds and switch the flag that the level is cleared once the total count of present enemies is 0. In fact, it would be quite trivial to implement it. But in Unity you would need some sort of an architectural solution to bypass inherent limitations of EC-S.
Entity-Compontity-System (ECS) uses these nouns differently; an Entity ends up being little more than an identifier for a large number of Components, which are data structures, and Systems are the code that modify groups of Components. "System" here is a noun, not a descriptor of the practice. The usual analogy is similar to a relational database (in fact, the point of the system is to achieve wide-scale performance like RDSes do): Entities are rows, identified by a primary key, Components are columns, and Systems are the SELECT/INSERT/UPDATE/DELETE queries which acts on the data.
Unity has a new-ish ECS framework under the DOTS initiative; Unreal has no parallel. Very few games are using these.