Héritage vs composition

16

Je gagne de l'argent en C # Généralement dans ce langage, j'aime tout découpler vers le ciel en utilisant des interfaces. Cela m'a bien servi dans le code d'entreprise, mais en écrivant des jeux en C #, je me retrouve à tendre vers l'héritage car je peux définir certains comportements par défaut pour les classes de base. Je me sens sale en faisant cela, comme si je désobéissais à un dieu de l'architecture qui a dit un jour "privilégiez la composition à l'héritage". Je sais que ce n'est pas noir et blanc, mais j'ai également l'impression que je pourrais utiliser des interfaces avec un peu plus de travail et réaliser à peu près la même chose.

Que font les autres gens? L'héritage est-il la bonne approche pour les jeux ou dois-je refactoriser certaines interfaces?

Peter Short
la source
1
Les interfaces ne sont pas non plus de la composition, donc ce n'est pas clair ce que vous demandez.
Je veux juste mentionner que puisque vous travaillez avec C #, vous auriez du mal si vous choisissez d'utiliser l'héritage car C # ne prend pas en charge l'héritage multiple véritable. L'utilisation de la méthode des interfaces multiples est correcte jusqu'à ce que vous atteigniez la plage d'interfaces 4-5 et que vous ayez à couper / coller plus de 25 lignes de code entre chaque classe qui partage la même implémentation. Il y a quelques work-a-rounds mais ils sont tout aussi laids car la langue ne fournit pas de support direct.
NtscCobalt

Réponses:

23

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.

Ingénieur
la source
Merci pour le compagnon de conseil :) Ravi de savoir que je n'entendais pas de voix!
Peter Short
1
+1 Merci pour l'article, je voulais le faire dans mon jeu depuis un certain temps
John McDonald
3
Il convient de noter qu'en raison de l'interdépendance élevée des entités de jeu, l'héritage complique souvent les choses et fait de la maintenabilité et de l'extension une tâche lourde. Les systèmes de composants s'attaquent bien à ce problème et l'autre avantage supplémentaire est ce qui est répertorié dans la réponse ci-dessus;)
James
Il convient également de noter que le "mais quand vous arrivez à portée tout à coup vous vous rendez compte qu'il a un pistolet à gros trou de ver. Surprise surprise!" est une mauvaise conception de jeu: D
Jonathan Connell
1
Les surprises sont amusantes, mais les surprises qui signifient que vous mourrez sans avertissement, comme un navire de bas niveau qui peut vous OHKO, sont juste frustrantes;) Bien sûr, ce n'est peut-être pas ce que vous vouliez dire dans votre réponse. De plus, un jeu ne se limite pas à la conception d'un jeu.
Jonathan Connell
3

Pour ceux qui parlent allemand, un livre intéressant: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

Regardez de plus près quand et pourquoi utiliser quelle architecture peut être trouvée ici: /programming/1901251/component-based-game-engine-design

Pour moi, je décide de mon architecture en fonction de la taille du projet et de la possibilité d'étendre ou de réutiliser le code. Pourquoi investir des heures et des heures dans l'architecture d'un micro-projet où il n'y a aucune chance que vous utilisiez à nouveau le code? Dans le même temps, vous pouvez terminer le projet.

Composition vs composants Les composants sont des trucs fantaisistes mais dans la plupart des projets / architectures, la composition fera aussi l'affaire (sans surcharge basée sur les composants). Cela dépend de ce que votre système de composants peut fournir que la composition ne peut pas.


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 grâce à la composition des objets.

tout cela était possible sans composants il y a longtemps aussi

idefix
la source
-1, les composants sont une forme de composition.
bien, une forme mais pas la même car ils fournissent des fonctionnalités différentes. (Donc je ne comprends pas votre commentaire et -1)
idefix
1
Lorsque vous dites «composition vs composants», ce que vous comparez n'est pas clair car les composants sont de la composition. Voulez-vous dire les composants dynamiques par rapport aux composants statiques? Que ce soit par rapport à la composition des types liés ni à la famille ni à la structure? Qu'est-ce que la «surcharge basée sur les composants»? Dans les systèmes de composants statiques (et de nombreux systèmes dynamiques), la surcharge est presque nulle.
Hm, des points intéressants. Cela vous dérange une discussion un peu plus détaillée? Sinon je voudrais vous envoyer mon adresse mail sur une autre plateforme.
idefix