Vorwort

Da das Netzwerk nun offiziell released ist und keine weitere Daten-Löschwelle mehr zu erwarten ist, möchten wir nun unseren Plan für das nächste halbe Jahr vorstellen. Viele von euch haben uns zu Beginn des Projektes gesagt, dass wir anstelle von wenigen großen Updates viele kleinere Updates bringen sollen. Dieser Ansicht sind wir ebenfalls. Allerdings steht eine Mammut-Aufgabe vor uns, die leider nicht schneller zu erledigen ist. Und ein Großteil der folgenden Updates hängt von dieser Roadmap ab. Um die Aufgaben umzusetzen, muss viel existierende Software geändert oder neu programmiert werden. Im Rahmen unseres Transparenz-Konzeptes geht diese Roadmap ins Detail der benötigten Änderungen. Es ist außerdem geplant, dass regelmäßig Updates zur Roadmap erscheinen werden, in denen ihr über den aktuellen Stand informiert werdet.

Aktueller Stand

Es ist keine Überraschung wenn ich schreibe, dass das Netzwerk insbesondere in den letzten Monaten von RewisServer Update-technisch vernachlässigt wurde. Es kamen viele Updates für die Lobby, was dazu führte, dass die ohnehin Lobby-lastige Community noch mehr mit Lobby-Singleplayer Aktivitäten verbringt.

Was besonders stark vernachlässigt wurde ist die Versionskompatibilität. Dies ist größtenteils darauf zurückzuführen, dass bei RewisServer damals möglichst zum Release der Version 1.9 die Elytra funktionieren mussten. Es wurde sehr viel Hoffnung in PixelGliders gesetzt. Wie alle mittlerweile wissen, ist PixelGliders ein Nieschen-Modus geworden. Allerdings stand man damals vor einem Problem. Die PvP Spieler wollten auf der 1.8 bleiben, während die 1.8 immer weniger möglichkeiten bot, neue, innovative Updates hervorzubringen. Plugins wie ViaVersion waren damals für unsere Standards zu Performance-lastig und wären ohnehin inkompatibel mit unserer Server-Software gewesen. Man hätte also damals entweder ViaVersion oder die Server-Software kompatibel machen müssen. Letzteres erwies sich als sehr aufwändig. Da die damalige Community nicht sonderlich für Versionen über der 1.8 zu begeistern war, hat man dieses Thema immer vor sich her geschoben. Bis Version 1.12 wurden durch Howaner noch regelmäßig Protokoll-Kompatibilitäten nachgerüstet.

Bis heute können Versionen über 1.12 das Netzwerk immer noch nicht betreten. Das soll nun geändert werden.

Das ist allerdings nicht die einzige Aufgabe dieser Roadmap. Es gibt viele, veraltete Systeme im Hintergrund, die man als unwartbar bezeichnen kann. Die Software ist größtenteils undokumentiert. Demnach kann sie nur von Leuten mit In-Depth-Wissen über die Funktionsweise der Software eingerichtet werden. Dieses Wissen, was von der ehemaligen Administration unter dem Begriff "Silo-Wissen" geführt wurde, haben wir glücklicherweise mehrfach im Team. Wir möchten zukünftig, dass unsere Software gut dokumentiert wird und keine stundenlange Einweisung einer anderen Person bedarf.

Zusätzlich dazu möchten wir mehr auf Software setzen, die Standard in der IT-Industrie ist. Dies hat den Vorteil, dass wir weniger Wartungsaufwand haben und wir Software verwenden, die sich unter Anderem auch in großen Unternehmen etabliert hat und somit auch 95% unserer Use-Cases abdeckt.

RewisServer Abklatsch

Wir haben bereits oft gelesen, dass Leute uns als RewisServer Abklatsch bezeichnen. Dies war zu erwarten, denn momentan ist es (abgesehen von neuen Maps) auch nichts Anderes. Die Kern-Community hat dafür gespendet, dass wir die Software von RewisServer von der Volix UG (dem Verwaltungs-Unternehmen von RewisServer) abkaufen. Wir fühlten uns in der Verpflichtung, den Code schnell wieder zum Laufen zu bekommen, um den Leuten das zu bringen, wofür sie bezahlt haben.

Wir haben uns jedoch zu Beginn schon dafür ausgesprochen, dass wir das Netzwerk weiterentwickeln wollen und auch neue Wege einschlagen wollen. Wir wollen dem Ganzen wieder Leben einhauchen und unter TheLotus eine neue Community aufbauen. Das Alte beizubehalten und zeitgleich etwas komplett neues zu entwickeln ist allerdings kein Wochenendausflug. Daher haben wir uns auf die Kompromisslöung geeinigt und releasen das Netzwerk mehr oder weniger so wie es zum Ende von RewisServer war und konzentrieren nun unsere gesamte Kraft darauf das Netzwerk codetechnisch aus dem Dreck zu ziehen, um daraus wieder ein großartiges Netzwerk zu machen.

Ich hoffe, dass dieser Abschnitt für einige Kritiker unsere Beweggründe aufzeigen konnte und vielleicht sogar etwas Verständnis hervorrufen kann.

Aufgaben

Kommen wir nun zur eigentlichen Roadmap. Die gelisteten Aufgaben werden teilweise parallel bearbeitet. Die Reihenfolge kann daher nicht als Prioritätenliste angesehen werden.

Serversoftware

Wie oben bereits beschrieben läuft TheLotus noch auf der Minecraft 1.8 Software, die auch bei RewisServer verwendet wurde. Diese Software wurde damals PowerSpigot getauft, da sie einige Performance-Benefits mitsich bringt, die andere Netzwerke nicht haben/hatten.

Diese Software baut auf der Spigot 1.8.8 auf und ist so zusammengestellt, dass wir aus Plugins problemlos auf internen Code (NMS, CraftBukkit) zugreifen können. Die Software hat Protokollunterstützungen von 1.8 bis 1.12.2 und viele weitere kleine Perks.

-> Versionskompatibilität
Das Hauptproblem ist, dass PowerSpigot nur 1.8-Content sowie die Elytra und Schilde aus der 1.9 unterstützt. Wir möchten mit TheLotus weiterhin 1.8 Spielern die Möglichkeit bieten bei uns zu Spielen. Zeitgleich wollen wir aber auch neue Wege einschlagen, für die die neuste Minecraft-Version unerlässlich ist.

Diesbezüglich haben wir uns viel Gedanken gemacht, wie wir das realisieren wollen und haben uns darauf geeinigt, dass wir für die 1.8 Modi weiterhin eine vollwertige 1.8er Server-Software und für die 1.17 Modi eine Vollwertige 1.17er Server-Software verwenden.

Alle Alternativ-Wege hätten bedeutet, dass wir eine Menge Fehler beheben müssten und Anti-Cheat-Systeme stark anpassen müssten, da sich zwischen 1.8 und 1.17 einiges getan hat.

-> Ablösung von PowerSpigot
Die alte Serversoftware hat gute Dienste erwiesen, jedoch ist es nun an der Zeit, dass wir eine neue Serversoftware verwenden und sie so aufbauen, dass wir sie upgraden können, ohne dass wir dafür jedes Plugin umschreiben müssen.

Um dies zu ermöglichen, bauen wir eigene APIs in die neue Serversoftware ein, die die NMS/CraftBukkit-Bedürfnisse unserer Plugins abdecken. So müssen wir bei einem Update der Serversoftware lediglich Änderungen in der Serversoftware selbst vornehmen und nicht mehr alle Plugins ändern.

Dieses ganze Projekt haben wir "Atlas" getauft. Atlas wird es in zwei Versionen geben:

• Atlas 1.8.x basierend auf Paper-Spigot 1.8.8
• Atlas 1.17.x basierend auf Paper-Spigot 1.17.x

Atlas 1.8.x existiert bereits und wird bereits produktiv für unser Bauteam verwendet.

-> Nachrüsten von PowerSpigot Features in Atlas
Da Atlas eine komplett "neue" Software ist, müssen wir die Features, die im Laufe der Jahre in die PowerSpigot implementiert wurden, bei Atlas nachrüsten. In diesem Zuge werden wir auch manche Features verwerfen oder verändern. Viele Dinge werden wir in Libraries auslagern, um die Wartbarkeit des Codes zu vereinfachen und um jenen Code auch in anderen Projekten verwenden zu können.

Einige dieser Features sind:

• Verhinderung von Knockback-Reduction ("Reducen")
• Zugriff auf die Client-Server Kommunikationsebene (Net-Code)
• Crash-Fixes
• Viele Performance- und QoL-Tweaks

Anpassung der Plugins

Dadurch, dass wir eine neue Serversoftware einsetzen werden, müssen auch viele Plugins angepasst werden. Viele unserer Plugins greifen direkt auf NMS oder CraftBukkit Klassen zu. Wie weiter oben bereits beschrieben ist das nicht optimal.

Um für zukünftige Updates der Serversoftware den Aufwand zu verringern, müssen viele Plugins so umgeschrieben werden, dass sie ausschließlich die API der Serversoftware verwenden. Hierfür müssen in der Serversoftware natürlich neue API-Funktionen hinzugefügt werden, um die NMS/CraftBukkit Funktionen verfügbar zu machen. Dieser zusätzliche Layer zwischen Plugin und Implementation erlaubt es uns, bei Updates der Serversoftware, Veränderungen die in der Implementation stattgefunden haben, in der API "abzufangen". Somit müssen wir nur im absoluten Ausnahmefall die Plugins anpassen.

Aktuell haben wir ca. 150 unterschiedliche Plugins im Einsatz. Von denen muss ein Großteil angepasst werden. Also kommt auch in diesem Bereich eine Menge Arbeit auf uns zu.

CloudServer

Der "CloudServer" oder besser "Zentralserver" ist das, was der Name bereits aussagt. Ein zentraler Server. Dieses Stück Software - ursprünglich für ein Pokémon-Projekt entwickelt - ist quasi das Gehirn des Netzwerkes. Zu Beginn von RewisServer war es dafür zuständig die Minecraft Server zu verwalten und mit anderen Servern und Software zu vernetzen.

Über die Jahre ist diese Software jedoch zu einem Monolithen gewachsen, der alles regelt, was irgendwie zentral geregelt werden muss. Teamspeak-Bot, Discord-Bot, Forum-Bot, Matchmaking-Server, Premium-Updater, Statistik-Updater uvm.

So wie die Software aktuell läuft, funktioniert das alles auch. Das Problem ist nur, dass wenn wir Updates an einem Teil vornehmen wollen, wir jedes Mal das gesamte Netzwerk herunterfahren müssen. So muss zum Beispiel für ein Update des TeamSpeak-Bots das gesamte Netzwerk heruntergefahren werden. Oder bei kritischen Bugfixes alle Runden abrupt beendet werden und keiner mehr das Netzwerk betreten kann.

Viele kennen sicherlich diesen Kick-Screen:

Sobald der Zentralserver abgeschaltet wird und die Proxies (BungeeCord) die Verbindung zum Zentralserver verlieren, trennen sie sofort alle Spielerverbindungen mit obiger Nachricht.

Um zukünftig zu verhindern, dass wir wegen Trivialitäten das gesamte Netzwerk abschalten müssen, sollen diese einzelnen "Abteile" des Zentralservers aufgeteilt werden. Fachlich nutzt man hierfür das Buzzword "MicroServices". Statt einer großen Software gibt es dann also viele kleinere Software-Teile, die ihren Part erledigen und mit anderen Softwares über Schnittstellen (REST, RPC, pub/sub) kommunizieren. Wenn wir also etwas am TS3-Bot aktualisieren müssen, dann wollen wir zukünftig nur noch den TS3-Bot stoppen müssen und nicht das ganze Netzwerk.

Diese Aufgabe besteht jedoch nicht einfach darin, den Code zu nehmen und ihn woanders hinzuschieben. Vieles kann beim "Auseinanderziehen" auch direkt überdacht und modernisiert werden. Dienste können direkt so angepasst werden, dass sie wichtige Informationen direkt teilen, sodass zukünftige Dienste diese Informationen nutzen können ohne, dass man großartige Änderungen programmieren muss. Wir wollen daher auch vorausschauend arbeiten, um zu verhindern, dass wir wieder in eine Situation wie die jetzige geraten.

Skalierende Infrastruktur

Unsere Infrastruktur basiert noch auf einer eigenen Implementation von RewisServer. Diese Implementation unterstützt eine Art Semi-Skalierung von Minecraft-Servern. Jedoch wird die "Hardware"-Infrastruktur selber nicht skaliert.

Laut TZimon im Abschiedsstream von RewisServer hat das Netzwerk gegen Ende um die 700 Euro pro Monat gekostet. Wenn man dann die geringen Spielerzahlen dazu in Betracht zieht, dann merkt man schnell, dass das nicht lange funktionieren kann. Der Grund für die hohen Kosten war, dass man immer so viel Hardware bereitstellen musste, wie das Netzwerk zu Spitzenzeiten benötigen würde.

Den ersten Schritt haben wir bereits getan, indem wir nun komplett auf Cloud-Infrastruktur aufbauen. Durch Cloud-Infrastruktur haben wir die Möglichkeit die Leistung stundenbasiert zu bezahlen. Wenn wir also einen richtig starken Server brauchen, um eine Lastspitze abzufangen, dann müssen wir diesen Server nur für die Zeit zahlen, für die wir den Server beansprucht haben.

Anders ausgedrückt hat RewisServer damals umgerechnet rund 98 Cent pro Stunde gekostet. Durchaus gerechtfertigt wenn mal 1000 Spieler online waren. Allerdings sind ja nicht immer 1000 Spieler online gewesen. Den Großteil der Zeit lag die Spielerzahl unter 500. Das Netzwerk hat zu diesen Zeiten jedoch immer noch 98 Cent pro Stunde gekostet. Sogar wenn es leer war.

Mit einer skalierenden Infrastruktur ist man da deutlich flexibler. Wenn nachts nur 10 Spieler online sind, dann kostet uns das Netzwerk deutlich weniger pro Stunde, als wenn nachmittags 1000 Spieler online sind, da wir nachts weniger Server benötigen.

Diese ganze Flexibilität (Scalability, Elasticity) sorgt dafür, dass das Netzwerk auch dann wirtschaftlich bleibt, wenn die Spielerzahlen sinken und im absoluten Worst-Case, müssen wir Admins keine Niere verkaufen, um das Netzwerk online zu halten.

Die neue Infrastruktur wird auf Kubernetes aufbauen. Dies erfordert unter Anderem, dass wir die ganze Art, wie wir unsere Software deployen, ändern müssen und uns deutlich mehr auf Automatisierungen verlassen müssen. Denn obwohl es kostensparender ist, ist es ein deutlich komplexeres System, was zwar oberflächlich einfach zu bedienen sein wird, jedoch "under the hood" deutlich mehr In-Depth Wissen erfordert als das jetzige System.

Wir werden hierzu noch deutlich weiter ins Detail gehen und sicherlich auch auf einige Hürden treffen, jedoch würde dies den Rahmen dieses Beitrages hier sprengen, weshalb "Scaling Infrastructure" in einem eigenen Blog-Beitrag abgedeckt werden wird.

Moderneres Anti-Cheat

Wir lesen eure Beschwerden über das aktuelle AntiCheat und merken auch selber, dass unter bestimmten Bedingungen das AntiCheat zu voreilig eingreift. Wir können zwar mit diversen Konfigurationsänderungen dagegen wirken. Jedoch muss eine Lösung her, die auch zukunftssicher ist. Unser aktuell verwendetes AntiCheat ist NoCheatPlus. NCP wird seit einigen Jahren nicht mehr aktiv weiterentwickelt. Somit werden dort auch keine Bugs mehr behoben und auch keine Unterstützungen für neue Minecraft Versionen eingepflegt.

Im Endeffekt bedeutet das, dass wir uns von NCP trennen werden. Welches AntiCheat wir zukünftig nehmen werden, steht zum aktuellen Zeitpunkt noch nicht fest. Wir werden evaluieren, welche AntiCheat Lösungen am besten passen und dann eine Wahl treffen. Ob wir ankündigen, welches AntiCheat wir verwenden, werden wir zu gegebener Zeit entscheiden.

Zusätzlich zur extern entwickelten "allround"-Lösung, werden wir selbstverständlich auch ein eigenes AntiCheat-System entwickeln. Die bisherigen AntiCheats von TheLotus beherrschen nur realtime Analyse - also sie erkennen (und verhindern) Cheats während der Runde. Zusätzlich sind die einzelnen Softwareteile auf unterschiedliche Plugins aufgeteilt und weisen einige Redundanzen auf. Auch hier möchten wir aufräumen und uns wieder auf ein einziges selbstentwickeltes AntiCheat setzen.

Dieses neue AntiCheat soll zusätzlich zur Live-Analyse auch Analysen von bereits vergangenen Runden durchführen können, welche uns helfen sollen Regression zu vermeiden und neue Prüfmethoden zu implementieren oder bestehende zu verbessern. Die Analyse von bereits vergangenen Runden eröffnet uns so einige Möglichkeiten - beispielsweise können wir so Verbesserungen und neue Prüfmethoden testen, bevor wir diese in den Produktionsbetrieb implementieren, indem wir analysieren lassen, ob Änderungen an Prüfmethoden/Algorithmen zu mehr oder weniger false- sowie positive-Flags führen.

Zudem ist es geplant alle Flags ebenfalls automatisch hochzuladen, sodass wir im Nachhinein nachvollziehen können wieso ein Spieler flagged wurde während der Runde. Bisher ging dies lediglich via /acbug, welches die Flags eines AntiCheats hochlädt, allerdings kaum Verwendung fand.

Mit Hilfe dieser Daten wollen wir, im Zuge der Verbesserungen, sowohl statistische als auch Heuristik-basierte Algorithmen implementieren, die sich mit der Zeit hoffentlich selbstständig verbessern werden.

Ziel dieses ganzen Prozesses soll sein, dass Cheater weiterhin schnell gebannt, aber Legit Spieler möglichst wenig bis keine Beeinflussungen seitens des AntiCheats erfahren.

Wie geht es jetzt also weiter?

Wir möchten so transparent wie möglich mit euch sein. Manche Updates sind nicht immer von jetzt auf gleich umgesetzt - das sollte denke ich aus dem oben stehenden Text hervorgegangen sein. Aber wir haben heute bereits die ersten Gespräche geführt und haben ausgearbeitet, welche kleineren Updates als nächstes zeitnahe auf euch zukommen können. Wir werden euch diesbezüglich auf dem laufenden halten!

Abschlussworte

Wir hoffen, euch hat dieser kleine Einblick in die Vergangenheit und Zukunft gefallen. Ihr merkt, wir haben ein klares Bild und deutliche Vorstellungen, wo und wie wir mit TheLotus weitermachen möchten und wir freuen uns, dass ihr uns auf dieser Reise begleiten möchtet.

Euer TheLotus.tv Serverteam

🌺