Thread by @sebify

You showed an interest in knowing why I currently think the ECS paradigm can be used to write maintainable code. This is going to be a long read (20+ tweets) but it's a summary of what I write on sebaslab.com. Let me know if it makes sense to you:

In case you never used a procedural language: have you ever thought how to write a whole game with it? It was fun. A main function was usually running a single loop for the duration of the game execution with all the logic in it, laid out sequentially

The code was not designed around objects, but around blocks of logic that would share most of the data. Clear frame, read input, check collisions, game logic, render background and sprites, play sounds...similar sequences were used and the code was relatively simple to follow

I moved from C to C++ like I moved from ODD to DOD, naturally. When complexity grew to the C limits, I started to use OOD as its data encapsulation seemed to help. OOP is great for ADTs and code abstraction, but its weaknesses show when objects must interact in complex systems

Did you know? OOP original designers knew that a fundamental problem would have been to make objects communicate. According what I read from Wikipedia, before C++, OOP objects communication should have happened only through messaging, improving encapsulation

2 of the reasons why OOP exists are Encapsulation and Reusability. Reusability through inheritance fails because behaviours cannot be composed in all the permutations and that's why composition is preferred. The multi-inheritance workaround introduced more problem than it solved

In c++ encapsulation can be broken in many ways, but mainly it happens due to inter-objects communication and since there isn't a standardised way to let objects communicate, encapsulation is usually broken in the most fantastic ways.

For a long time, while making games, I was happy with the solutions I used to find, but I wasn't able to reuse them. I was inventing the wheel every time, a classic problem in gamedev. GOF patterns weren't the solution, making things more confusing. This started my journey

Switching to C# was easy and my previous experience made me realise immediately the limits of the Component based object system Unity uses. It's at that point when I started my blog and the first thing I experimented was to use an Inversion of Control container

I realised that the problems regarding good OOP code design always orbit around inter objects communication as it can't happen without a form of dependency injection. Even Singletons solve dependency injection, although in the worst way possible

Did you know? Svelto.IoC was the 1st IoC container made for Unity. An IoCc cannot be used without applying the Inversion of Control principle. Funny enough, it was the studying of the limits of using an IoCc that led me to implement Svelto.ECS

In my articles I discern between Inversion Of Creation Control (you can't create dependencies outside a composition root) and Inversion of Flow control (the Hollywood principle "Don't call us, we'll call you"). Using an IoCc without applying both concepts leads to design failure

The applications of the Hollywood principle through an IoCc were taking me to the same conclusion: the Template Pattern. Did you know? Many engines, including Unity and Unreal, use it. However traditionally the TP is used inside frameworks and not for the game code itself.

It's simple to see that the evolution of the Template Pattern is ECS. As it was happening in C, the logic that runs inside the TP managers doesn't need to use external dependencies, it needs just the object data.

At this point I suddenly saw the value of ECS. I knew about it, but I didn't realise the code design benefits of its use. Systems are a great way to solve inter entities communication. They know all the entities they must handle, implicitly solving the communication problem.

Data dependency is solved too and object injection is not needed. Inversion of Flow Control works in the same way it works with the template pattern, the systems take over the logic responsibilities.

The SOLID principles are the foundation to understand the OOD patterns. However I see ECS as the antithesis of OOP, a different paradigm. Can the SOLID principles be applied too then? I think so:

Let's start from the Single Responsibility. ECS is not perfect and it must be used wisely. In fact, it's very simple to see ECS as procedural code with global accessible data. This would lead to catastrophe.

Systems can be seen as behaviours to apply to a set of entities. They can access multiple entities to enable communication, but the behaviour is always applied to a specific entity type. Once the system is seen as a single entity type behaviour, it's simple to follow the SRP

Open Close Principle: Systems following the SRP are very modular. Entity behaviours are enabled through data composition and components permutations would enable different entity behaviours. Instead to modify a big system, would be better to create new modular ones.

The Liskov substitution principle: systems and components can be designed at different levels of abstraction. While specialised components belong to specialised entities, generic ones can be shared among different entity types.

Think about a health component, it can be used on all the entities requiring health. The health systems don't need to know the specific entity types, but can handle all of them through the health component (basically no need to downcast!).

The Dependency Inversion Principle may make sense too, as the less abstracted system can use the higher abstracted entity components, but the more abstracted system should never access the less abstracted entity component.

The Interface Segregation Principle is the only one that may not have really a counterpart in ECS. Maybe we can apply it to the entity components as these should be kept focused.

In fact, a big entity component with a lot of data can be created, but if an entity component includes health and more specialized data, then the previous principles cannot be applied.

I think I wrote long enough now, but these are essentially my thoughts. A blog post with more links and info will follow. but meanwhile, if you are interested, you should read what I have already written on the topic on sebaslab.com