Artikel

Alle Welten auf einer Karte

Jeder Server hatte seine eigene Kartenansicht, jede Welt hieß „world“. Wie ich sie zusammengeführt habe — mit Verweisen statt Kopien und einem Webserver, der komprimierte Dateien versteht.

BlackZackBlackzack

1042 Wörter · 5 Min. Lesezeit

  • minecraft
  • bluemap
  • nginx

Für Minecraft-Welten gibt es Kartenwerkzeuge, die aus den Weltdaten eine dreidimensionale Ansicht im Browser erzeugen. Jeder meiner Server hatte so etwas — und damit hatte ich mehrere Kartenansichten unter verschiedenen Adressen.

Das Ziel: eine Adresse, ein Menü, alle Welten.

Das Namensproblem zuerst

Bevor irgendetwas zusammengeführt werden konnte, musste ein banales Problem gelöst werden: Auf jedem Server hieß jede Welt gleich. world, world_nether, world_the_end — das sind die Standardnamen, und sie sind pro Server eindeutig, über Server hinweg aber nicht.

Also ein Namensschema, das den Server mit einbezieht, und zwar sowohl für die interne Kennung als auch für den Anzeigenamen.

Umbenennen ohne alles neu zu rendern geht, wenn man zwei Dinge gemeinsam anfasst: die Konfigurationsdatei der Karte und den Ordner mit den erzeugten Kacheln. Die Kennung steht in keiner Metadatei, nur der Anzeigename. Danach genügt ein Neuladen — kein Serverneustart, und die bereits gerenderten Daten bleiben erhalten. Bei einer Welt mit mehreren Gigabyte Kacheln ist das der Unterschied zwischen Minuten und Tagen.

Warum ein eigener Webserver

Der naheliegende Weg wäre, den eingebauten Webserver eines der Kartenwerkzeuge zu benutzen und ihm die Ordner der anderen unterzuschieben. Das funktioniert nicht, und der Grund ist lehrreich.

Diese Werkzeuge legen ihre Kacheldateien komprimiert ab. Der Browser fragt nach der unkomprimierten Datei, und der eingebaute Webserver liefert die komprimierte Fassung aus, wenn er die Karte selbst verwaltet. Für fremde Ordner tut er das nicht — er sucht die Datei unter dem angefragten Namen, findet sie nicht, und antwortet mit einem Fehler.

Ergebnis: eine Karte, die nicht lädt, mit einer Fehlermeldung, die nach einem kaputten Datenbestand aussieht.

Die Lösung ist ein eigener Webserver mit drei Einstellungen:

gzip_static always;    # liefert die komprimierte Datei, wenn nach der normalen gefragt wird
gunzip on;             # entpackt für Clients, die das nicht können
disable_symlinks off;  # Verweise ins Datenverzeichnis erlauben

Und kein Versuch, die Existenz der Datei vorher zu prüfen — das würde einen Fehler liefern, bevor die Suche nach der komprimierten Fassung überhaupt beginnt. Genau diese eine Zeile hatte ich zuerst drin, aus Gewohnheit, und sie hat mich eine Stunde gekostet.

Verweise statt Kopien

Meine erste Fassung hat die Kartendaten regelmäßig in ein gemeinsames Verzeichnis gespiegelt. Das funktioniert und hat drei Nachteile:

  • Es verdoppelt mehrere Gigabyte.
  • Es hinkt immer hinterher.
  • Die Kartenwerkzeuge schreiben ihre Einstellungsdatei bei jedem Neuladen neu — und überschreiben damit die zusammengeführte Fassung.

Die zweite Fassung arbeitet mit Verweisen auf die Originalverzeichnisse. Damit ist jede Ansicht immer aktuell, auch die Anzeige der gerade anwesenden Spieler, und es gibt keine Verdopplung.

Die gemeinsame Einstellungsdatei — die, die dem Browser sagt, welche Welten es gibt — wird von einem eigenen Skript geschrieben. Sie liegt außerhalb der Zuständigkeit der Kartenwerkzeuge und kann deshalb von keinem überschrieben werden.

Infobox

Ein kleines Skript baut die Verweise und die Einstellungsdatei neu und läuft stündlich. Damit tauchen neue Welten von allein auf. Das ist der Unterschied zwischen einer Einrichtung, die man einmal macht, und einer, die mitwächst — und der Aufwand dafür war eine halbe Stunde.

Die Fallen, die ich mir notiert habe

Ein Anhalten der Renderprozesse wird durch ein Neuladen nicht rückgängig gemacht. Wer anhält und danach neu lädt, wundert sich über gleichbleibende Kachelzahlen. Es braucht einen ausdrücklichen Startbefehl.

Fehlende Kacheln sind normal. Während gerendert wird, fragt der Browser nach Bereichen, die es noch nicht gibt. Das erzeugt Fehlermeldungen im Browserprotokoll, die keine sind.

Leere Kartenordner bleiben nach dem Umbenennen zurück. Wer vorher nicht aufräumt, hat Verweise ins Nichts.

Was der Betrieb einer Kartenansicht kostet

Ein paar Zahlen, weil sie bei der Planung helfen und selten irgendwo stehen.

Speicherplatz. Eine erkundete Welt erzeugt schnell mehrere Gigabyte an Kacheln. Das ist deutlich mehr als die Weltdaten selbst und wächst mit jedem erkundeten Bereich.

Rechenzeit beim Rendern. Das erste vollständige Rendern einer gewachsenen Welt läuft Stunden. Danach werden nur noch Änderungen nachgezogen, und das ist wenig.

Dauerlast durch Besucher. Praktisch null — es sind statische Dateien. Was Last erzeugt, ist die Anzeige der anwesenden Spieler, und die ist ein kleiner Aufruf im Sekundenbereich.

Der erste Punkt ist der, den man einplanen muss. Ich habe die Renderfäden bewusst niedrig eingestellt, damit das Rendern den Spielserver nicht beeinträchtigt — es dauert dann länger, stört aber niemanden.

Warum ich die Karte für wichtiger halte, als sie klingt

Eine Karte ist kein Feature, das jemand braucht. Und sie ist der Teil meines Netzwerks, der am häufigsten von außen aufgerufen wird.

Der Grund liegt darin, dass sie die einzige Ansicht ist, die ohne das Spiel funktioniert. Man kann sie am Handy öffnen, in der Bahn, an einem Rechner ohne Minecraft. Man kann sie jemandem zeigen, der nicht spielt.

Damit ist sie das Schaufenster — und zwar unabhängig davon, ob man das beabsichtigt hat. Bei mir hat das dazu geführt, dass ich Dinge, die auf der Karte sichtbar sind, anders behandle: Ortsnamen, Markierungen, die Beschriftung der Welten.

Das ist eine Erkenntnis, die über Minecraft hinausgeht: Jedes System hat eine Oberfläche, die Fremde zuerst sehen. Man sollte wissen, welche das ist — und es ist selten die, an der man am meisten gearbeitet hat.

Was auf einer öffentlichen Karte nichts verloren hat

Eine Kartenansicht zeigt mehr, als man auf den ersten Blick denkt — und ein paar Dinge sollte man ausdrücklich abschalten.

Genaue Spielerpositionen. Sie sind bei mir sichtbar, weil das gewollt ist. Auf einem Server mit Wettbewerb wäre es ein Problem: Wer die Karte offen hat, sieht, wo alle sind.

Versteckte Bereiche. Manche Kartenwerkzeuge können Bereiche ausnehmen. Das ist sinnvoll für Baustellen, für Verwaltungsbereiche und für alles, was nicht öffentlich sein soll.

Untergrund. Höhlen, Basen unter der Erde, Lagerräume. Standardmäßig ist eine Draufsicht harmlos; eine Ansicht mit Untergrundmodus zeigt jedes versteckte Lager.

Markierungen mit Namen. Wer Orte beschriftet, sollte wissen, dass diese Namen öffentlich sind.

Diese vier Punkte sind alle Einstellungssache und keiner davon ist technisch schwierig. Sie werden nur selten bedacht, weil eine Karte harmlos wirkt — und dann steht die Basis von jemandem auf einer öffentlichen Seite, der sie bewusst versteckt hatte.

Was daraus geworden ist

Eine Adresse, unter der man alle Welten des Netzwerks ansehen kann, mit einem Menü zum Umschalten und mit den Punkten der gerade anwesenden Spieler.

Was mich daran am meisten überrascht hat, ist die Wirkung auf die Leute, die spielen. Eine Karte ist kein Feature, das man braucht. Sie ist aber das Erste, was Leute Freunden zeigen — und sie beantwortet unterwegs die Frage, ob gerade jemand online ist, ohne das Spiel zu starten.