L'héritage dans les jeux est en fait l'une des pires choses que vous puissiez faire - en particulier en ce qui concerne les entités. Lisez ceci pour savoir pourquoi. La composition sur l'héritage vous emmène loin avec les jeux. Quant aux autres domaines de votre moteur, cela n'a pas vraiment d'importance. Supposons par exemple que vous appelez une sorte de service réseau externe, puis vous pouvez hériter d'un type de service générique, par exemple. HTTPService et SocketService - tout comme dans les applications d'entreprise auxquelles vous êtes habitué.
À moins que votre jeu est vraiment simple, vous aurez à utiliser une architecture d'entité à base de composants (CBE). L'idée générale est qu'avec les entités, la raison pour laquelle elles sont si couramment composées plutôt qu'héritées est parce que vous ne pouvez pas savoir avant l'exécution quelles capacités une entité donnée aura.. Par exemple, prenez le vaisseau du joueur dans un jeu de tir spatial. Vous ne savez pas jusqu'à quel moment du jeu, quelles armes, armures, systèmes (c'est-à-dire les composants) que le joueur va ramasser, acheter, vendre, perdre, avoir détruits, etc. Donc, la seule façon réaliste de modéliser cela est par la composition d'objets. Le côté positif de ce scénario est que vous pouvez également avoir des ennemis entièrement personnalisables, construits de la même manière, plutôt que des ennemis qui sont toujours exactement les mêmes chaque fois que vous voyez ce type d'ennemi. Donc, avec les CBE, vous pourriez voir un Martian Freighter et penser: "Ah, il n'a que de minuscules lasers, je vais le retirer", et généralement ce serait vrai, mais quand vous arrivez à portée, vous vous rendez compte qu'il a un gros cul pistolet trou de ver. Surprise Surprise!
La mise en composants supprime le couplage implicite de la logique, et c'est bien.