Multiplayer
Status: Social-Hub-Movement und serverautoritativer Dungeon-Waffenpfad implementiert; vollständige Dungeon-/Run-Simulation bleibt offen
Netzwerkebenen
- Nakama: Auth, Realtime-Socket, Chat, Hub-Join-Kontext, RPC und Storage.
- Godot ENet: Verbindung zum Headless Hub Server und Playerbewegung.
- Registry: HTTP-Discovery für Headless-Hubs.
Wichtige Pfade und Klassen
Core/Network/NetworkManager.cs: erstellt/entsorgt ENet-Client und publiziert Connection Events.Core/Bootstrap/ServerBootstrap.cs: erstellt ENet-Server.Core/Network/HubNetworkSync.cs: Registration, Movement-RPCs, serverseitige Validation/Walkability, Broadcast.src/HolodeckArena.Networking/Movement: Settings, MovementValidator, Snapshot/Prediction/InputHistory.src/HolodeckArena.Shared/Hubs: gemeinsame HubDefinition/Walkability/Hash.Features/Hub/HubRemotePlayersController.csundRemotePlayerAvatar.cs: Remote-Presentation/Interpolation.
Autorität
Client sendet Profil-/Presentationdaten bei Registration und periodisch Position/Velocity/InputSequence als unreliable RPC. Server prüft Hub-ID/Version/Hash, validiert Movement über MovementValidator, prüft HubWalkabilityMap und verteilt autoritative Snapshots. Upsert/Remove sind reliable. Andere Clients interpolieren visuell. Kamera, Animation und lokale Eingabe sind Clientdarstellung.
Der Client darf nicht ServerTick, Walkability, andere Player oder Score bestimmen. Nakama-UserId kommt derzeit aus dem lokalen Profilpayload; HubNetworkSync verifiziert keine Nakama-Session gegen ENet. Diese Vertrauenskante ist für Produktion zu schließen.
Prediction, Reconciliation und Interpolation
Networking enthält PredictionBuffer/InputHistory/SnapshotBuffer und Settings wie MaxSpeed 5.5, MaxAcceleration 40, TeleportThreshold 3, HardSnapDistance 0.75. HubNetworkSync nutzt serverseitige Validation und Remote-Snapshots; eine vollständige lokale Reconciliation-Pipeline ist nicht durchgängig angeschlossen. Bei Jitter zuerst SendInterval, ServerTick, WorldUnits-Konvertierung, Buffer und HardSnap kontrollieren.
Noch nicht vollständig implementiert
Der Dungeon besitzt vorbereitete serverautorisierte Weapon-Session-Validierung und eine transportneutrale IRunAuthority-Commandgrenze. Vollstaendige serverautorisierte Gegner-, Run-, Replay- und Completion-Simulation ueber ENet fehlt weiterhin.
Tests, Debugging, Performance
Eigene Networking-Tests fehlen. Zwei lokale Clients plus Headless-Server prüfen: Registration, inkompatiblen HubHash, Bewegung an Grenzen, Disconnect, Interpolation und Packet loss. JSON pro Movement-Paket sowie Broadcast pro Peer sind Skalierungsrisiken; mit Godot Network Profiler und GC messen.
Verwandt: Headless, Social Hub, Troubleshooting.
Dungeon weapon combat
Dungeon weapon combat has a separate ENet authority path from social-hub movement. AdvancedWeaponController sends fire/reload/switch intent through IDungeonCombatCommandPort; DungeonCombatNetworkSync implements that port for ENet. The headless server owns ammo, validation, hit resolution, damage, health, replay events, and snapshots. See Server-authoritative dungeon weapon combat for contracts, validation, reconciliation, smoke testing, and the remaining identity trust boundary.