[AerieC]

I don't think it's ranty at all, and I think you make a good point.

There is always a lot of debate in this industry over which way of doing things is "the best", and I don't think there's ever going to be a time where one "best way" of doing things will apply to all circumstances. Rarely are two problems in development exactly the same. How can anybody make the assertion that any solution will be a one-size-fits-all?

In regards to this example, I can see many instances where inheritance in games could be useful. Not every game needs as much flexibility as the author suggests.

As long as code does what it's supposed to do, as fast as it should be doing it, is well documented, and is understandable and clear, the path you take to get the job done is irrelevant.

[stonemetal]

Not every game needs as much flexibility as the author suggests.

That is the thing, the way our system got put together it isn't flexible. Weapon damage got separated from weapon animations, so now there is no way to dual wield or have shield bashes because there is no way to link damage to the weapon animation. That happens often in our system, things are sliced and diced so finely that you assemble everything out of these little blocks like lego but they are devoid of context so it is impossible say this is apart of that. That is fully a problem with our specific design not the general strategy.

  Also it is rather slow. We store our entities in a database, so the ORM auto generates a 40 table join to check for all the different components we have(performance issues? like hell you say.)  Also for some reason we keep our game objects devoid of all context so there is no way to tell if you have an npc or a potion without examining all the components it has and making a guess.  Basically in our case the flexibility is a lie.  Sure you can gin up any set of components you like but you have no clue how the system is going to react.