In der vorherigen Lektion hast du gelernt, wie Python Entitäten während des Spiels steuern kann. Aber Python in Cave ist nicht nur auf das laufende Spiel beschränkt. Du kannst es auch verwenden, um Editor Tools zu erstellen, die dir helfen, dein Spiel schneller zu bauen.

Das ist besonders nützlich, da viele Projekte sich wiederholende Aufgaben haben. Vielleicht platzierst du oft Gegner, erstellst Checkpoints, organisierst Ordner, testest Werte oder untersuchst Szenendaten. Statt jedes Mal alles von Hand zu machen, kannst du kleine Werkzeuge erstellen, die Teile deines Workflows automatisieren. Du kannst sogar komplexere Editoren erstellen, die prozedural generierte Level, prozedurale Gebäude und vieles mehr ermöglichen.

In dieser Lektion lernst du:

Den Unterschied zwischen Gameplay-Skripten und Editor-Skripten.
Wofür ein Editor-Tool verwendet werden kann.
Wie ein Editor-Tab-Tool aufgebaut ist.
Warum #editoronly wichtig ist.
Wann es sich lohnt, ein eigenes Tool zu erstellen.

Du musst nicht sofort Werkzeuge erstellen, wenn du anfängst, aber es ist gut zu wissen, dass dieses System existiert. Es ist eines dieser Features, das wertvoller wird, je größer dein Projekt wird.

Gameplay-Skripte vs Editor-Tools

Kurz gesagt:

Gameplay-Skripte laufen während das Spiel läuft.
Editor-Tools laufen im Editor, um dir bei der Arbeit am Projekt zu helfen.

Skripttyp	Läuft in	Beispiel
Gameplay-Skript	Play-Modus und exportiertes Spiel.	Spielerbewegung, Gegner-KI, Türen, Aufsammelobjekte.
Editor-Tool	Cave Editor.	Level-Helfer, Batch-Umbenennung, Szeneninspektor, prozedurale Gebäudegenerierung, Platzierungswerkzeug.

Ein Tür-Öffnungsskript ist beispielsweise Gameplay-Logik, weil der Spieler das während des Spiels erleben soll. Ein Tool, das zehn Fackeln entlang eines Korridors platziert, ist Editor-Logik, weil es dir beim Bau des Levels hilft, aber im exportierten Spiel nicht existieren muss.

Warum Editor-Tools nützlich sind

Anfangs klingen benutzerdefinierte Tools vielleicht nach etwas, das nur große Teams brauchen.

Aber selbst Solo-Entwickler profitieren von kleinen Tools, weil sie wiederholte manuelle Arbeit reduzieren. Wenn du dieselbe Aufgabe oft erledigst, kann ein einfaches Editor-Skript dein Projekt spürbar schneller machen.

Editor-Tools können bei Dingen helfen wie:

Platzieren von Gruppen von Entitäten.
Prüfen, ob erforderliche Komponenten fehlen.
Erstellen gängiger Szenen-Setups.
Ausgeben von Debug-Informationen.
Testen von Werten ohne den Play-Modus zu starten.
Designern helfen, Gameplay-Daten anzupassen.

Stell dir zum Beispiel vor, du baust ein Third-Person-Spiel mit vielen Gegnerlagern. Statt jedes Mal manuell dieselbe Ordnerstruktur zu erstellen, könntest du ein Tool bauen, das automatisch eine Enemy Group, einige Spawn-Punkte und ein Trigger-Gebiet anlegt.

Editor-Only-Skripte

Editor-Skripte beginnen normalerweise mit folgender Zeile:

#editoronly

Das teilt Cave mit, dass das Skript nur für die Verwendung im Editor gedacht ist.

Das ist wichtig, weil Editor-Tools APIs oder Verhalten verwenden können, die nur im Editor sinnvoll sind. Du möchtest normalerweise keinen Level-Design-Helfer oder Debug-Panel in deinem finalen Spiel- Runtime haben.

Außerdem sagt das Cave, welche Skripte beim Spielstart ausgeführt und welche ignoriert werden sollen. Standardmäßig werden alle Skripte ausgeführt. Wenn du möchtest, dass ein Skript ignoriert wird, sollte es diesen Kommentar als erste Zeile enthalten.

Wenn du also ein Skript erstellst, das nur dazu dient, dir im Cave Editor zu helfen, mache es zu einem Editor-only-Skript.

Editor-Tab-Tools

Eine häufige Methode, Werkzeuge zu erstellen, ist ein Editor-Tab.

Ein Editor-Tab ist ein benutzerdefiniertes Panel, das im Cave Editor erscheint. Es hat eine draw()-Methode, und Cave ruft diese Methode auf, solange der Tab sichtbar ist, damit das Werkzeug Buttons, Text, Eigenschaften und andere Steuerelemente zeichnen kann.

Ein sehr kleines Editor-Tab sieht so aus:

#editoronly
import cave

class ExampleTab(cave.ui.DebugTab):
    def __init__(self):
        super().__init__()
        self.counter = 0

    def draw(self):
        cave.ui.text("This is a sample tool.")
        cave.ui.separator()

        self.counter = cave.ui.prop("Counter", self.counter)

        if cave.ui.buttonDark("Increase counter +1"):
            self.counter += 1
            print("Counter increased by +1")

Dies ist auch der Standardcode, wenn du einen Editor-Tab hinzufügst. Wenn du ihn im Properties-Tab öffnest und dann zum Editor Tooling Tab wechselst, siehst du die Beispiel-Tab-Klasse als Debug-Tab. Dann musst du nur noch den Tab registrieren oder neu laden, und er ist in der Benutzeroberfläche verfügbar:

Dieses Beispiel ist einfach, aber zeigt schon die Grundidee:

cave.ui.DebugTab erstellt einen benutzerdefinierten Editor-Tab.
draw() definiert, was der Tab anzeigt.
cave.ui.text() zeichnet Text.
cave.ui.prop() zeichnet eine editierbare Eigenschaft.
cave.ui.buttonDark() erstellt einen Button.
print() kann verwendet werden, um Informationen an die Konsole zu senden.

So einfach ist es, eigene Tools für Cave Editor zu erstellen. Du kannst dieselbe Struktur später für echte Werkzeuge verwenden.

Was die `draw()`-Methode bedeutet

Die draw()-Methode ist nicht wie start() in einer Gameplay-Komponente.

Sie wird wiederholt aufgerufen, solange das Tool sichtbar ist, weil die Editor-Benutzeroberfläche gezeichnet und aktualisiert werden muss. Das bedeutet, der Code in draw() sollte die aktuelle Oberfläche des Tools beschreiben.

Zum Beispiel:

def draw(self):
    cave.ui.text("Level Helper:")

    if cave.ui.buttonDark("Create Enemy Group"):
        print("Create enemy group clicked")

Der Button wird jedes Mal gezeichnet, wenn der Tab aktualisiert wird, aber der Code im if wird nur ausgeführt, wenn der Benutzer den Button anklickt.

Dieses Muster ist in Editor-Tools sehr verbreitet.

Eine praktische Tool-Idee

Angenommen, du baust ein Level und brauchst oft dieselben Grundordner:

Environment
Enemies
Gameplay Triggers
Lighting
Audio
Debug Helpers

Du könntest ein Editor-Tool mit einem Button namens Create Level Folders erstellen. Beim Klick würde es diese Ordner-Entitäten automatisch in der aktuellen Szene anlegen. Denk daran: Ein Ordner im Scene Graph ist einfach eine Entität ohne Komponenten.

Das klingt vielleicht klein, aber solche Tools machen große Projekte leichter organisiert. Außerdem helfen sie dir, deine eigenen Projektkonventionen zu befolgen, ohne jeden Schritt manuell merken zu müssen.

Editor-Komponenten

Manchmal möchtest du Gameplay-Logik mit Editor-Logik mischen. Zum Beispiel möchtest du vielleicht eine Komponente an einer Entität anbringen, die auch Editor-Logik ausführt, etwa um Debug-Informationen oder eine Debug-Kugel anzuzeigen, die den Bewegungs- oder Angriffsradius eines Gegners markiert. In diesem Fall verwendest du statt cave.Component cave.EditorComponent.

Das ist nützlich, wenn eine Entität spezielles Editor-Verhalten braucht, das aber nicht Teil des eigentlichen Spiels sein soll.

Beispiele:

Ein Spawn-Punkt könnte Hilfsinformationen im Editor anzeigen.
Ein Trigger-Volumen könnte Debug-Steuerelemente bereitstellen.
Ein Level-Marker könnte prüfen, ob er korrekt konfiguriert ist.

Die wichtige Idee: Editor-Skripte dienen dem Workflow rund um die Spielegestaltung. Gameplay-Skripte gehören zum Spiel selbst.

WICHTIG: In diesem Fall ist das Verhalten etwas anders als bei einer normalen Komponente, da eine Editor-Komponente eine Editor-Update-Methode hat, die jedes Frame aufgerufen wird, solange der Editor läuft und das Spiel nicht. Aber, und das ist der wichtigste Unterschied, wird diese Komponente tatsächlich zusammen mit der Entität registriert, initialisiert und gestartet, unabhängig davon, ob sich das Spiel im Play-Modus befindet oder nicht. Wenn du also Logik in der Start-Methode dieser Komponente hast, wird sie auch außerhalb des Play-Modus aufgerufen.

Das kann potenziell gefährlich sein, zum Beispiel: Wenn du in der Start-Methode einer Editor-Komponente Logik einbaust, die alle Entitäten in der Szene löscht, wird dein Spiel im Editor vollständig und unwiderruflich gelöscht. Das ist kein Fehler oder Bug, sondern so gewollt. Sei dir dessen bewusst.

Wenn du es sicherer machen willst, kannst du die Python Code Component verwenden, denn diese hat eine Editor-Update-Methode, und wenn du darin Code schreibst, beeinflusst das nicht, ob Start- und End-Update im Editor aufgerufen werden (normalerweise nicht). Schau dir das Beispiel "Enemy" im Initialprojekt an, das Cave erstellt, dort wird die Python Code Component verwendet, um eine Debug-Kugel um die Gegner zu zeichnen, die den Radius anzeigt, in dem sie sich bewegen können. Das ist eine gute Möglichkeit, mehr darüber zu lernen.

Wann solltest du ein Tool bauen?

Erstelle nicht für jede kleine Ecke ein Tool.

Bau ein Tool, wenn es ein echtes Workflow-Problem löst, z. B.:

Du wiederholst dieselbe Aufgabe häufig.
Ein Setup ist leicht zu vergessen.
Eine Szene braucht Validierung.
Ein Designer braucht eine klarere Oberfläche, um Werte zu ändern.
Ein Prototyp braucht schnelle Debug-Buttons.

Als Anfänger solltest du zuerst das Spielobjekt manuell bauen. Erst wenn du die Schritte verstanden hast, kannst du den langweiligen Teil automatisieren.

Was du dir merken solltest

Python in Cave kann sowohl für Gameplay als auch für Editor-Tools verwendet werden.

Gameplay-Skripte steuern, was während des Spiels passiert. Editor-Skripte helfen dir, das Projekt im Cave Editor zu bauen, zu inspizieren, zu debuggen oder zu organisieren.

Du brauchst keine Editor-Tools, um dein erstes Spiel zu machen, aber sie sind sehr mächtig, wenn dein Projekt wächst. Ein kleines Tool, das heute fünf Minuten spart, kann später Stunden einsparen.

Cave: Erste Schritte Anleitung