BlueMap veröffentlichen: Was ihr vor der Freigabe prüft
Bevor ihr BlueMap öffentlich freigebt, legt fest, was ein Besucher ohne Anmeldung sehen darf, und prüft diese Ansicht von außerhalb eures Netzwerks. Betrachtet Gelände, Spielerpositionen, Marker und bereits erzeugte Daten getrennt. Wenn ein Bereich auf einer Bildschirmansicht fehlt, ist damit noch nicht belegt, dass sämtliche zugehörigen Informationen unzugänglich sind.
Der Ablauf richtet sich an Community-Verantwortliche, Bauteams und Veranstalter, die BlueMap bereits installiert haben und die Veröffentlichung freigeben müssen. Das Ergebnis ist ein kurzes Prüfprotokoll mit Nachweisen und Zuständigkeiten. Es handelt sich um einen vorgeschlagenen Arbeitsablauf, nicht um eine Vertraulichkeitsgarantie oder eine von uns durchgeführte Prüfung eures Servers.
Formuliert eine überprüfbare Vorgabe
Beschreibt den Zweck der Karte in einem Satz: „Das öffentliche Viertel und seine Einrichtungen zeigen, ohne das Wettkampfgebiet vorab zu verraten.“ Eine Vorgabe wie „Die Karte soll privat sein“ lässt zu viel Interpretationsspielraum.
Erstellt eine Liste der betroffenen Bereiche und Daten. Erfasst alle Dimensionen, Probewelten, unfertigen Bauwerke, Teilnehmerpositionen und Marker aus Integrationen. Ordnet jeden Eintrag als öffentlich, zugangsbeschränkt oder ausgeschlossen ein. Benennt außerdem eine Person, die Änderungen daran freigeben darf.
Ein hypothetisches Team möchte beispielsweise Spawn und Läden präsentieren, eine Arena aber erst später ankündigen. Die erste Veröffentlichung könnte deshalb nur das öffentliche Viertel umfassen, ohne Live-Spielerpositionen und mit einer geprüften Markerliste. Das ist eine vorgeschlagene Betriebsentscheidung für dieses Beispiel, keine allgemeingültige BlueMap-Konfiguration.
Klärt auch, wer die Veröffentlichung stoppen darf, wenn eine Baustelle vor ihrer Ankündigung sichtbar wird. Diese Person braucht einen konkreten Ablauf und die passenden Zugriffsrechte, bevor der Link verteilt wird. Eine Zuständigkeit auf dem Papier allein reicht im entscheidenden Moment nicht aus.
Begrenzt das gerenderte Gelände
Mit render-mask kann BlueMap Bereiche ein- oder ausschließen; die Reihenfolge der Masken zählt. Laut Dokumentation aktualisieren Änderungen die Karte und entfernen Kacheln außerhalb des festgelegten Bereichs. Prüft eure installierte Version und das Ergebnis vor der Freigabe. Grundlage ist die offizielle Masken-Dokumentation.
Für das Beispiel soll nur das vereinbarte Viertel erscheinen. Kontrolliert seine Grenzen von oben, in der Perspektivansicht und aus der Nähe. Eine ausgesparte Arena kann trotzdem auffindbar sein, wenn eine Straße, ein Markername oder ein benachbartes Bauwerk darauf hinweist. Bewertet deshalb auch, was Besucher aus der Darstellung ableiten können.
Verwendet freigegebene Koordinaten eurer eigenen Welt statt Werte aus einer Demonstration. Haltet den erlaubten Bereich als Screenshot fest und dokumentiert, welche Konfiguration ihn erzeugt hat. Sind ausgeschlossene Blöcke weiterhin sichtbar, bleibt die Veröffentlichung gesperrt, bis die Abweichung geklärt ist.
Prüft Positionen und Marker gesondert
live-player-markers steuert die Positionsübertragung an die Webanwendung über den integrierten Server. Daneben gibt es regelmäßige Schreibvorgänge für Spieler- und Markerdaten im Speicher. Prüft beide Wege und installierte Erweiterungen; ein abgeschalteter Weg belegt nicht, dass alle anderen geschlossen sind. Siehe Plugin-Konfiguration.
Verwendet ein Testkonto und einen Beobachter außerhalb eures Netzwerks. Verbindet euch, bewegt euch zwischen öffentlichem und reserviertem Bereich, wechselt die Dimension und meldet euch ab. Protokolliert die Darstellung während jedes Übergangs. Verbietet eure Vorgabe öffentliche Positionen, müssen sichtbare Koordinaten in der zuständigen Konfiguration oder Integration korrigiert werden.
Prüft auch Markertexte. Teamnamen, Links, Koordinaten und Beschreibungen können geplante Inhalte verraten, selbst wenn niemand online ist. Teilt die Kontrolle manueller Marker und automatischer Integrationen ausdrücklich zu. Erzeugt ein anderes System einen gelöschten Marker erneut, beseitigt das manuelle Löschen nur vorübergehend das sichtbare Problem.
Lasst während der Probe mindestens einen relevanten Aktualisierungsvorgang stattfinden. Eine anfangs bereinigte Ansicht genügt nicht, wenn der nächste Import ausgeschlossene Informationen zurückbringt. Notiert bei jedem beanstandeten Eintrag das erzeugende System, damit die zuständige Entwicklung einen nachvollziehbaren Fehlerfall bekommt.
Kontrolliert alte Daten und weitere Zugangswege
Das Entfernen einer Karte aus der Konfiguration beseitigt nicht sämtliche bereits gerenderten Daten. Die Konfigurationsanleitung behandelt diese Schritte getrennt. Identifiziert vor dem Entfernen gespeicherter Daten die richtige Karte und den richtigen Speicher und vereinbart, welche Kopie außerhalb des öffentlichen Zugriffs aufbewahrt wird.
Prüft bei einer zugangsbeschränkten Bereitstellung die normale Adresse und mögliche direkte Zugänge zum Ursprungsserver. Die Netzwerkschnittstelle des integrierten Servers ist konfigurierbar; die Webserver-Referenz beschreibt diese Einstellung. Wählt die Topologie passend zu eurem Aufbau: Eine Anleitung für einen Proxy auf derselben Maschine lässt sich nicht unverändert auf getrennte Rechner oder Container übertragen.
Lasst die Webadministration neben der Startseite auch Datenpfade sowie verwendete Caches und öffentliche Kopien kontrollieren. Eine neue Browsersitzung hilft, die Besucheransicht nachzustellen. Bereits angefertigte Screenshots oder heruntergeladene Dateien holt sie nicht zurück. Müssen Informationen geheim bleiben, ist es am wirksamsten, sie gar nicht erst zu veröffentlichen.
Haltet die Freigabe nachvollziehbar fest
Ein kurzes Protokoll sollte für ein anderes Teammitglied wiederholbar sein:
| Prüfung | Aufzubewahrender Nachweis | Voraussetzung für die Freigabe |
|---|---|---|
| Gelände und Dimensionen | Screenshots und zugeordnete Konfiguration | Nur freigegebene Bereiche erscheinen |
| Spieler und Übergänge | Beobachtungen des Testkontos | Die Positionsvorgabe wird eingehalten |
| Marker und Integrationen | Geprüfte Liste und Aktualisierungstest | Ausgeschlossene Informationen kehren nicht zurück |
| Zugänge und alte Daten | Geprüfte eigene URLs und Ergebnisse | Beschränkte Inhalte sind nicht abrufbar |
| Zugriff schließen | Zuständige Person und Ablauf | Das Team kann die Veröffentlichung zurücknehmen |
Notiert Datum, BlueMap-Version, Umgebung, prüfende Person und Ausnahmen. Eine nicht ausgeführte Prüfung bleibt offen. Eine ordentlich aussehende Startseite ersetzt die übrigen Nachweise nicht. Wiederholt die betroffenen Prüfungen nach Änderungen an Welten, Masken, Erweiterungen oder Webhosting.
Wenn Server und Webbereitstellung gemeinsam geplant werden sollen, beschreibt Umgebung und Zuständigkeiten für eine Anfrage zur verwalteten Infrastruktur. Für Marker oder Zugangsabläufe mit eigenen Systemen definiert den Umfang der individuellen Integration: Welche Informationen dürfen das Spiel verlassen, wer gibt sie frei und wie wird die Abnahme nachgewiesen? Projekte werden bezahlt und individuell angeboten; laufender Support wird separat vereinbart.
