53 lines
5.4 KiB
Markdown
53 lines
5.4 KiB
Markdown
# 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.
|
||
- `get_game_balance`: authentifizierte Spielclients erhalten die freigegebene Balance-Konfiguration; `set_game_balance`: ausschließlich Server-zu-Server mit `NAKAMA_HTTP_KEY` darf sie ändern. Die Werte gelten für neue Online-Partien; `matchInit` lädt einen privaten Snapshot in den Match-Zustand.
|
||
- `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.
|
||
|
||
Balancing-Regressionstest: `node tests/runtime_sim_test.js` prüft Runtime- und RPC-Verhalten; `node tests/balance_duel_test.js` spielt reproduzierbare Einzelduelle mit der echten Server-Kampflogik durch. Der Duelltest ist eine Referenzmessung, kein vollständiger Durchspiel-Bot.
|
||
|
||
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.
|