Vererbung gegen Zusammensetzung


16

Ich verdiene mein Geld in C # Im Allgemeinen entkopple ich in dieser Sprache gerne alles mit Hilfe von Schnittstellen an den Himmel. Dies hat mir im Enterprise-Code gute Dienste geleistet, aber beim Schreiben von Spielen in C # tendiere ich zur Vererbung, da ich einige Standardverhaltensweisen für Basisklassen definieren kann. Ich fühle mich dabei allerdings dreckig, als würde ich einem Architekturgott nicht gehorchen, der einmal sagte "Komposition gegenüber Vererbung bevorzugen". Ich weiß, dass es nicht schwarz-weiß ist, aber ich habe auch das Gefühl, dass ich Schnittstellen mit ein bisschen mehr Arbeit verwenden und ungefähr das Gleiche erreichen könnte.

Was machen andere Leute? Ist die Vererbung der richtige Ansatz für Spiele oder sollte ich einige Schnittstellen überarbeiten?


1
Schnittstellen sind auch keine Komposition, daher ist nicht klar, wonach Sie fragen.

Ich möchte nur erwähnen, dass Sie Schwierigkeiten haben würden, wenn Sie die Vererbung verwenden, da C # keine echte Mehrfachvererbung unterstützt, da Sie mit C # arbeiten. Die Verwendung der Mehrfachschnittstellenmethode ist in Ordnung, bis Sie in den 4-5-Schnittstellenbereich gelangen und mehr als 25 Codezeilen zwischen jeder Klasse mit derselben Implementierung ausschneiden / einfügen müssen. Es gibt einige Work-a-Rounds, aber sie sind genauso hässlich, da die Sprache keine direkte Unterstützung bietet.
NtscCobalt

Antworten:


23

Vererbung in Spielen ist tatsächlich eines der schlimmsten Dinge, die Sie tun können - insbesondere in Bezug auf Entitäten. Lesen Sie hier, warum. Komposition über Vererbung bringt Sie mit Spielen weit. Wie für andere Bereiche Ihres Motors, ist es nicht wirklich wichtig. Angenommen, Sie rufen einen externen Netzwerkdienst an und erben dann einen generischen Diensttyp an z. HTTPService und SocketService - ähnlich wie in den gewohnten Unternehmensanwendungen.

Es sei denn , Ihr Spiel ist wirklich einfach, Sie werden wollen eine komponentenbasierte Einheit (CBE) Architektur verwenden. Die allgemeine Idee ist, dass bei Entitäten der Grund dafür, dass sie so häufig zusammengesetzt und nicht geerbt werden, darin besteht, dass Sie erst zur Laufzeit wissen können, über welche Funktionen eine bestimmte Entität verfügt. Nehmen Sie zum Beispiel das Schiff des Spielers in einem Weltraum-Shooter. Bis zu einem bestimmten Zeitpunkt im Spiel wissen Sie nicht, welche Waffen, Rüstungen, Systeme (dh Komponenten) der Spieler aufnehmen, kaufen, verkaufen, verlieren, zerstören usw. wird. Der einzig realistische Weg, dies zu modellieren, ist durch Objektzusammensetzung. Das Plus in diesem Szenario ist, dass Sie auch vollständig anpassbare Feinde haben können, die auf die gleiche Weise aufgebaut sind, anstatt Feinde, die jedes Mal, wenn Sie diesen Feindtyp sehen, exakt gleich sind. Mit CBEs sehen Sie vielleicht einen Marsfrachter und denken: "Ah, es hat nur winzige Laser, ich mache es kaputt." Normalerweise ist das der Fall, aber wenn Sie plötzlich in Reichweite kommen, stellen Sie fest, dass es einen großen Hintern hat Wurmlochgewehr. Überraschung Überraschung!

Die Komponentisierung hebt die implizite Verknüpfung von Logik auf, und das ist GUT.


Danke für den Rat, Kumpel :) Schön zu wissen, dass ich keine Stimmen gehört habe!
Peter Short

1
+1 Vielen Dank für den Artikel, ich habe vor, dies für einige Zeit in meinem Spiel zu tun
John McDonald

3
Es sollte beachtet werden, dass die Vererbung aufgrund der hohen gegenseitigen Abhängigkeit von Spieleinheiten die Dinge oft kompliziert und die Wartbarkeit und Erweiterung zu einer mühsamen Aufgabe macht. Komponentensysteme packen dieses Problem gut an und der andere zusätzliche Vorteil ist, was in der Antwort oben aufgeführt ist;)
James

Zu beachten ist auch, dass das "aber wenn man plötzlich in Reichweite kommt merkt man, dass es eine dicke Wurmlochpistole hat. Überraschung Überraschung!" ist schlechtes Spieldesign: D
Jonathan Connell

1
Überraschungen machen Spaß, aber Überraschungen, die bedeuten, dass Sie ohne Vorwarnung sterben, wie ein Low-Level-Schiff, das Sie OHKO kann, sind nur frustrierend;) Natürlich ist dies möglicherweise nicht das, was Sie in Ihrer Antwort gemeint haben. Zu einem Spiel gehört auch viel mehr als nur das Design eines Spiels.
Jonathan Connell

3

Für diejenigen, die Deutsch sprechen, ein interessantes Buch: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

Hier erfahren Sie, wann und warum Sie welche Architektur verwenden: /programming/1901251/component-based-game-engine-design

Für mich selbst entscheide ich meine Architektur in Abhängigkeit von der Größe des Projekts und der Möglichkeit, den Code zu erweitern oder wiederzuverwenden. Warum stundenlang in die Architektur eines Mikroprojekts investieren, bei dem es unwahrscheinlich ist, dass Sie den Code erneut verwenden? In der gleichen Zeit können Sie das Projekt fertig haben.

Komposition gegen Komponenten Komponenten sind coole, ausgefallene Dinge, aber in den meisten Projekten / Architekturen erledigt Komposition diese Dinge auch (ohne komponentenbasierten Overhead). Es kommt darauf an, was Ihr Komponentensystem für eine Komposition bietet, die es nicht kann.


Nehmen Sie zum Beispiel das Schiff des Spielers in einem Weltraum-Shooter. Bis zu einem bestimmten Zeitpunkt im Spiel wissen Sie nicht, welche Waffen, Rüstungen, Systeme (dh Komponenten) der Spieler aufnehmen, kaufen, verkaufen, verlieren, zerstören usw. wird. Der einzig realistische Weg, dies zu modellieren, ist durch Objektzusammensetzung.

all das war schon lange ohne komponenten möglich


-1, Komponenten sind eine Form der Zusammensetzung.

Nun, eine Form von, aber nicht die gleiche, da sie unterschiedliche Funktionen bieten. (Also verstehe ich Ihren Kommentar und -1 nicht)
idefix

1
Wenn Sie auf „Zusammensetzung vs Komponenten“ , sagen ist es nicht klar , was Sie vergleichen , da Komponenten sind Zusammensetzung. Meinen Sie dynamische oder statische Komponenten? Weder familiär noch strukturell verwandt? Was ist "komponentenbasierter Overhead"? In statischen Komponentensystemen (und vielen dynamischen) ist der Overhead nahezu Null.

Hm, interessante Punkte. Stört es Sie, etwas ausführlicher zu diskutieren? Wenn nicht, möchte ich Ihnen meine E-Mail-Adresse auf einer anderen Plattform senden.
Idefix
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.