Dev-Blog: Wenn Entwickler zu viel Zeit haben

Immer mehr Menschen beschweren sich, dass so wenig passieren würde. Ich möchte hier einmal kleinere Spielereien von mir vorstellen.

Hauptsächlich beschäftige ich mich derzeit in meiner Thesis damit, einem herumfahrenden Roboter beizubringen, was ein Ball ist und wie man diesen in ein Tor schießt.
Dazu steht mir eine relativ nette Kamera mit Tiefenbild und Farbbild zur Verfügung. Der Roboter existiert bereits, meine Aufgabe ist die Bilderkennung und die Pfadfindung.
Alles in allem eine Aufgabe, die mich noch einige Wochen beschäftigen muss, bevor ich Anfang Mai eine Vollzeitstelle als Entwickler anfange.
(Kamera: Intel D435i, eingesetzte Bibliotheken: RealSense und OpenCV, Programmiersprache: C++)

Interessant ist es auf jeden Fall, aber wohl weniger Minecraft-Relevant.
Doch für Minecraft habe ich auch das ein oder andere. Das Update auf 1.13 lässt lange auf sich warten, Schuld bin wohl ich daran. Ich habe entschieden, einige Codeteile zu überarbeiten, dazu gehört das "Bedieninterface" des Städteplugins.

Neu mit der 1.13 sind beispielsweise Befehlsvorschläge im Chat, welche ähnlich wie beim Tabben die Vorschläge anzeigen. Dabei lässt sich dann auch die Syntax von Befehlen anzeigen etc.
Bereits im Dezember habe ich ein CommandFramework getestet, was das Erstellen von Befehlen vereinfacht und TabCompletes unterstützt. Dies habe ich auf das Städteplugin angewendet. Dabei sind mehrere tausend Code-Zeilen verändert worden:

In Folge meines Testens und "Spielens" ist dann auch eine Ingame-Befehlsliste entstanden.
Dabei lassen sich FAQ- und Wiki-Einträge mit jedem Befehl verbinden und sind über das entsprechende Symbol vor dem Befehl aufrufbar. Als Tooltip bieten inzwischen die meisten Befehle eine Kurzbeschreibung an.

Als letzte Spielerei mit dem Städteplugin habe ich außerdem eine API ausprobiert, um Inventare zu öffnen.
Was anfangs als kleinere Spielerei angefangen hat, hat mich nach und nach immer mehr begeistert.
Inzwischen lassen sich auf dem Testserver bereits umschaltbare Flags wie Handelslizenz, Ranken, TNT, Elytra-Nutzung und Wetterstation per Inventar einstellen.

Zwar habe ich noch einige andere Ideen, aber diese sind noch weniger spruchreif.
Leider liegt die aktuelle Priorisierung meiner Arbeiten auf dem ersten Thema. Ich bin zuversichtlich, dass irgendwann auch die anderen Ideen auf Terraconia Einzug halten und auch, dass es eines Tages ein 1.13-Update geben wird. Und hätte ich nicht angefangen, mit neuen Features zu spielen, wäre das auch bereits längst passiert

Zu der Weihnachtszeit möchte ich gerne diesen Thread ausgraben.

In der Zwischenzeit warten viele Spieler auf die 1.14.4. Leider ist es mir nicht möglich, alles so schnell zu erledigen, wie ich es gerne täte.
Da nun zwischenzeitlich die 1.15 erschienen ist, habe ich mich entschieden, die Version 1.14 zu überspringen und direkt auf die 1.15 zu aktualisieren.

Diese Bienen in der 1.15 sind aber auch süß.

Das 1.15 Update sollte dann Anfang nächsten Jahres auf Terraconia Einzug halten.

In den letzten Wochen habe ich viele Plugins aktualisiert. Neben Bugfixes und Anpassungen an neue Begebenheiten, gab es kaum Zeit, neue Sachen auszuprobieren.

Als ich dann irgendwann mal wieder am Origo-Spawn durch die Gegend gesprungen bin, sind mir die in die Jahre gekommenen Wegweiser aufgefallen.
Dabei hab ich mich schon immer gefragt, wer versteht, was diese Schilder denn überhaupt aussagen. Und vor allem - welcher Neuling diese Schilder denn wirklich zur Orientierung nutzt.

Eine mögliche Lösung war schnell gefunden: Man nutzt ein Hologramm als Wegweiser. Das große Problem: Viele Hologramme auf kleinem Raum sind unübersichtlich und man sieht das Hologramm auch aus der "falschen" Richtung. Wenn man also einen Wegweiser zum Spawnschiff sieht, dann ist dieser nur von einer Seite richtig.
Aber man kann ja in Minecraft vieles machen, so auch mit dem zuständigen Plugin HolographicDisplays. Dieses bietet an, Hologramme nur einzelnen Spielern zu zeigen. Und nach etwas programmieren, testen und bugfixen ist es nun möglich, ein Hologramm nur für Spieler sichtbar zu machen, die in einer speziellen Region sind.

Diese neuen Wegweiser sollten mit dem 1.15.2 Update auf Terraconia möglich sein. Wie und ob diese dann auch in Städten einsetzbar sind, muss ich noch überlegen. Ein großes Problem ist, dass die Speicherung der Wegweiser durch eine WorldGuard-Region erfolgt, wie es auch bei Grundstücken, Apartments und PvP-Arenen der Fall ist. Zu viele Regionen innerhalb einer Stadt führen unter Umständen zu Problemen bei der Verwaltung und bei der Auflösung von Städten.

Als @MeeriSchatz die ein oder andere Verbesserung erwähnt hat, war auch diese gemeint.

Bei meinen letzten Änderungen für die 1.16 wurde mir eins klar: Unser System serverübergreifend Inventare zu synchronisieren ist blöd.

Spielerisch mag das schön sein, dass das Inventar von Esconia, Andora und von der Farmwelt gleich ist. Technisch ist das sehr aufwendig.
Minecraft in seiner ursprünglichen Form weiß nicht, was ein Netzwerk aus mehreren Servern ist. Noch weniger ist Minecraft davon begeistert, Spielerdaten mit anderen Servern zu teilen. Und doch hat Terraoconia ein System gefunden, wie man Inventare verteilt. Doch mit diesem System gibt es immer mehr Probleme, weswegen nun eine Überarbeitung ansteht.

Doch der Reihe nach:
[headline]Was sind die aktuellen Probleme[/headline]
Wir nutzen gegenwärtig ein eigenstehendes Plugin. Dieses wurde einst von einem anderen Entwickler programmiert, der dieses Plugin als OpenSource-Projekt angeboten hat. Doch seit der Version 1.13.2 häufen sich immer mehr Probleme, neuere Versionen ab 1.14 werden von diesem Plugin gar nicht unterstützt.

Und auch die Updates von Minecraft laufen nicht sonderlich rund. Immer wieder gibt es bei Updates Probleme, sodass einzelne Spieler Inventare mysteriös verlieren. Zudem gehen ab und an mal einzelne Items verloren, wenn man den Server wechselt.

Und zu guter letzt ist die spärliche Dokumentation von dem Plugin auf chinesisch.

[headline]Anforderungen[/headline]
Die Probleme beim bestehenden Plugin sind massiv. Ich kann mir nicht vorstellen, dass dieses durchaus komplexe Plugin für uns eine zufriedenstellende Zukunft darstellt. Daher habe ich selbst schon länger die Idee im Kopf, selbst ein System dafür zu erstellen.
Dabei sind folgende Anforderungen entstanden:

• Speicherung von Inventaren (Spieler + Enderchest), Leben, Hunger, Effekten, vorhandene Luft, vorhandenes Feuer etc. in einer Datenbank
• möglichst Versionsunabhängig: Versionsanpassungen sollten einfach geschehen
• Versionsupdates sollen problemlos möglich sein: Inventare sollen automatisch auf die neue Version aktualisiert werden.
• Einfache Erweiterung von Daten, die gespeichert werden sollten
• Keine Limitierung von Inventargrößen

Das ist also durchaus eine Liste von Anforderungen für so ein System. Und da ich alle Spieler verstehen kann, die Angst vor Inventarverlusten haben und ich Angst vor Duplizierungsbugs habe, sollte das alles noch möglichst zuverlässig sein.

[headline]Umsetzung[/headline]
Diese Liste an Anforderungen umzusetzen ist gar nicht so einfach. Man greift in Bereiche von Minecraft ein, die normalerweise nicht angefasst werden. Kaum ein Server synchronisiert die Inventare serverübergreifend.

Um das Problem effizient und möglichst einfach anzugehen, war schnell die Idee vorhanden, tief an der Wurzel anzusetzen. Das Grundkonzept war spätestens dann gefestigt, als mit der 1.15.2 wir uns eine eigene Serversoftware angeschafft haben, um einzelne Änderungen an der Servermechanik vornehmen zu können:

• Die Spielerdaten (NBTTags) werden in eine Datenbank gespeichert.
• Die Datenbank verwaltet, welcher Server aktuell das Inventar "offen" hat.
• Beim Login werden aus der Datenbank die Spielerdaten geladen und dem Spieler zugewiesen.
• Beim Logout werden die Spielerdaten wieder in die Datenbank geschrieben.
• Gespeichert werden die Rohdaten von Minecraft (für die technikaffinen: Gespeichert wird ein byte-Array als Blob in die Datenbank).

Somit gibt es ein Zusammenspiel zwischen einem Plugin und dem Server: Der Server übergibt dem Plugin Daten zum Speichern, das Plugin schiebt diese Daten dann in die MySQL-Datenbank. Dieses Zusammenspiel sollte aber möglichst reibungslos sein.

[headline]Klingt einfach?[/headline]
Ja gut, da fehlt ja noch eine Sache:
Wenn ein Spieler einen Server wechselt, werden auf dem neuen Server erst die Spielerdaten geladen, bevor auf dem alten Server die Spielerdaten gespeichert werden. Das bedeutet, dass der alte Server das Inventar nicht gespeichert hat, wenn der neue Server es haben möchte.

Die Lösung dazu ist dann etwas komplexer: Nach dem Serverwechsel wird der Spieler festgefroren. Er steht zwar in der Welt, kann sich aber selbst nicht bewegen. Regelmäßig wird dann versucht, das Inventar nachzuladen, sodass der alte Server dieses abspeichern kann. Nach dem Laden des Inventars werden die neuen Daten auf den Spieler angewendet und sein gefrorener Zustand wird beendet.

Technisch fehlt hier noch, dass der alte Server über das erfolgreiche Speichern den neuen Server benachrichtigt, aber das sollte technisch nicht sonderlich aufwendig sein.

[headline]Aktueller Stand[/headline]
Auf dem Testserver sind gegenwärtig einige Server bereits auf der 1.16.1. Dort ist bereits das neue Inventarsystem im Probesystem und scheint auch zu funktionieren. Allerdings gibt es hier noch einige offene Punkte, z.B. fehlen noch Fehlerbehandlungen bei Abstürzen von Servern und verschiedene Hilfsfunktionen.

Alles in allem ist dies wieder ein Projekt, wo man etliche Stunden investiert. Ich schätze den Aufwand für das Inventarsystem auf 60-80 Arbeitsstunden, für das komplette 1.16.1-Update wir noch einiges mehr an Zeit drauf gehen.

Wie man sehen sollte, ist so ein "einfaches Inventaresynchronisieren" mehr Arbeit als gedacht.