Void-Bastion/server/nakama

Void Bastion Online-Backend

Dieser Docker-Compose-Stack betreibt eine eigene Nakama-Instanz mit einer ausschließlich intern erreichbaren PostgreSQL-Datenbank.

Unraid-Pfade

• Stack: /mnt/user/appdata/void-bastion-online/stack
• Nakama-Daten und spätere Servermodule: /mnt/user/appdata/void-bastion-online/nakama
• PostgreSQL-Daten: /mnt/user/appdata/void-bastion-online/postgres
• tägliche Datenbanksicherungen: /mnt/user/appdata/void-bastion-online/backups
• Geheimnisse: /mnt/user/appdata/void-bastion-online/stack/.env

Die echte .env-Datei bleibt ausschließlich auf dem Server und darf weder in das Spiel noch in ein Quellarchiv aufgenommen werden.

Der Backup-Container erstellt beim Start und danach täglich einen komprimierten PostgreSQL-Dump. Sicherungen werden 14 Tage aufbewahrt. Für einen vollständigen Schutz sollte dieses Verzeichnis zusätzlich durch das vorhandene externe Unraid-Backup erfasst werden.

Erreichbarkeit

• Spiel-API und Echtzeit-WebSocket: Host-Port 7350
• Verwaltungskonsole: nur auf Unraid-Loopback 127.0.0.1:7351
• PostgreSQL: kein veröffentlichter Host-Port

Für eine öffentliche Testversion wird Port 7350 später über Nginx Proxy Manager mit einer eigenen Domain und TLS als HTTPS/WSS veröffentlicht. Die Verwaltungskonsole bleibt privat.

Öffentliche Adresse: api.void-bastion.gergames.de. Der Host api.void-bastion zeigt als CNAME auf bs6o73mrdi3e60p0.myfritz.net; Nginx Proxy Manager stellt HTTPS/WSS mit einem automatisch erneuerten Let’s-Encrypt-Zertifikat bereit und leitet intern auf Nakama an Port 7350 weiter.

Betrieb

Der Stack verwendet fest versioniertes Nakama 3.37.0 und PostgreSQL 16 Alpine. Vor einem Versionswechsel werden Datenbank und Nakama-Appdata gesichert und die offiziellen Migrationshinweise geprüft.

Freunde und Einladungen

Freundschaftsanfragen, bestätigte Freundschaften und Online-Präsenz verwenden die eingebauten Nakama-Funktionen. Die app-eigene RPC invite_friend nimmt ausschließlich die Freundes-ID und einen sechsstelligen privaten Raumcode entgegen. Sie prüft, dass der Absender den Raum erstellt hat und eine gegenseitige Freundschaft besteht. Je Empfänger gilt ein Mindestabstand von 15 Sekunden. Die Benachrichtigung ist nicht persistent und enthält nur Absendername und Raumcode; ein Chat oder frei eingebbarer Einladungstext existiert nicht. Die Funktion muss zusammen mit dem aktualisierten Godot-Client ausgerollt werden.

find_player_by_name löst einen sichtbaren Spielernamen per exakter, nicht groß-/kleinschreibungsabhängiger Suche in eine interne Benutzer-ID auf. Wenn mehrere Konten denselben Anzeigenamen haben, wird die Anfrage als ambiguous abgewiesen, statt versehentlich das falsche Konto hinzuzufügen. Der Client zeigt und kopiert im Freundemenü nur den sichtbaren Namen. Im privaten Warteraum ist für bestätigte Freunde EINLADEN verfügbar.

Online-Diagnose

submit_online_diagnostics nimmt am Ende einer Online-Partie automatisch technische Berichte der beiden Clients entgegen. Der Server prüft anhand der beim Matchbeitritt gespeicherten Teilnehmerzuordnung, ob das sendende Konto zur Runde gehört. Beide Berichte werden mit derselben 16-stelligen Rundenkennung und unterschiedlichen Seitenzahlen gespeichert. Es werden nur erlaubte numerische Messwerte und vordefinierte Ereignisse übernommen; keine Namen, Nachrichten, IP-Adressen oder Raumcodes. Die Speicherung ist serverprivat und wird nach 14 Tagen beim nächsten Diagnoseabruf oder -upload bereinigt.

Die Server-zu-Server-RPC list_online_diagnostics liefert mit {} eine kompakte Übersicht. Mit {"round_id":"<Kennung>"} liefert sie beide vollständigen Seitenberichte. Der private HTTP-Schlüssel gehört ausschließlich in die Server-/Webhosting-Konfiguration, niemals in den Spielclient. Weitere Auswertungshinweise stehen in ONLINE_DIAGNOSE.md.

Private Statistik-RPCs

• record_activity: nur für angemeldete Spieler; aktualisiert die pseudonyme Aktivität sowie aggregierte Plattform- und Versionswerte.
• private_stats: nur als Server-zu-Server-Aufruf mit NAKAMA_HTTP_KEY; liefert die zusammengefassten Werte für die interne Homepage.
• create_unlock_code, list_unlock_codes und delete_unlock_code: nur Server-zu-Server mit NAKAMA_HTTP_KEY; verwalten private Freischaltcodes inklusive Einlösungsstatus und optionaler Admin-Bemerkung. Löschen ist nur bei null Einlösungen möglich; eine versionsgebundene Löschung schützt vor einer gleichzeitigen Einlösung.

Der Code-Lookup verwendet einen SHA-256-Schlüssel. Für die private Admin-Übersicht wird der Klartextcode zusätzlich in einem Nakama-Speicherobjekt mit permissionRead:0 und permissionWrite:0 gehalten; Spielclients können dieses Objekt nicht lesen. Bemerkungen sind auf 160 Zeichen beschränkt. Die echte Webhosting-Konfiguration mit dem HTTP-Schlüssel darf nicht in Git abgelegt werden.