Verstehen von Entities

Lassen Sie uns nun das Konzept eines Entity in Cave verstehen. Entities sind die grundlegenden Objekte innerhalb einer Cave-Szene.

Wenn eine Szene ein Level, Menü oder Testbereich ist, sind Entities die Dinge, die in diesem Raum existieren. Zum Beispiel können ein Spieler, Gegner, Tür, Licht, Kamera, Trigger, UI-Schaltfläche, Soundquelle und Ordner alle Entities sein.

In dieser Lektion lernen Sie:

• Namen.
• IDs.
• Aktivierungszustand.
• Parenting.
• Ordner.
• Hierarchie-Reihenfolge.
• Tags und Eigenschaften.
• Template-Instanzen.

Diese Details mögen klein erscheinen, aber sie machen einen großen Unterschied, wenn eine Szene von wenigen Objekten zu einem echten Level wächst.

Was ist ein Entity?

Ein Entity ist ein Objekt in einer Szene.

Ein Entity kann repräsentieren:

• Ein sichtbares 3D-Objekt.
• Einen unsichtbaren Helfer.
• Einen Gameplay-Trigger.
• Ein UI-Element.
• Eine Soundquelle.
• Oder einfach einen Ordner zur Organisation.

Zum Beispiel ist eine Kiste ein sichtbares Entity. Ein Spawnpunkt kann im Gameplay unsichtbar sein, ist aber dennoch ein Entity, weil er markiert, wo etwas passieren soll.

Cave hält diese Idee einfach: Szenen werden aus Entities aufgebaut.

Entities sind Komponenten-Container

Entities allein können nicht viel, ihre Funktionen kommen von Komponenten. Zum Beispiel:

Deshalb sind Entities flexibel. Eine Tür ist kein komplett separater, hart codierter Objekttyp. Sie ist ein Entity, das aus Bausteinen besteht: ein Mesh zum Sehen, Kollisionskörper, um den Spieler zu blockieren, und Logik zum Öffnen oder Schließen.

Wenn Sie das verstehen, wird das Erstellen von Objekten praktischer. Sie hören auf zu fragen "Welchen Objekttyp brauche ich?" und fragen stattdessen "Welche Komponenten braucht dieses Entity?"

Entity-Namen

Jedes Entity hat einen Namen. Sie können ein Entity über das Schnellbearbeitungsmenü im Scene Graph oder im Properties-Tab umbenennen.

Es ist erwähnenswert, dass Namen in erster Linie für Menschen gedacht sind:

• Sie erleichtern das Durchsuchen des Scene Graph.
• Sie erleichtern das Debuggen.
• Sie erleichtern die Kommunikation über Objekte mit Teammitgliedern.
• Sie helfen Ihnen später, Ihre Szene besser zu verstehen.

Cave verlangt nicht, dass jeder Entity-Name einzigartig ist. Mehrere Entities können denselben Namen haben, was bei wiederholten Objekten wie Steinen, Münzen, Kisten oder Gegnern nützlich ist.

Behandeln Sie den Namen jedoch nicht als einzigen zuverlässigen Bezeichner für ein Entity.

Gute Namen sind einfach und beschreibend:

Das Ziel ist nicht, Namen schick klingen zu lassen. Das Ziel ist, die Szene lesbar zu machen.

Entity-Namen können auch im Code verwendet werden, um ein bestimmtes Entity aus Ihrer Szene anzusprechen. Da Sie jedoch wissen, dass mehrere Entities denselben Namen haben können, sollten Sie auch beachten, dass wenn Sie ein Entity über seinen Namen ansprechen und es mehrere Entities mit diesem Namen gibt, dies zu undefiniertem Verhalten führen kann, da nicht garantiert ist, welches Entity zurückgegeben wird. Es wird das erste gefundene zurückgegeben. Wenn es also wichtig ist, ein bestimmtes Objekt im Code zu erhalten, wie den Spieler, stellen Sie sicher, dass es einen eindeutigen Namen hat.

Entity-IDs

Cave verfolgt Entities intern mit eindeutigen IDs.

Sie müssen diese IDs normalerweise nicht bearbeiten oder sich darum kümmern. Sie existieren, damit die Engine Entities zuverlässig identifizieren kann, auch wenn sich Namen wiederholen. Tatsächlich sind eindeutige IDs unveränderlich, das heißt, sie können nicht geändert werden. Sie werden automatisch von der Engine zugewiesen.

Merken Sie sich:

Wenn zwei Gegner beide Enemy heißen, kann Cave sie dennoch intern unterscheiden.

Aktivierungszustand des Entity

Entities können aktiv oder inaktiv sein.

Im Scene Graph und Properties-Tab wird dies mit einer augenähnlichen Aktivierungssteuerung angezeigt.

Abhängig vom Entity und seinen Komponenten kann das Deaktivieren folgende Bereiche beeinflussen:

• Rendering.
• Physik.
• Logik.
• Laufzeit-Updates.
• Verhalten von Komponenten.

Ein deaktiviertes Entity wird niemals Updates seiner Komponenten erhalten. Sobald Sie ein Entity deaktivieren, wird die End-Methode der Komponenten aufgerufen, und wenn Sie es wieder aktivieren, wird die Start-Methode der Komponenten aufgerufen.

Sie können sicher davon ausgehen, dass ein deaktiviertes Entity nicht zu Physikberechnungen, Logik, Triggern usw. der Szene beiträgt, es sei denn, Sie fragen diese Entities manuell ab und ignorieren, dass sie deaktiviert sind.

Die praktische Idee ist einfach: inaktiv bedeutet "hier behalten, aber momentan nicht aktiv".

Deaktivieren vs. Löschen

Deaktivieren und Löschen sind nicht dasselbe.

Deaktivieren Sie ein Entity, wenn Sie es später möglicherweise wieder benötigen. Löschen Sie ein Entity, wenn Sie sicher sind, dass es entfernt werden soll.

Zum Testen ist Deaktivieren oft sicherer. Wenn eine Gegnerbegegnung zu schwer erscheint, deaktivieren Sie zunächst einige Gegner und testen das Level. Wenn die Änderung passt, können Sie die Szene später bereinigen.

Parenting von Entities

Entities können anderen Entities als Eltern zugeordnet werden.

Wenn ein Entity einen Elternteil hat, wird es Teil der Hierarchie dieses Elternteils. Wenn Sie den Eltern bewegen, bewegen sich die Kinder mit.

Parenting ist nützlich für:

• Ein Schwert, das an einen Charakter angehängt ist.
• Ein Licht, das an eine Fackel gehängt ist.
• Eine Kamera, die an ein Fahrzeug angehängt ist.
• Eine Gruppe von Requisiten, die unter einem Ordner organisiert sind.
• UI-Elemente, die unter einem Eltern-Panel gruppiert sind.

Parenting beeinflusst auch die Transformationen. Die Transformation eines Kind-Entity wird relativ zur Eltern-Hierarchie bewertet.

Dies ist eine der einfachsten Methoden, verwandte Objekte zusammenzuhalten.

Ordner-Entities

Ordner-Entities werden zur Organisation verwendet. Sie sind besonders hilfreich, wenn Ihre Szene viele Objekte enthält.

Definitiongemäß macht das Fehlen von Komponenten wie Transform und UI Element ein Entity oft zu einem Ordner, da ein Entity ohne Welt-Transform und ohne UI-Element wahrscheinlich als Ordner verwendet wird. Dies ist jedoch hauptsächlich eine Namenskonvention.

Häufige Ordnergruppen sind:

• Umgebung.
• Gameplay-Trigger.
• Gegner.
• Requisiten.
• Beleuchtung.
• UI.
• Audio.
• Debug-Helfer.

Ordner dienen nicht nur der Ordnung. Ein sauberer Scene Graph hilft Ihnen, schneller zu arbeiten, weil Sie das benötigte Objekt ohne Suche durch hunderte lose Entities finden können.

Reihenfolge der Entities in der Hierarchie

Die Reihenfolge der Entities im Scene Graph ist für die Organisation wichtig und kann in manchen Fällen auch beeinflussen, wie Dinge verarbeitet oder angezeigt werden.

Wenn Sie einen Ordner öffnen und die folgende Struktur sehen, ist das schwer zu überblicken:

Kiste
Spieler
Licht
Gegner
Kamera
Stein
Trigger

Aber diese ist leichter:

Spieler
Kamera
Beleuchtung
Gegner
Umgebung
Gameplay Trigger

Das Ziel ist nicht, die Hierarchie schick zu machen, sondern nützlich.

Wenn Sie eine Szene nach einer Woche Pause öffnen und sofort verstehen, wo die wichtigen Objekte sind, erfüllt Ihre Hierarchie ihren Zweck.

Wichtiger Hinweis: Aufgrund der Optimierung der internen Szenengraph-Struktur der Engine ist die Reihenfolge der Entities auf oberster Ebene (Entities ohne Eltern) zufällig. Kinder-Entities haben jedoch eine festlegbare Reihenfolge, die Sie im Editor per Rechtsklick auf einzelne Entities nach oben, unten, ganz oben oder ganz unten verschieben können.

Entity-Eigenschaften und Tags

Entities können benutzerdefinierte Eigenschaften und Tags speichern.

Ein Gegner könnte zum Beispiel haben:

• Ein Damageable Tag.
• Eine health Eigenschaft.
• Eine team Eigenschaft.
• Eine patrolRadius Eigenschaft.

Skripte und Logik können diese Daten verwenden, um Entscheidungen zu treffen.

Ein Schadenssystem könnte nach Entities mit dem Damageable Tag suchen. Ein Gegnerskript könnte patrolRadius lesen, um zu entscheiden, wie weit der Gegner patrouillieren kann.

Eigenschaften und Tags ermöglichen es, einem Entity spielrelevante Bedeutung zu geben, ohne für jede kleine Datenmenge eine eigene Komponente zu benötigen.

Tags sind schneller abzufragen als Eigenschaften, daher eignen sie sich besser zur Identifikation, z.B. ob ein Entity Schaden empfangen kann oder ein Gegner ist. Sie tragen aber keinen Wert. Eine Eigenschaft ist langsamer abzufragen, hat aber einen Wert. Eigenschaften sind in Code gesehen tatsächlich Python-Dictionaries.

Vorschau von Entity-Templates

Manche Entities sind Instanzen von Entity-Templates. Der Spieler, den Sie im Standard-Cave-Projekt finden, ist zum Beispiel eine Instanz des folgenden Templates:

Template-Instanzen werden im Scene Graph anders dargestellt, sie verwenden die Template-Farbe von Cave. Das hilft Ihnen zu erkennen, dass ein Entity von einem wiederverwendbaren Template-Asset stammt.

Wenn ein Entity eine Template-Instanz ist:

• Deren interne Kinder zum Template gehören.
• Die platzierte Instanz zur Szene gehört.
• Die Template-Struktur wird bearbeitet, indem das Template-Asset geöffnet wird.
• Lokale Werte können weiterhin angepasst werden, wenn sie als Eigenschaften freigegeben sind.

Die nächste Lektion erklärt Entity Templates ausführlicher.

Das Entity-Mentalmodell

Betrachte eine Entity wie einen kleinen Behälter:

• Der Name hilft dir, sie zu verstehen.
• Die ID hilft Cave, sie zu verfolgen.
• Der Aktivzustand steuert, ob sie teilnimmt.
• Der Elternteil bestimmt, wo sie gehört.
• Die Komponenten definieren, was sie tut.
• Die Eigenschaften und Tags beschreiben zusätzliche Spieldaten.

Das ist der Kern des Szenenaufbaus in Cave.

Sobald Entities verständlich sind, wird der Scene Graph viel mehr als eine Liste von Objekten. Er wird zur Struktur deiner Spielwelt.