Was sollte in einem Diagramm der Spielszene enthalten sein?

Würden Sie mir bitte helfen, zu klären, was genau in einem Spieleszenendiagramm enthalten sein sollte? Siehe folgende Liste bitte:

• Spielschauspieler? (Natürlich sollten alle Objekte, deren Status sich ändert, der Hauptteil des Szenendiagramms sein.)
• Einfache statische Spielobjekte? (Ich meine, wirft Orte im Hintergrund aus, die nicht animiert werden und auch nicht kollidieren.)
• Spiel Trigger?
• Spiel Lichter?
• Spiel - Kameras?
• Waffengeschosse ?
• Spielexplosionen und Spezialeffekte?

Die oben betrachteten Objekttypen. Nun zur Abdeckung des Szenendiagramms:

• Sollte ein Szenendiagramm die gesamte Karte des Spiellevels seit Beginn des Levels enthalten oder sollte es nur den sichtbaren Teil der Karte enthalten? Wenn die Sekunde wahr ist, würde dies bedeuten, dass das Szenendiagramm kontinuierlich aktualisiert wird, indem Spielobjekte hinzugefügt / entfernt werden, während sich der Spieler bewegt. Es wäre jedoch viel schneller, nur die sichtbaren Teile der Karte zu enthalten, um sie zu durchlaufen und zu aktualisieren.

Ich denke, ein gutes Stück Nachlesen darüber, was andere Szenendiagrammtechnologien tun, würde Ihnen viele Vorteile bringen.

Hintergrund
Schauen Sie sich zum Beispiel die Ogre3D-Beschreibung an. Es ist eine auf Szenendiagrammen basierende Grafik-Engine, die Open Source ist. Ich würde vorschlagen, dass Sie sich die Tutorials ansehen und sehen, wie Szenenknoten verwendet werden (Hinweis: Ich möchte Ihnen nicht sagen, wie Sie Ogre verwenden sollen, sondern welche Funktionen in den Szenenknoten und Szenenmanagern von Ogre vorhanden sind.)

SceneNode-Dokumentation:
http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_node.html

SceneManager-Dokumentation: http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_manager.html

Etwas anderes, das einen Blick wert ist, ist der folgende Link:
http://sgl.sourceforge.net/#features

Es handelt sich um eine OpenGL-basierte Szenendiagrammlösung. Auf der dortigen Funktionsseite werden alle Knoten angezeigt, die darin enthalten sein können.

Ihre vorgeschlagenen Knoten
Ich bin der Meinung, dass ein Szenendiagramm so weit wie möglich von der Spielelogik entfernt sein sollte, damit Sie keine Abhängigkeitsprobleme haben. Für jeden Ihrer Aufzählungspunkte würde ich Folgendes sagen:

Game Actors
Ich würde wahrscheinlich nein sagen. Ähnlich wie bei Ogre hätte ich eine Basis-Entity-Klasse (die die objektspezifische Logik enthalten würde) und einen Basis-SceneNode mit einem Entity-Member-Zeiger, um die entsprechenden Informationen zum Rendern des Objekts zu erhalten (Position, Ausrichtung usw.).

BEARBEITEN: Ich sage hier nicht, dass Sie Ihre Spielschauspieler nicht in das Szenendiagramm aufnehmen sollen (sonst würde nichts angezeigt: P). Ich sage, dass Sie einen Szenenknoten mit einem Verweis auf die Klasse der logischen Spielschauspieler haben sollen immer noch lose Kopplung des Renderns und Aktualisierens von Spielobjekten.

Einfaches statisches Spiel ojbects
Ja

Spielauslöser?
Nein, das klingt für mich nach spielspezifischer Logik.

Spiellichter?
Ja

Spielekameras?
Ja

Waffengeschosse?
Ich bin mir nicht ganz sicher, aber ich würde wahrscheinlich ja sagen, aber Sie möchten wahrscheinlich alle Aufzählungszeichen als Kinder zu einem übergeordneten Szenenknoten "BulletCollection", damit Sie diese Position zwischenspeichern können und die Position nicht durchlaufen müssen Szenendiagramm viel zu entfernen und Aufzählungszeichen zum Rendern hinzuzufügen.

Spielexplosionen und Spezialeffekte?
Ich bin mir nicht sicher, ich werde es jemand anderem beantworten lassen.

Abdeckung von Szenendiagrammen
Wenn Sie eine relativ kleine Ebene haben, sollten Sie in der Lage sein, die gesamte Ebene in einem Szenendiagramm zu speichern und dann die Sichtbarkeit mithilfe eines Octree (normalerweise für Außenumgebungen) oder eines BSP-Baums (normalerweise für Innenumgebungen) zu optimieren.

Wenn Sie ein viel größeres Level haben und kein Level laden möchten, kommt hier das Streaming ins Spiel, aber das ist ein ganz anderes Problem. Ich würde mit einem kleinen Level beginnen und schrittweise sehen, wie groß Sie es machen können, ohne die Leistung zu beeinträchtigen.

Fazit
Für mich ist ein Szenendiagramm für den Render-Teil einer Spielschleife. Sie sollten Ihr Rendering und Ihre Logikaktualisierungen nicht zu eng miteinander verbinden, da Sie sonst auf lästige Abhängigkeitsprobleme stoßen.

Meine Neigung ist es, weniger Dinge in ein Szenendiagramm einzufügen. Siehe insbesondere diesen Artikel von Tom Forsyth: " Szenendiagramme - Sag einfach nein ."

Der Kern von Forsyths Artikel ist, dass Sie nicht versuchen sollten, eine Menge nicht verwandter Dinge in eine große Stammdatenstruktur zu packen. Dies ist sehr ähnlich zu den Ideen, die ich in dieser Antwort angesprochen habe , um alles im Spiel abzuleiten GameObjectund dann alles in eine große heterogene Liste zu schieben (das heißt, das ist schlecht).

Relativ wenige Objekte auf der Welt weisen wirklich eine starke Eltern-Kind-Beziehung auf, wie es sich für eine Baumstruktur gehört. Das kanonische Beispiel einer Kaffeetasse auf einem Tisch wird hier normalerweise verwendet - sicher, Sie könnten sie als "Kind" des Tisches betrachten ... zumindest bis sie abgeschlagen wird. Ist es dann wirklich noch ein Kind vom Tisch? Dies bedeutet, dass Ihr 'Baum' ziemlich flach werden kann und sowieso zu einer Liste degeneriert.

Daher würde ich vorschlagen, dass Sie mehrere Datenstrukturen für mehrere Dinge verwenden, da dies für diese Dinge am sinnvollsten ist. Statische Geometrie und Lichter scheinen beispielsweise eine vernünftige Sache zu sein, um sie in ein Szenendiagramm zu verschieben. Selbst wenn die dargestellten Objekte keine natürlichen Eltern-Kind-Beziehungen haben, bedeutet die Tatsache, dass sie statisch sind, dass Sie ihnen strukturelle Eltern-Kind-Beziehungen geben können, in dem Wissen, dass sie sich nie ändern.

Spielschauspieler ... da bin ich mir nicht so sicher. Alles, was dazu neigt, sich zu bewegen, bedeutet in der Tat, dass Sie sie normalerweise in der Nähe der Wurzel des Diagramms halten oder sie ständig neu erziehen müssen (was mühsam und nicht sehr effizient ist).

Kugeln, Auslöser, Spezialeffekte und andere vorübergehende Objekte, die ich woanders aufbewahren würde. Nichts, was gerendert wird oder eine visuelle Darstellung hat (ein Auslöser ist normalerweise ein unsichtbares Begrenzungsvolumen, eine Kugel ist normalerweise nur ein Strahlenguss), sollte in einem Renderdiagramm enthalten sein. Sie sollten sich um die Trennung von Render- und Logikebene bemühen .

Für das, was es wert ist, habe ich in keinem der Renderer, die ich für den nicht-akademischen Gebrauch erstellt habe, ein baumartiges Szenendiagramm verwendet (offensichtlich habe ich zuvor baumartige Szenendiagramme erstellt, und so bin ich zu dem Schluss gekommen, dass ich Ich versuche jetzt, Sie dazu zu bringen, zuzustimmen.

Ich verwende räumliche Partitionierungsmethoden, die dem Spielstil entsprechen (Quad-Tree, Octree, BSP usw.), um die logischen Entitäten im Spiel zu gruppieren / auszusortieren, die (a) in diesem Frame verarbeitet und (b) gerendert werden sollen dieser Rahmen. Am Ende füge ich den Satz von Objekten aus Liste (b) in ein System ein, das logische Objekte zum Rendern von Beschreibungen abbildet und diese Beschreibungen basierend auf Eigenschaften in Buckets sortiert (zum Beispiel wird alles, was Transparenz verwendet, in den Bucket für "Sachen" verschoben das sollte von hinten nach vorne gerendert werden) Dann rendere ich jeden Bucket in der richtigen Reihenfolge und für jeden Bucket jede Beschreibung in der richtigen Reihenfolge. Ich denke, man könnte dies einen "Baum" nennen, aber es zeigt nicht den typischen Zustand / Transformationsausbreitungsmethoden, die herkömmliche baumorientierte Szenendiagramme verwenden. YYMV,