Game object systems

While designing a small engine for C# roguelike I've tried to figure out how to implement the object system. ECS (entity component system) is a typical way to handle it, but I don't like it. It's "simple" only from the surface, because the structure of code doesn't have to reflect the object hierarchy. You can add components (I would rather call them properties) to a base object class and that's it. No need to think about complex class hierarchy etc.

But, it's actually modeling the same amount of complexity anyway. There are people who always parrot the meme "use composition over inheritance" which I find quite annoying. If you think about a component, let's say a container. You would add it to a class and use it something like object.container.PutItem(); Yet, if you inherit from a container class and then use it like object.PutItemInContainer(); it's in practice the same thing. The only difference is that when you use inheritance you need to create larger and more rigid class hierarchy. I bet those parroting people never actually created a full class hierarchy for game objects, they just assume it's "ridiculous" etc. even it's simply modeling the same amount of complexity.

My guess is that it makes sense to use class hierarchy for things that don't change in the game object, and property/component list for external things that can be added and removed from the object. The roadblock in this design is that C# only implements single inheritance. Although you could somehow create such a simple class hierarchy that it doesn't need multiple inheritance by adding some things as components. It's a shame that Microsoft didn't include multiple inheritance to C#, because in my mind it is one of the core principles of object-oriented programming. It's like removing GOTO from BASIC language, because they think it's bad. C# does have interface, but I'm still trying to understand how it could replace multiple inheritance, because just by reading about it I don't get the concept.

I think it's a tempting idea to use a simple object class with component model, but I would rather accept the fact that it's a complex system and try to approach it that way. In OO languages it's quite silly to avoid actual object-oriented style, but that's what many people are doing. Then they complain that object-oriented languages are bad (C++ obviously the worst). Even though we have much less success from using something like pure functional languages in game programming.