Ein Plugin statt siebenundfünfzig — der Plan hinter DreamCore

Mein Hauptserver läuft mit siebenundfünfzig Plugins. Beim letzten Versionssprung habe ich elf davon aktualisiert, zwei ersetzt, drei aufgegeben und eines selbst geforkt.

Das ist die eigentliche Rechnung eines fremden Plugin-Stapels: Jeder Versionssprung ist ein Projekt, dessen Umfang von Entscheidungen anderer abhängt.

Der Plan, an dem ich seitdem arbeite: möglichst viel davon in ein eigenes zentrales Plugin holen. Dann muss bei einem Sprung nur noch eine Sache angepasst werden.

Warum nicht alles

Die ehrliche Vorabbewertung: „Nur noch ein Plugin" geht nicht, und wer das behauptet, hat sich die Liste nicht angesehen.

Was zwingend bleibt, weil es Infrastruktur ist und kein Komfort:

• die Bedrock-Anbindung samt Kontenbrücke — das ist ein ganzes Protokoll
• die Versionsübersetzung für Clients
• die Protokollbibliothek, auf die vieles aufbaut
• die Rechteverwaltung — die Auflösung steckt tief im Server; darauf soll mein Plugin aufsetzen, nicht sie ersetzen
• Weltbearbeitung und Regionsschutz
• die Weltverwaltung für mehrere Dimensionen
• der Profiler

Was ersetzbar ist, nach Nutzen sortiert:

• Chat, Anzeigen, Spielerliste, Serverbeschreibung — vier Plugins, die zusammen ein Anzeigemodul ergeben
• Rucksäcke und Lagerung
• Kisten und Belohnungen
• Möbel und dekorative Objekte
• Teile der Grundbefehle: Zuhause, Warp, Teleportanfragen
• Figuren, die im Spiel stehen und Menüs öffnen

Realistisches Ziel: von siebenundfünfzig auf etwa zwölf bis fünfzehn.

Warum das überhaupt lohnt

Der offensichtliche Grund ist der Versionssprung. Es gibt zwei weitere, die mir inzwischen wichtiger sind.

Zusammenhängendes Verhalten. Wenn Chat, Anzeige und Spielerliste in einem Modul liegen, gelten überall dieselben Regeln für Namen, Ränge und Farben. Bei vier Plugins hat jedes seine eigene Vorstellung, und man verbringt Zeit damit, sie in Einklang zu bringen.

Ein Datenmodell statt vieler. Jedes Plugin bringt seine eigene Datenhaltung mit — mal eine Datei, mal eine Datenbank, mal beides. Ein netzwerkweiter Zustand über mehrere Server hinweg ist damit nicht möglich, ohne für jedes einzeln eine Lösung zu suchen.

Der zweite Punkt ist der eigentliche Auslöser. Ich will Dinge, die serverübergreifend gelten — und das ist mit einer Sammlung fremder Plugins nicht zu machen.

Das Fundament: eine gemeinsame Datenbank

Der erste Baustein, der steht: Mein Plugin verbindet sich mit derselben Datenbank, die auch die Rechteverwaltung benutzt, und legt beim Start seine eigenen Tabellen an — mit einem eigenen Namenspräfix, damit keine zusätzlichen Rechte nötig sind.

Zwei Entscheidungen dabei:

Der Datenbanktreiber kommt über den eingebauten Bibliotheksmechanismus, nicht als mitgelieferte Datei. Damit gibt es keine Kollision mit anderen Plugins, die denselben Treiber in anderer Fassung mitbringen — ein Klassiker unter den schwer auffindbaren Fehlern.

Der Testserver hat eine eigene Datenbank. Versuche sollen nicht in den Livebetrieb durchschlagen. Das klingt selbstverständlich und wird bei „ist ja dieselbe Software" gerne übersehen.

Laden ist asynchron, Anwenden im Haupttakt. Wenn ein Spieler den Server betritt, werden seine Daten im Hintergrund geholt und erst danach angewendet. Alles andere wäre eine Verzögerung im Takt des Servers — und damit für alle spürbar.

Es gibt einen Rückfall auf eine lokale Datei, wenn die Datenbank nicht erreichbar ist. Ein Spieler, der seine Kosmetik verliert, weil die Datenbank hakt, ist eine schlechtere Antwort als ein leicht veralteter Stand.

Die Reihenfolge, in der ich ersetze

Ein Reduktionsplan braucht eine Reihenfolge, sonst fängt man beim Interessantesten an statt beim Nützlichsten. Meine Kriterien, nach Gewicht:

Wie oft bricht es bei Versionssprüngen? Ein Plugin, das jedes Mal Ärger macht, ist ein besserer Kandidat als eines, das seit Jahren durchläuft.

Wie tief sitzt es? Etwas, das nur Anzeige betrifft, ist risikoarm zu ersetzen. Etwas, das Daten hält, nicht.

Wie viel Verhalten müsste ich reproduzieren? Hier zeigt sich, warum die Dokumentation vor dem Code kommt: Ohne sie ist diese Frage nicht beantwortbar.

Was gewinne ich? Bei einem Anzeigemodul: netzwerkweite Einheitlichkeit. Bei Rucksäcken: einen gemeinsamen Datenbestand über alle Server.

Der letzte Punkt ist der, der die Reihenfolge bei mir bestimmt hat. Ersetzen um des Ersetzens willen lohnt nicht — jedes eigene Modul muss etwas können, das die Sammlung fremder Plugins nicht kann.

Der Einwand, den ich ernst nehme

Es gibt ein Argument gegen dieses Vorhaben, das ich nicht wegdiskutieren kann: Ich baue mir Arbeit, die vorher jemand anderes gemacht hat.

Ein fremdes Plugin wird von seinem Autor an neue Versionen angepasst. Meines nicht. Bei jedem Sprung liegt die Arbeit bei mir.

Meine Gegenrechnung ist nicht, dass das nicht stimmt, sondern dass die Alternative anders aussieht, als sie klingt. Beim letzten Versionssprung fielen von den fremden Plugins vierzehn aus. Elf ließen sich aktualisieren, zwei musste ich ersetzen oder forken, eines blieb liegen.

Das ist auch Arbeit — nur eine, die ich nicht steuern kann und bei der ich fremden Code verstehen muss, den ich nicht geschrieben habe.

Der Unterschied ist nicht die Menge, sondern die Vorhersehbarkeit. Und die Frage, ob ich lieber eine Sache anpasse, die ich vollständig verstehe, oder fünfzehn, bei denen ich hoffe, dass jemand anderes zuerst fertig wird.

Der ehrliche Teil

Das ist ein Plan, kein Ergebnis. Was steht, ist die Datenbankschicht und ein erstes Modul. Der Rest ist eine Liste.

Und es gibt einen Einwand gegen das ganze Vorhaben, den ich ernst nehme: Ein eigenes Plugin ist Arbeit, die dauerhaft an mir hängt. Ein fremdes Plugin wird von jemand anderem an neue Versionen angepasst. Meines nicht.

Meine Antwort darauf ist eine Abwägung, keine Widerlegung: Bei einem Versionssprung passe ich lieber eine Sache an, die ich vollständig verstehe, als fünfzehn, die ich nicht geschrieben habe — und von denen einige nicht mehr gepflegt werden. Die Erfahrung mit den drei Plugins, die den letzten Sprung nicht überlebt haben, ist genau der Grund für diesen Plan.