I went through a very similar thing writing my own toy/hobby game-project. It started out as a classical straightforward OOP design, but once I started adding e

I went through a very similar thing writing my own toy/hobby game-project. It started out as a classical straightforward OOP design, but once I started adding extra stuff to it like animation, a scripting engine, etc. I really started to feel a lot of inertia from the design and the awkward forced hierarchies I had built. Over time I've been incrementally flattening the design to end up with the kind of hybrid/half-way design mentioned in the article, which borrows some things from ECS, but still has distinct game objects implemented as classes. I'm not fully on-board with the (between-the-lines) assessment in the article that this is somehow inferior to, or should just be a stepping stone towards a full-blown ECS though. At least not for a simple game where performance is not really a concern. My view is that a hybrid approach can actually be better than a 'real' ECS for those kinds of cases, taking the best of both worlds. In my case I don't use any inheritance, only composition, I don't have to fight OOP, but I can still write very clear and concise code to access and manipulate properties of my game objects. It may not be cache-efficient and whatnot, but that really is no concern for my simple game at all, having at most 20 to 40 lightweight entities active at the same time. Physics updates (which could drag down performance if too inefficient) are treated like in a traditional ECS, simply advancing the full physics sim for all entities completely separate from the game objects. Looking forward to the next article!