Was ist eine gute Entitätshierarchie für ein 2D-Spiel?

Ich bin gerade dabei, ein neues 2D-Spiel aus einem Code zu erstellen, den ich vor einiger Zeit geschrieben habe.

Die Objekthierarchie für Entitäten lautet wie folgt:

• Scene(zB MainMenu): Enthält mehrere Entitäten und Delegierte update()/ draw()an jede
• Entity: Basisklasse für alle Dinge in einer Szene (zB MenuItemoder Alien)
• Sprite: Basisklasse für alle Entitäten, die nur eine Textur zeichnen, dh keine eigene Zeichenlogik haben

Ist es sinnvoll, Entitäten und Sprites so aufzuteilen? Ich denke in einem 2D-Spiel sind die Begriffe Entität und Sprite etwas synonym, oder?

Ich glaube jedoch, dass ich eine Basisklasse für Entitäten benötige, die nur eine Textur zeichnen, anstatt sich selbst zu zeichnen, um Doppelarbeit zu vermeiden. Die meisten Entitäten sind so.

Ein seltsamer Fall ist meine TextKlasse: Sie leitet sich von ab Sprite, die entweder den Pfad eines Bildes oder eine bereits geladene Textur in ihrem Konstruktor akzeptiert. TextLädt eine Textur in seinen Konstruktor und übergibt diese an Sprite.

Können Sie ein Design skizzieren, das sinnvoller ist? Oder weisen Sie mich auf eine gute objektorientierte Referenzcodebasis für ein 2D-Spiel hin? Ich konnte nur 3D-Engine-Codebasen mit anständiger Codequalität finden, z. B. Doom 3 und HPL1Engine.

Im Allgemeinen ist es keine schlechte Idee, die Spielmechanik von ihrer visuellen Darstellung zu trennen. Wenn Sie eine Spielelogik haben, die einerseits nicht weiß, wie sie angezeigt wird, und eine Grafik-Engine, die eine visuelle Darstellung des aktuellen Spielstatus erstellt, sich aber nicht darum kümmert, wie dieser Status andererseits erstellt wird, ist Ihre Code wird viel flexibler sein. Sie können beispielsweise problemlos eine alternative visuelle Darstellung des Spielstatus erstellen, z. B. eine Minikarte, eine Übersichtskarte oder eine völlig andere Perspektive. Sie können sogar von einer 2D-Engine zu einer 3D-Engine wechseln, ohne den Code der Spielmechanik zu berühren. Ihre visuellen Darstellungen wären ebenso flexibel. Wenn Ihre Grafik-Engine spielunabhängig ist,

Daher würde ich Sprite nicht als Basisklasse empfehlen.

Ein weiterer Grund ist, dass es in Ihrer Spielszene möglicherweise Objekte gibt, die keine visuelle Darstellung haben (z. B. Ereignisauslöserbereiche). Oder Sie könnten Objekte haben, die mehr als ein Sprite haben. In einem 2D-RPG-Projekt, an dem ich teilgenommen habe, hatten wir Charaktere mit einem nackten Basis-Sprite und mehreren Stoff-Sprites, die über das Basis-Sprite gelegt wurden. Also hatte jede Entität 0..n Sprites. Ich könnte mir auch andere Genres vorstellen, in denen es sinnvoll sein könnte, Objekte zu haben, die durch mehrere übereinander gestrichene Bilder dargestellt werden.

Das Erstellen Ihrer Objekthierarchie ist sehr anwendungsspezifisch und hängt stark von Ihrem Gameplay ab. Es ist daher schwierig, eine eindeutige Richtlinie bereitzustellen.

Im Allgemeinen sollten Sie die Komposition nach Möglichkeit der Vererbung vorziehen. In diesem Beispiel hätte ich Sprite nicht als Basisklasse, von der Spielobjekte abgeleitet sind. Ob ein Sprite gezeichnet werden soll oder nicht, ist nur eine Eigenschaft des Entity-Objekts. Möglicherweise folgen Sprite und Text einer Drawable-Oberfläche und ordnen sie entsprechend den Entitäten zu.

Erwägen Sie die Verwendung eines komponentenbasierten Spielobjektsystems:
/programming/1901251/component-based-game-engine-design

Es ist ein sehr flexibler und moderner Ansatz, der sich gut für mittelgroße und große Spiele eignet.