Not to dig up an old topic, and to avoid putting up a new one, but to respond to this topic.
I have been doing a lot of studying on the ECS Design pattern so I'll give you my 2 1/2 Cents....
First off don't mistake it as EC System like most people... it's not a system it's a design pattern that involves 3 components:
1) Entities - Are unique identifiers that relate to a specific piece of "The World"; this could be a player, monster, NPC, sword, rock, the grass you walk on... etc.
2) Components - Are storage units that contain specific pieces of information about an entity, for example, a PositionComponent would possess an X and Y value as well as possibly a Z value to represent the present location of an entity.
3) Systems - Are the "Muscles", they operate everything and tie everything together by creating actions; Systems are generally separated into 3 groups:
- Global System: Basically the game itself
- Managers: Entity, Component, & System Manager which regulates everything
- Sub-Systems: Which operate your basic features, from rendering to crafting to movement.
The reasoning behind using an ECS over OOP is actually quite simple. OOP was designed to solve a lot of issues when building complex applications such as video games. However, while it did solve quite a few issues it also created more to take their place. This is common for any design pattern, there is no perfect design for coding, it's simply a question of what issues do you prefer to deal with and which ones you can't stand. ECS focuses around fixing the issues known as the "God Blob" and the "Diamond" complexes, where by most features wind up in a lowly base class that collects virtually everything from everywhere (God Blob), or you wind up with 4 classes 1 being the base class with a ton of junk code, 2 and 3 being sub-classes of 1 to represent specific entities and 4 being a sub class of 2 and 3, because 1, 2 or 3 didn't have everything it needed individually. Thus creating 2 base class-like classes (1 & 4) and 2 sub-class-like classes (2 & 3) (Diamond). Both issues which cause a great deal of overhead, not to mention a massive headache, especially later on.
By it's basic definition ECS does not follow any of the OOP standards, in fact most people will tell you to forget everything OOP. At it's core ECS creates a massive degree of dis-connectivity between the objects, data and systems of a game. This might sound pointless when trying to code a video game but it is actually a good thing. The problems faced by OOP design is that everything is based around inheritance, so if you want to change one thing chances are you have to change many things to create a simple outcome, because everything is connected. But with ECS you simply create a unique id and add the components it needs to make it what you want it to be. In essence you literally build objects. This can be very good especially for MMO design as in the MMO world creating updates and patches must happen very quickly, so having to go back and re-code a lot of information can ruin your MMO's career very quickly.
There is of course a great deal of debate on how an ECS should be designed. In realty there is no right or wrong way it's just what you prefer. If you go by what some people say an ECS design should look like, Entities are integers stored in a list, components are classes that inherit from an interface that designates it as type Component, and systems iterate over the list of entities checking the attached components to see if the entity "fits" then operating on them. The only level of communication is between systems by means of Events. So in essence you have a sh** ton of events firing off throughout every operation... (Note issue #1)
I like to look at it this way, as a very smart person once stated: ECS design is like a Lock and Key, the lock is a System and only a certain key can open it. The key itself is an Entity, and the little groves/prongs coming out of the key are components. When you insert the key into the lock if it doesn't turn then it doesn't belong to that lock. This is a perfect analogy for ECS design, but that doesn't mean it is the perfect design concept.
So what are some drawbacks? Well first off, you have a ton of events firing off everywhere, that alone kinda negates the reduced overhead by not using massive class hierarchies. What else? Well if nothing but systems communicate then how do your components and entities communicate? If systems are listed and ran in order based on the most common ECS design, then what about time-lag? If I move and Move sends a message to Render, how long till render runs in order to update my screen? For that matter what if Render is before my Move system? So I have to wait till the next interval for it to update? What if something updates my components before Render can get to it? Does it glitch? These kinds of questions quickly arise and the entire design breaks down.
But ultimately this is how it works. Personally I prefer a more hybrid design, bringing in certain features of OOP into the ECS design to solve several flaws creating a middle ground for the overhead issue. I'm actually working on a design pattern right now that mostly follows the ECS standards, while hybridizing certain OOP aspects to create a fast and efficient model.
If you have any further questions let me know...
