Network Interest Management: jedem Client die relevante Welt replizieren

Festlegen, was jede Verbindung benötigt

Interest Management wählt für jeden Client die Objekte oder Daten aus, die für ihn relevant sind. Die autoritative Welt kann dabei deutlich grösser bleiben als die replizierte Sicht eines einzelnen Clients. Die Regeln können sich auf Distanz, Besitz, Teams oder Matchzugehörigkeit stützen. Mirror dokumentiert diese Alternativen, Unreal bewertet die Relevanz von Actors dagegen pro Verbindung. Die Sichtbarkeit im Kamerabild allein genügt nicht: Auch ein Projektil ausserhalb des Bildschirms oder ein hörbarer Gegner kann den Spieler beeinflussen. [1][2]

Änderungen der Zugehörigkeit als Lebenszyklus behandeln

Beim Eintritt in die relevante Menge ist genug Anfangszustand nötig, um auf dem Client eine brauchbare Repräsentation zu erzeugen. Spätere Deltas müssen sich auf eine Baseline beziehen, die dieser Client tatsächlich besitzt. Für den Austritt braucht es eine definierte Operation zum Ausblenden oder Entfernen (Despawn); das autoritative Objekt wird dadurch nicht zwingend gelöscht. Die Network Visibility von Unity steuert ausdrücklich das Spawnen und Despawnen auf Clients sowie den Datenverkehr der Objekte. [3]

Beim erneuten Eintritt ist ein frischer Zustand aufzubauen, und verspätete Updates, die zu einer veralteten Inkarnation des Objekts gehören, sind zu verwerfen. Die persistente Identität ist von einem wiederverwendeten Laufzeit-Handle zu trennen. Auch angehängte Ausrüstung und andere Abhängigkeiten eines Objekts brauchen eine konsistente Sichtbarkeit, sonst erhält der Client Referenzen, die er nicht auflösen kann.

Rechenbeispiel: Nutzdatenersparnis und Wechsel an der Grenze

Betrachtet sei ein beispielhafter Server mit 1000 dynamischen Objekten. Werden pro Objekt 64 Byte Nutzdaten mit 20 Updates pro Sekunde gesendet, kostet das für einen Client 1000 * 64 * 20 = 1280000 Byte pro Sekunde. Benötigt dieser Client 80 Objekte, kostet dasselbe Modell 80 * 64 * 20 = 102400 Byte pro Sekunde. Es handelt sich um reine Nutzdatenrechnungen ohne Header, Kompression, Anfangszustand und erneute Übertragungen.

Angenommen sei bei gewöhnlicher distanzbasierter Zugehörigkeit, dass Objekte innerhalb von 100 Metern eintreten, aber erst jenseits von 120 Metern wieder ausscheiden. Diese Hysterese verringert wiederholtes Spawnen nahe der Grenze. Sie hält allerdings auch zusätzliche Objekte vor; der Spielraum ist anhand von Bewegungsgeschwindigkeit, Update-Takt und Eintrittskosten zu wählen. Informationsberechtigungen sind vor dieser räumlichen Komfortregel anzuwenden, damit ein grösserer Austrittsradius nie einen unzulässigen Gegner offenbart.

Die Relevanz-Pipeline aufbauen und messen

Zu Beginn stehen explizite Kategorien: immer relevant, nur für den Besitzer und räumlich. Ein räumlicher Index liefert die Kandidaten, danach werden die vollständigen Regeln angewendet. Die Zugehörigkeit wird aktualisiert, wenn sich Spieler bewegen, Teams wechseln oder Objekte gespawnt werden. Ein verzögerter Neuaufbau braucht einen konservativen Spielraum oder einen direkten Pfad für dringende Änderungen.

Zu protokollieren sind die Anzahl relevanter Objekte, die Auswertungszeit, die Bytes des Anfangszustands, der stetige Datenverkehr und die Häufigkeit von Ein- und Austritten. Zu testen sind Teleports, Zuschauerkameras, überfüllte Eingänge und rasch wechselnder Besitz. Zu prüfen ist, was ein Client tatsächlich empfängt, einschliesslich der Felder von ansonsten relevanten Objekten; die Objektzugehörigkeit filtert private Felder nicht automatisch.

Die Grenzen verstehen

Interest Management tauscht serverseitigen Verwaltungsaufwand und Komplexität im Lebenszyklus gegen selektive Übertragung ein. In dichten Begegnungen kann dennoch fast alles lokal relevant werden. Wer versteckte Informationen sendet und später wieder entfernt, kann nicht rückgängig machen, was ein manipulierter Client bereits erfahren hat. Die Autorisierungsregeln sind explizit zu halten, und neben dem durchschnittlichen Datenverkehr sind auch plötzliche Erweiterungen der Sichtbarkeit einzuplanen. Eine korrekte Zugehörigkeit garantiert weder rechtzeitige Zustellung noch flüssige Bewegung; dafür sind separate Netzwerkstrategien nötig.

Quellen

• [1] Interest Management — Mirror Networking contributors.
• [2] Actor Relevancy — Epic Games, Unreal Engine documentation.
• [3] Object Visibility — Unity Technologies, Netcode for GameObjects documentation.