Zum Szenendiagramm oder nicht zum Szenendiagramm?

Ich hatte Probleme mit der Entscheidung, ob ich ein Szenendiagramm in mein Spiel implementieren soll oder nicht. Ich habe einige Anwendungsfälle, die ein solches Tool erfordern, aber ich konnte einige Implementierungsdetails nicht durchgehen.

Einige Hintergrundinformationen: Ich schreibe ein Space-Shooter-Spiel für mobile Plattformen (hauptsächlich Android) und mein Code ist fast ausschließlich C ++. Ich verwende keine Middleware. Insbesondere die Rendering- und Physik-Engines sind meine eigenen Kreationen. Meine Physik-Engine aktualisiert die Positionen von Objekten basierend auf Kräften und Impulsen. Ich habe noch kein Animationssystem, kann es aber irgendwann besuchen (was möglicherweise nichts mit dieser Diskussion zu tun hat).

Zunächst beschreibe ich einen guten Anwendungsfall. Ich hätte gerne einen Chef, der aus mehreren diskreten Teilen besteht, von denen jeder unabhängig voneinander beschädigt / zerstört werden kann. Zum Beispiel könnte ich einen Boss haben, der einen Arm hat, der unabhängig vom Rest der Boss-Entität Schaden erleiden kann. Wenn der Arm zerstört wird, könnte ein Feuerpartikeleffekt an der Schulter des Bosses darauf hinweisen, dass der Arm jetzt zerstört ist.

So wie es ist, habe ich beschlossen, solche Probleme mit Einschränkungen in meiner Physik-Engine zu lösen, um solche zusammengesetzten Objekte zusammenzuhalten. Eine solche Einschränkung bietet 0 Freiheitsgrade und ist im Wesentlichen eine Transformationsmatrix. Dies ist wirklich ein Versuch, ein Problem zu umgehen, das mich letztendlich von den unten beschriebenen Szenendiagrammen abgeschaltet hat.

Der Hauptgrund, warum ich mich von der Verwendung eines Szenendiagramms abgewandt habe, ist, dass ich keinen effizienten Weg finden konnte, verschachtelte Objekte (Objekte, die eine Transformation von ihrem übergeordneten Objekt erben) sowohl in der Physikwelt als auch in der Rendering-Szene beizubehalten. Die Physikwelt benötigt Objekte im Weltraum (oder zumindest im selben Raum), während die Rendering-Szene Objekte im Elternraum benötigt. Das Verfolgen von Standorten in beiden Bereichen kann hilfreich sein (und ist unvermeidlich), wirft jedoch eigene Bedenken auf, die sich nicht zuletzt auf die Leistung beziehen.

Angesichts von Anwendungsfällen wie dem oben beschriebenen denke ich jedoch, dass es sehr wichtig sein wird, im übergeordneten Bereich "arbeiten" zu können, und der Versuch, meine Physik-Engine zu zwingen, diese Beziehungen durch die Verwendung von Einschränkungen aufrechtzuerhalten, wird problematisch.

Sollte ich angesichts des oben beschriebenen Anwendungsfalls und der oben beschriebenen Situation eine Diagrammstruktur verwenden, um Transformationen von einem Objekt zu einem anderen zu übergeben? Wenn ja, wie sollte meine Physik-Engine neue Standorte berechnen und Schnittpunkttests für Objekte in verschiedenen Räumen durchführen?

Haben Sie tatsächlich ein hierarchisches Diagramm ausprobiert und die Leistung gemessen?

Haben Sie einfache Physik-Engines untersucht, um zu sehen, wie sie mit dem Problem umgehen? Selbst eine 2D-Engine mit Verknüpfung zwischen Objekten würde Ihnen dabei helfen, eine bewährte Richtung einzuschlagen.

Ich würde nicht versuchen, Ihre Physik in mehreren Räumen zu betreiben, die Komplexität wäre entmutigend. Führen Sie die Physik im Weltraum aus und fügen Sie Funktionen hinzu, um Transformationen Ihrer Hierarchie zu erstellen und lokale Weltraumobjekte in den Weltraum und zurück zu verschieben. Ihre Einschränkungen müssen sich notwendigerweise im lokalen Bereich relativ zum übergeordneten Objekt befinden.

Als Randnotiz ist sogar eine reine Anordnung von Objekten ein "Szenendiagramm", nur ein sehr einfaches. Haben Sie keine Angst davor, Daten so zu organisieren, dass Probleme gelöst werden, und entscheiden Sie insbesondere nicht, dass die Leistung dieser Datenorganisation ein Faktor ist, ohne diese Leistung überhaupt gemessen zu haben.