Cave: Einstiegshandbuch
Verstehen von Entitäten
Lesson 9 of 19 • 25 XP
Keep your place in this quest
Log in or sign up for free to subscribe, follow lesson progress, and access more learning content.
Verständnis von Entities
Jetzt lass uns das Konzept einer Entity in Cave verstehen. Entities sind die grundlegenden Objekte innerhalb einer Cave-Szene.
Wenn eine Szene ein Level, ein Menü oder ein Testbereich ist, sind Entities die Dinge, die in diesem Bereich existieren. Zum Beispiel können ein Spieler, ein Feind, eine Tür, ein Licht, eine Kamera, ein Trigger, ein UI-Button, eine Klangquelle und ein Ordner alles Entities sein.
In dieser Lektion wirst du lernen über:
- Namen.
- IDs.
- Aktive Zustände.
- Eltern-Kind-Beziehungen.
- Ordner.
- Hierarchie-Reihenfolge.
- Tags und Eigenschaften.
- Vorlageninstanzen.
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 eine Entity?
Eine Entity ist ein Objekt in einer Szene.
Eine Entity kann darstellen:
- Ein sichtbares 3D-Objekt.
- Einen unsichtbaren Helfer.
- Einen Gameplay-Trigger.
- Ein UI-Element.
- Eine Klangquelle.
- Oder einfach einen Ordner zur Organisation.

Zum Beispiel ist eine Kiste eine sichtbare Entity. Ein Spawnpunkt kann während des Gameplays unsichtbar sein, ist aber trotzdem eine Entity, da er markiert, wo etwas passieren soll.
Cave hält diese Idee einfach: Szenen bestehen aus Entities.
Entities sind Komponententräger
Entities tun alleine nicht viel, ihre Funktionen kommen von Komponenten. Zum Beispiel:
| Entity | Komponenten, die sie haben könnte |
|---|---|
| Kiste | Transform, Mesh, Rigid Body. |
| Spieler | Transform, Charakter, Kamera, Python, Audio. |
| Tür | Transform, Mesh, Rigid Body, Logic Bricks. |
| Fackel | Transform, Mesh, Licht, Audio. |
| Button | Transform, UI-Element, Logic Bricks oder Python. |
| --- |
Deshalb sind Entities flexibel. Eine Tür ist kein völlig separater, fest codierter Objekttyp. Es ist eine Entity, die aus Teilen besteht: einem Mesh, um sie zu sehen, Kollision zur Blockierung des Spielers und Logik, um sie zu öffnen oder zu schließen.
Wenn du das verstehst, wird das Erstellen von Objekten praktikabler. Du hörst auf zu fragen: "Welchen Objekttyp brauche ich?" und beginnst zu fragen: "Welche Komponenten benötigt diese Entity?"
Entity-Namen
Jede Entity hat einen Namen. Du kannst eine Entity über ihr Schnellbearbeitungsmenü im Scene Graph oder im Properties-Tab umbenennen.
Es ist erwähnenswert, dass Namen zuerst für Menschen gedacht sind:
- Sie machen den Scene Graph leichter durchsuchbar.
- Sie erleichtern das Debugging.
- Sie erleichtern es, mit Teamkollegen über Objekte zu sprechen.
- Sie helfen dir, deine eigene Szene später zu verstehen.
Cave erfordert nicht, dass jeder Entity-Name einzigartig ist. Mehrere Entities können denselben Namen teilen, was nützlich für wiederholte Objekte wie Steine, Münzen, Kisten oder Feinde ist.
Behandle den Namen jedoch nicht als den einzigen verlässlichen Identifikator für eine Entity.
Gute Namen sind einfach und beschreibend:
| Schwacher Name | Besserer Name |
|---|---|
Mesh |
Holzkiste |
Empty |
Spieler Start |
Light |
Höhleneingangslicht |
Folder |
Feindgruppe |
Das Ziel ist nicht, Namen ausgefallen zu gestalten. Das Ziel ist es, die Szene lesbar zu machen.
Entity-Namen können auch im Code verwendet werden, um eine bestimmte Entity aus deiner Szene abzufangen, aber da du bereits weißt, dass mehrere Entities denselben Namen haben können, solltest du dir auch bewusst sein, dass wenn du eine Entity nach ihrem Namen abfragst und es mehrere Entities mit diesem Namen gibt, dies zu undefiniertem Verhalten führen kann, da du keine Garantie dafür hast, welche Entity die Szene für diesen Namen zurückgibt. Es wird die erste zurückgeben, die bei der Suche nach deiner Abfrage gefunden wird. Wenn es dir wichtig ist, ein bestimmtes Objekt durch Code zu erhalten, wie den Spieler, stelle sicher, dass du ihm einen eindeutigen Namen gibst.
Entity-IDs
Cave verfolgt Entities intern mit einzigartigen IDs.
Normalerweise musst du diese IDs nicht bearbeiten oder dir darüber Gedanken machen. Sie existieren, damit die Engine Entities zuverlässig identifizieren kann, auch wenn Namen wiederholt werden. Tatsächlich sind einzigartige IDs unveränderlich, was bedeutet, dass du sie nicht ändern kannst. Sie werden automatisch von der Engine zugewiesen.
Denk daran:
| Ding | Zweck |
|---|---|
| Name | Hilft dir, die Szene zu lesen. |
| ID | Hilft Cave, das Objekt intern zu verfolgen. |
Wenn zwei Feinde beide Enemy heißen, kann Cave sie hinter den Kulissen trotzdem unterscheiden.
Aktiver Zustand der Entity
Entities können aktiv oder inaktiv sein.

Im Scene Graph und im Properties-Tab wird dies mit einer augenähnlichen aktiven Steuerung angezeigt.
| Zustand | Bedeutung |
|---|---|
| Aktiv | Die Entity nimmt normal an der Szene teil. |
| Inaktiv | Die Entity bleibt in der Szene, ist jedoch deaktiviert. |
Je nach Entity und ihren Komponenten kann die Deaktivierung Auswirkungen haben auf:
- Rendering.
- Physik.
- Logik.
- Laufzeitaktualisierungen.
- Verhalten der Komponenten.
Eine deaktivierte Entity wird keine ihrer Komponentenaktualisierungen aufrufen und in dem Moment, in dem du eine Entity deaktivierst, wird auch die Endmethode der Komponenten aufgerufen, und wenn du sie wieder aktivierst, wird die Startmethode der Komponenten aufgerufen.
Du kannst sicher davon ausgehen, dass eine deaktivierte Entity nicht zur Physikberechnung, Logik, Trigger usw. der Szene beitragen wird. Es sei denn, du fragst manuell diese Entities aus der Szene ab und ignorierst die Tatsache, dass sie deaktiviert sind, natürlich.
Die praktische Idee ist einfach: inaktiv bedeutet „hier behalten, aber momentan nicht teilnehmen.“
Deaktivieren vs. Löschen
Deaktivieren und Löschen sind nicht dasselbe.
| Aktion | Ergebnis |
|---|---|
| Deaktivieren | Hält die Entity in der Szene, schaltet sie aber aus. |
| Löschen | Entfernt die Entity aus der Szene. |
Deaktiviere eine Entity, wenn du sie später möglicherweise wieder möchtest. Lösche eine Entity, wenn du dir sicher bist, dass sie entfernt werden sollte.
Für Tests ist Deaktivieren oft sicherer. Wenn ein Feindbegegnung zu schwer erscheint, deaktiviere zuerst ein paar Feinde und teste das Level. Wenn sich die Änderung richtig anfühlt, kannst du die Szene später bereinigen.
Entities Parent-Kind-Beziehungen
Entities können anderen Entities untergeordnet werden.
Wenn eine Entity einen Elternteil hat, wird sie Teil der Hierarchie dieses Elternteils. Wenn du den Elternteil bewegst, bewegt sich auch das Kind mit ihm.
Parenting ist nützlich für:
- Ein Schwert, das an einem Charakter befestigt ist.
- Ein Licht, das an einer Fackel befestigt ist.
- Eine Kamera, die an einem Fahrzeug befestigt ist.
- Eine Gruppe von Requisiten, die unter einem Ordner organisiert sind.
- UI-Elemente, die unter einem übergeordneten Panel gruppiert sind.
Parenting beeinflusst auch die Transformationen. Die Transformation einer Kind-Entity wird relativ zur Elternhierarchie bewertet.
Dies ist eine der einfachsten Möglichkeiten, verwandte Objekte zusammenzuhalten.
Ordner-Entities
Ordner-Entities werden zur Organisation verwendet. Sie sind besonders hilfreich, wenn deine Szene beginnt, viele Objekte zu enthalten.
Definitionsgemäß besteht das, was eine Entity zu einem Ordner macht, hauptsächlich im Fehlen von Komponenten in ihr, insbesondere einer Transform- und einer UI-Element-Komponente, denn wenn eine Entity keine Transformation in der Welt hat und kein UI-Element hat, wird sie wahrscheinlich als Ordner verwendet. Aber das ist größtenteils eine Namenskonvention, also behalte das im Hinterkopf.
Häufige Ordnergruppen umfassen:
- Umwelt.
- Gameplay-Trigger.
- Feinde.
- Requisiten.
- Beleuchtung.
- UI.
- Audio.
- Debug-Helfer.
Ordner sind nicht nur für die Übersichtlichkeit da. Ein sauberer Scene Graph hilft dir, schneller zu arbeiten, weil du das benötigte Objekt finden kannst, ohne durch Hunderte loser Entities suchen zu müssen.
Reihenfolge der Entity-Hierarchie
Die Reihenfolge der Entities im Scene Graph ist für die Organisation wichtig, und in einigen Fällen kann es wichtig sein, wie Dinge verarbeitet oder angezeigt werden.
Wenn du einen Ordner öffnest und die folgende Struktur siehst, ist das schwerer zu scannen:
Kiste
Spieler
Licht
Feind
Kamera
Stein
Trigger
Aber das hier ist einfacher:
Spieler
Kamera
Beleuchtung
Feinde
Umwelt
Gameplay-Trigger
Das Ziel ist nicht, die Hierarchie fancier zu gestalten, sondern sie nützlich zu machen.
Wenn du eine Szene nach einer Woche Abwesenheit öffnen kannst und sofort verstehst, wo sich die wichtigen Objekte befinden, erledigt deine Hierarchie ihren Job.
Wichtiger Hinweis: Aufgrund der Art und Weise, wie die Engine ihren internen Scene Graph optimiert, wird die Reihenfolge, in der die Entities auf oberster Ebene erscheinen, d. h. Entities, die keinen Elternteil haben, zufällig sein, aber Kindentities, die Kinder, können eine spezifische Reihenfolge haben, und du kannst sie organisieren, indem du mit der rechten Maustaste auf jede einzelne Entity im Editor klickst und sie nach oben oder unten oder zum Anfang oder Ende bewegst.
Eigenschaften und Tags von Entities
Entities können benutzerdefinierte Eigenschaften und Tags speichern.
| Merkmal | Zweck |
|---|---|
| Eigenschaft | Speichert einen bearbeitbaren Wert. |
| Tag | Fügt ein Label zur Identifikation oder Gruppierung hinzu. |
Zum Beispiel könnte ein Feind:
- Ein
Damageable-Tag haben. - Eine
health-Eigenschaft haben. - Eine
team-Eigenschaft haben. - Eine
patrolRadius-Eigenschaft haben.
Skripte und Logik können diese Daten nutzen, um Entscheidungen zu treffen.
Ein Schadenssystem könnte nach Entities mit dem Damageable-Tag suchen. Ein Feindskript könnte patrolRadius lesen, um zu entscheiden, wie weit der Feind umherwandern kann.
Eigenschaften und Tags erlauben es dir, einer Entity gameplay-relevante Bedeutung zuzuweisen, ohne für jedes kleine Datenstück eine spezielle Komponente benötigen zu müssen.
Tags sind schneller abzufragen als Eigenschaften, daher sind sie besser geeignet, um eine Entity zu identifizieren, die Schaden erhalten kann oder ein Feind ist usw. Aber sie tragen keinen Wert in sich. Eine Eigenschaft ist langsamer abzufragen, aber du kannst einen Wert hinzufügen. In Bezug auf das Programmieren sind Entity-Eigenschaften buchstäblich Python-Dictionaries.
Vorschau auf Entity-Vorlagen
Einige Entities sind Instanzen von Entity-Vorlagen. Der Spieler, den du im Standard-Neuen-Cave-Projekt finden wirst, ist zum Beispiel eine Instanz dieser Vorlage hier:

Vorlageninstanzen werden im Scene Graph anders angezeigt, indem die Vorlagefarbe von Cave verwendet wird. Dies hilft dir, zu erkennen, dass die Entity aus einem wiederverwendbaren Vorlagen-Asset stammt.
Wenn eine Entity eine Vorlageninstanz ist:
- Die internen Kinder gehören zur Vorlage.
- Die platzierte Instanz gehört zur Szene.
- Die Struktur der Vorlage wird bearbeitet, indem man das Vorlagen-Asset öffnet.
- Lokale Werte können weiterhin angepasst werden, wenn sie als Eigenschaften exposed sind.
Die nächste Lektion erklärt die Entity Templates detaillierter.
Das mentale Modell der Entität
Denke an eine Entität wie an einen kleinen Behälter:
- Der Name hilft dir, sie zu verstehen.
- Die ID hilft Cave, sie zu verfolgen.
- Der aktive Zustand steuert, ob sie daran teilnimmt.
- Der Elternteil steuert, wo sie hingehört.
- Die Komponenten definieren, was sie tut.
- Die Eigenschaften und Tags beschreiben zusätzliche Spieldaten.
Das ist der Kern des Szenenaufbaus in Cave.
Sobald Entitäten Sinn machen, wird das Szene-Graphen viel mehr als nur eine Liste von Objekten. Es wird zur Struktur deiner Spielwelt.