This "huge win" depends heavily on what you're making. If you're making simple games where performance is not that much of a problem (like most indie games) then moving to entity/component systems makes no sense and tends to make everything more complex than it needs to be. A good middle ground in those cases is to just stick with normal OOP with shallow trees (no more than 2-3 levels) and favor simpler types of composition like mixins whenever needed.
As someone who has made indie games with both traditional OOP and component systems-- I vastly prefer component systems. I disagree that they make things more complex. I found that they made things much simpler. Although, it does require learning about and possibly developing a component system.
If you are talking about very very simple games, it would perhaps not be worth the effort, but at that level basically any architecture will work.
Entity component systems are just another form of OO that rely heavily on ontology and named object instances. Unless you mean OOP must be Java, then of course, it's not.
Even indie games can benefit a lot from components, and a basic component-entity system is very easy to implement. Make component and entity classes, give the entities a list of components, put the update method in the component, and put most of your code there.
This is fairly different from the most popular/performant ways of implementing ECS's (there are no "Systems"), but keeps a lot of the benefits (much more flexible than traditional class hierarchies, easier to develop and design content for without writing new code, etc), while avoiding a lot of the complexity which makes component systems overkill for smaller games.
You lose a bit of performance (compared to other methods of implementing component systems), but in higher level languages this will likely be faster than trying to imitate C++ patterns (I could say more about this, as I've seen some travesties, but I won't).
For a higher level language (I use Lua) I prefer a more loose type of system where I skip the part of creating components and putting them in a list and just inject methods/attributes to my objects directly in the form of mixins. At this point I wouldn't say that this is an ECS, it's just normal OOP favoring composition wherever it makes sense. From what I've seen though most people do tend to go for the system type of ECS and that's what I was referring to when I said that it makes things more complicated than they need to be.
Comments
This "huge win" depends heavily on what you're making. If you're making simple games where performance is not that much of a problem (like most indie games) then moving to entity/component systems makes no sense and tends to make everything more complex than it needs to be. A good middle ground in those cases is to just stick with normal OOP with shallow trees (no more than 2-3 levels) and favor simpler types of composition like mixins whenever needed.
As someone who has made indie games with both traditional OOP and component systems-- I vastly prefer component systems. I disagree that they make things more complex. I found that they made things much simpler. Although, it does require learning about and possibly developing a component system.
If you are talking about very very simple games, it would perhaps not be worth the effort, but at that level basically any architecture will work.
Entity component systems are just another form of OO that rely heavily on ontology and named object instances. Unless you mean OOP must be Java, then of course, it's not.
Even indie games can benefit a lot from components, and a basic component-entity system is very easy to implement. Make component and entity classes, give the entities a list of components, put the update method in the component, and put most of your code there.
This is fairly different from the most popular/performant ways of implementing ECS's (there are no "Systems"), but keeps a lot of the benefits (much more flexible than traditional class hierarchies, easier to develop and design content for without writing new code, etc), while avoiding a lot of the complexity which makes component systems overkill for smaller games.
You lose a bit of performance (compared to other methods of implementing component systems), but in higher level languages this will likely be faster than trying to imitate C++ patterns (I could say more about this, as I've seen some travesties, but I won't).
For a higher level language (I use Lua) I prefer a more loose type of system where I skip the part of creating components and putting them in a list and just inject methods/attributes to my objects directly in the form of mixins. At this point I wouldn't say that this is an ECS, it's just normal OOP favoring composition wherever it makes sense. From what I've seen though most people do tend to go for the system type of ECS and that's what I was referring to when I said that it makes things more complicated than they need to be.