Empfohlen Neu Dev-Blog: Ein neues Questplugin für Terraconia

Seit vielen Jahren vermissen wir auf Terraconia die täglichen Quests. Doch seit einiger Zeit arbeite ich daran, diesen Umstand zu ändern.

Im Laufe der Zeit hat sich Terraconia immer weiter entwickelt, weswegen die damaligen Quests nicht mehr funktioniert haben. Damit wurde ein neues Plugin zwingend notwendig.

Voraussetzungen für ein Quest-Plugin

Da wir ein Quest-Plugin möglichst flexibel einsetzen möchten, haben wir auf Terraconia einige Anforderungen an so ein Plugin:

• Unterstützung von mehreren Servern:
  Wir möchten auf Terraconia Quests anbieten, die auf unterschiedlichen Servern anfangen, bearbeitet und beendet werden können. Während damals die täglichen Quests immer in der Farmwelt-Lobby angenommen werden mussten, muss das ja nicht so bleiben.
• Einfache Erstellung von Quests:
  Nicht jeder auf Terraconia ist ein Entwickler und wir brauchen keinen zu komplexen Aufbau. Daher sollte das Erstellen einer Quest möglichst einfach erfolgen. Entweder mittels Webeditor oder in einem Texteditor mit Syntax-Prüfung.
• Einbindung von Denizen um einfach NPCs einzubinden:
  Mit Denizen haben wir bereits ein externes Plugin, mit dem man sehr gut NPCs erstellen und deren Verhaltensweise ändern kann. Dieses Plugin funktioniert bereits gut und mit einer eigenen Erweiterung können wir bereits auf unser eigenes System zugreifen. Dadurch können NPCs Geld mit einem Grund vergeben, einem Spieler ein Easteregg hinzufügen oder Spieler serverübergreifend teleportieren. Um flexibel zu bleiben, sollte das Quest-Plugin auch Denizen entsprechend einbinden und unterstützen.

Auf dem Plugin-Markt gibt es bereits viele Plugins, die in diese Art gehen. Doch ein System wir Terraconia ist einzigartig und ich konnte kein Plugin finden, was uns wirklich zufrieden stellt. Daher habe ich mich für eine Selbstentwicklung entschieden.

Konzeptionierung

Am Anfang einer Entwicklung steht immer die Konzeptionierung. Für mich war die Struktur einer Quest der grundlegende Punkt.

Eine Quest beinhaltet verschiedene Attribute. Zum Beispiel einen Namen oder eine Beschreibung. Zum anderen die notwendigen Schritte, die man in einer Quest erledigen muss.

Mit etwas Überlegung erhält man dann schon eine Datenstruktur:

• Name: Der Anzeigename, der für den Spieler an allen möglichen Stellen angezeigt wird, z.B. Tagesquest
• ID: Die interne ID, die wir für die Speicherung und Referenzen nutzen, z.B. daily-quest
• Beschreibung: Eine Beschreibung der Quest, z.B. "Erledige deine tägliche Aufgabe in der Farmwelt."
• Stages: Eine Liste an Schritten, die in der Quest erledigt werden müssen.
• Zeitlimit der Quest: Wann die Quest erledigt sein muss. Innerhalb 24 Stunden? Oder am selben Tag?

Und jede Stage hat dann noch einmal mehrere Attribute und Optionen.

• Typ: Der Typ der Stage, z.B. ob man Monster töten soll, zu einer Position gehen soll oder ob man mit einem NPC sprechen soll.
• Rank: Die höhe der Stage. Eine Möglichkeit, um eine Stage zu referenzieren.
• Beschreibung: Eine Beschreibung, was man in der Stage machen muss.
• Nachrichten beim Beitritt bzw. beim Verlassen einer Stage, die man erhält, wenn man die Stage erfüllt hat.
• Und weitere Attribute, abhängig vom Typ.

Hierbei fehlen sicherlich noch einige Optionen, aber damit sollte eine Quest bereits funktionieren.

Bei der Entwicklung kann nun diese Struktur in entsprechende Java-Klassen umgeformt werden. Diese dienen als Speicher der Attribute und helfen bei der Erstellung eines neuen Kontexts bestehend aus Spieler, Quest und aktueller Quest-Stage, wenn eine Quest gestartet wird.

Konfiguration einer Quest

Nun steht also die Daten-Struktur. Doch ohne eine Dokumentation, verstehe selbst ich nicht, was für Attribute die Stages haben. Während also die Java-Struktur entwickelt wurde, habe ich mir parallel auch Gedanken zum Erstellen von Quests gemacht.

Ein Web-Editor hört sich ganz nett an, führt aber zu einer höheren Komplexität. Zudem können wir Textdateien einfacher vergleichen und versionieren, als Daten aus einem Web-Editor. Doch auf der anderen Seite ist eine einfache Textdatei bei der Erstellung von Quests zu komplex.

Da Yaml-Dateien in Minecraft schon weit verbreitet sind, habe ich mich für das Format entschieden. Das Format hat den Vorteil, dass wir bereits Tools für die Validierung haben, die Dateien einfach geladen werden können und wir ein Schema erstellen können, welches die Quest-Dateien beschreibt. Ein solches Schema beinhaltet die Syntax von den Quest-Dateien, wie vorhandene und notwendige Felder, Beschreibungen zu den Feldern und einfache Datenvalidierung. Das Schema wird mit dem Quest-Plugin gepflegt und automatisch durch unsere Entwicklungs-Infrastruktur bereit gestellt.

Da unsere NPC-Ersteller bereits VSCode zum Erstellen von NPCs nutzen, kann dieser Editor auch zu der Erstellung von Quest-Dateien genutzt werden. Mittels der Projekteinstellungen wird dann das Schema automatisch heruntergeladen. Damit wird beim Erstellen von Quests automatisch geprüft, ob eine Quest auch eine gültige Syntax hat.

So fehlt bei der Beschreibung von dieser Stage die Anzahl an Steine, die benötigt werden:

Auch Vorschläge für mögliche Felder sind somit einfach möglich:

Die Dateien mit den Quests werden nach der Erstellung in unser Versionssystem geladen. Dadurch können wir die Historie von den Quests sehen und haben Möglichkeiten auch gemeinsam an diesen Quests zu arbeiten. Mittels Minecraft-Befehlen kann der aktuelle Stand aus dem Versionssystem geladen werden.

Da das Versionssystem automatisch Aufgaben ausführen kann, können wir somit automatisch die Syntax der Quests beim Upload testen. Somit werden fehlerhafte Quest-Dateien schnell erkannt:

Somit kann auch das Erstellen von neuen Quests deligiert werden und man muss kein Pluginentwickler sein, um die Syntax zu verstehen. Eine ausführliche Dokumentation muss dazu nicht gepflegt werden, weil das Schema bereits fast alle notwendigen Informationen beinhaltet. Gleichzeitig sind wir sehr flexibel bei der Erarbeitung von neuen Quests und können das bestehende Quest-Plugin bequem um neue Funktionalität erweitern.

Eine vollständige Quest kann dann so aussehen. Die Gespräche mit einem NPC werden in einem Skript vom Denizen-Plugin beschrieben:

Aktueller Stand

Ein "Proof of Concept" (erster Teststand mit minimaler funktionierender Quest) funktioniert bereits auf unserem Testserver. Dabei können wir eine Quest über einen Befehl starten, Mobs töten oder Blöcke abbauen und die Quest wird korrekt abgeschlossen. Die Kernfunktionalität ist somit implementiert, doch einige Themen sind noch offen:

• Einige Quests soll man nur unter bestimmten Umständen starten können. Entweder, weil die Quest auf einer anderen aufbaut, oder weil sie nur einmalig oder einmal am Tag ausgeführt werden können soll. Diese Bedingungen fehlen noch vollständig.
• Mögliche Questziele müssen noch erweitert werden. Im aktuellen Zustand kann man nur mit NPCs sprechen, Blöcke abbauen oder Mobs töten. Ziele wie "eine bestimmte Zeit warten" oder "zu einer Region gelangen" müssen erst noch implementiert werden.
• Offene Quests müssen noch in einer sinnvollen Variante an zentraler Stelle zusammen gefasst werden. Dazu soll ein Journal (ausgeführt als aufrufbares Buch) erstellt werden, bei dem Informationen zu allen aktuellen Aufgaben vorhanden sein soll. Der erste Ansatz muss dazu noch weiter ausgearbeitet werden, inklusive dem Layout und der Farbwahl:
  

Die Arbeit an dem Plugin wird in den kommenden Wochen weiter gehen und es wird noch etwas dauern, bis wir das Quest-Plugin auf dem Hauptsystem spielen können. Dennoch hoffe ich, dass wir zeitnah die ersten einfachen Quests auf Terraconia haben können.