3.3 KiB
Online-Diagnose für Zwei-PC-Tests
Ab dem nächsten gemeinsamen Client-/Nakama-Update schreibt das Spiel während jeder Online-Partie Messwerte lokal mit. Beim Sieg (Welle 15), bei einer Niederlage oder beim Verlassen sendet jeder PC seinen Bericht automatisch an Nakama. Beide Berichte bekommen dieselbe 16-stellige Rundenkennung und die Seitenzahl 0 oder 1. Die Spieler müssen dafür keinen Diagnose-Button bedienen. Bei vorübergehendem Übertragungsfehler versucht der Client es dreimal; die lokale .jsonl-Datei bleibt als Rückfallebene erhalten.
Die private Server-zu-Server-RPC list_online_diagnostics liefert mit {} eine Übersicht der letzten Berichte. Mit {"round_id":"<16-stellige Kennung>"} liefert sie die zwei vollständigen Seitenberichte. Sie ist wie private_stats nur mit dem privaten Nakama-HTTP-Schlüssel erreichbar; Spielclients können sie nicht aufrufen. Für den Vergleich einer Partie erst die Rundenkennung in der Übersicht auswählen und anschließend beide Seiten laden. Die Kennung steht außerdem nach erfolgreichem Upload in der Spielausgabe als ONLINE DIAG hochgeladen: Runde ....
Online gespeichert werden nur technische Messwerte. Nachrichten, IP-Adressen, Spielernamen, Raumcodes und der rohe Match-Identifier werden nicht als Bericht gespeichert. Der Server nimmt nur Berichte von Konten an, die tatsächlich Teilnehmer der Runde waren. Berichte und Teilnehmerzuordnung werden nach 14 Tagen beim nächsten Diagnoseabruf oder -upload bereinigt.
Jede window-Zeile fasst etwa zehn Sekunden zusammen:
| Feld | Bedeutung |
|---|---|
snapshots_per_second, gap_p95_ms, gap_max_ms |
Wie regelmäßig Zustände beim PC eintreffen; erwartet sind ungefähr 10/s bzw. 100 ms Abstand. |
tick_jump_max, tick_jumps_over_1 |
Ob Server-Schritte zwischen verarbeiteten Zuständen fehlen. Zusammen mit den Empfangsabständen und Warteschlangenwerten zeigt das, ob Zustände ausblieben oder erst verspätet gebündelt ankamen; allein beweist es noch keine Ursache. |
bytes_avg, bytes_max |
Größe der vollständigen Zustandsnachrichten. Wachsende Werte bei vielen Gegnern/Türmen weisen auf Datenmenge als möglichen Faktor hin. |
coalesced, queue_dropped, queue_max |
Mehrere Zustände kamen vor einem Bild zusammen oder die Warteschlange lief voll. Das deutet auf einen Client-Rückstau hin. |
parse_max_us, apply_max_us |
Höchste Zeit für JSON-Verarbeitung bzw. Anwenden des Zustands in Godot. |
frame_max_ms, frame_stalls_over_200_ms |
Lokale Bildaussetzer, auch wenn das Netz regelmäßig liefert. |
enemies, towers |
Last im Spiel zum Zeitpunkt der Messung. |
Zusätzliche snapshot_gap, tick_jump, frame_stall, socket_closed und socket_reconnected-Zeilen markieren einzelne Ereignisse. Die Uhrzeit ist UTC, damit beide PCs direkt verglichen werden können. Ein Empfangsabstand allein beweist keine Paketverluste: Er kann auch durch Serverlast, Netzwerk-Jitter oder einen blockierten Client entstehen. Für eine eindeutige Zuordnung die gleichzeitigen Berichte beider PCs vergleichen; serverseitige ONLINE DIAG tick_gap_ms- und loop_ms-Warnungen helfen zusätzlich.
Wichtig: Alte Spielversionen laden noch nichts hoch. Vor einem echten Zwei-PC-Test müssen sowohl der neue Windows-Build als auch der aktualisierte Nakama-Runtime-Code veröffentlicht sein.