Mega-Paket: Wie es den Entwicklern von Factorio gelang, das Problem mit Multiplayer für 200 Spieler zu lösen.

Im Mai dieses Jahres nahm ich als Spieler an der MMO-Veranstaltung KatherineOfSkyteil. Ich bemerkte, dass, sobald die Anzahl der Spieler eine bestimmte Zahl erreicht, einige von ihnen alle paar Minuten „abfallen“. Leider für Sie (aber nicht für mich) war ich einer der Spieler, die sich jeden Mal verabschiedeten auch bei stabiler Verbindung. Ich nahm dies als persönliche Herausforderung und begann, nach den Ursachen des Problems zu suchen. Nach drei Wochen Debugging, Tests und Korrekturen war der Fehler schließlich behoben, aber diese Reise war alles andere als einfach., selbst bei einer guten Verbindung. Ich habe das als persönliche Herausforderung angesehen und begonnen, nach den Ursachen des Problems zu suchen. Nach drei Wochen des Debuggings, Testens und Fehlersuchens war der Fehler schließlich behoben, aber diese Reise war alles andere als einfach.

Die Probleme in Mehrspieler-Spielen sind sehr schwer nachzuvollziehen. Sie treten oft unter sehr spezifischen Netzwerkkonfigurationen und Zuständen im Spiel auf (in diesem Fall — mit mehr als 200 Spielern). Selbst wenn es gelingt, das Problem nachzustellen, kann es nicht richtig debuggt werden, da das Setzen von Kontrollpunkten das Spiel stoppt, die Timer verwirrt und in der Regel zu einer Unterbrechung der Verbindung aufgrund von Timeout führt. Aber dank Hartnäckigkeit und eines großartigen Tools namens clumsy , konnte ich herausfinden, was wirklich passiert.

Kurz gesagt: Aufgrund eines Fehlers und einer unvollständigen Implementierung der Verzögerungssimulation befand sich der Kunde manchmal in der Situation, dass er in einem einzigen Takt ein Netzwerkpaket mit etwa 400 Aktionen von Spielentitäten (wir nennen es "Megapaket") senden musste. Danach muss der Server nicht nur alle diese Eingabewertungen korrekt empfangen, sondern sie auch an alle anderen Kunden senden. Wenn du 200 Kunden hast, wird das schnell zum Problem. Der Kanal zum Server wird schnell überlastet, was zu Paketverlusten und einem Kaskadeneffekt an wiederholt angeforderten Paketen führt. Die Verzögerung der Eingabewertungen führt dann dazu, dass noch mehr Kunden beginnen, Megapakete zu senden, und die Lawine wird noch größer. Glückliche Kunden schaffen es, sich zu erholen, während alle anderen "ausfallen".


Das Problem war ziemlich grundlegend, und ich habe zwei Wochen gebraucht, um es zu beheben. Es ist recht technisch, daher werde ich im Folgenden die technischen Einzelheiten erläutern. Aber zunächst sollten Sie wissen, dass ab Version 0.17.54, die am 4. Juni veröffentlicht wurde, der Multiplayer unter Bedingungen mit temporären Verbindungsproblemen stabiler geworden ist, und die Verzögerungsreduzierung deutlich weniger fehleranfällig ist (weniger Ruckler und Teleportationen). Außerdem habe ich die Methode zur Reduzierung von Verzögerungen im Spiel geändert und hoffe, dass sie dadurch etwas flüssiger werden.

Multiplayer-Megapaket — technische Einzelheiten

Einfach ausgedrückt funktioniert der Multiplayer im Spiel folgendermaßen: Alle Clients simulieren den Spielzustand, indem sie nur die Eingaben der Spieler empfangen und senden (genannt „Input Actions“ Input Actions). Die Hauptaufgabe des Servers besteht darin, sicherzustellen Input Actions und zu steuern, dass alle Clients in einem Takt die gleichen Aktionen ausführen. Mehr dazu können Sie im Post lesen FFF-149.

Da der Server Entscheidungen treffen muss, welche Aktionen ausgeführt werden sollen, verlaufen die Aktionen des Spielers in etwa folgender Reihenfolge: Aktion des Spielers -> Spielclient -> Netzwerk -> Server -> Netzwerk -> Spielclient. Das bedeutet, dass jede Aktion des Spielers erst ausgeführt wird, nachdem sie den Hin- und Rückweg über das Netzwerk zurückgelegt hat. Dadurch würde das Spiel extrem langsam erscheinen; daher wurde fast sofort nach der Einführung des Mehrspielermodus ein Mechanismus zur Verborgenen Verzögerung implementiert. Die Verborgene Verzögerung emuliert die Eingabe des Spielers, ohne die Aktionen anderer Spieler und Entscheidungen des Servers zu berücksichtigen.

In Factorio gibt es einen Spielzustand Spielzustand – das vollständige Zustand der Karte, des Spielers, der Entitäten und aller anderen Elemente. Er wird deterministisch in allen Clients simuliert, basierend auf den vom Server empfangenen Aktionen. Der Spielzustand ist heilig, und wenn er jemals von dem Server oder einem anderen Client abweicht, entsteht eine Desynchronisation.

Zusätzlich Spielzustand wir haben einen Zustand der Verzögerung Verzögerungszustand. Er enthält eine kleine Teilmenge des Hauptzustands. Verzögerungszustand es ist nicht heilig und stellt einfach dar, wie der Zustand des Spiels in Zukunft aussehen wird, basierend auf den Eingaben der Spieler. Input Actions.

Dafür speichern wir eine Kopie der erstellten Input Actions in der Verzögerungswarteschlange.

Das heißt, am Ende des Prozesses sieht das Bild auf der Clientseite ungefähr so aus:

1. Wir wenden an Input Actions alle Spieler auf Spielzustand so, wie diese Eingabeschnitte vom Server empfangen wurden.
2. Wir entfernen aus der Verzögerungswarteschlange alle Input Actions, die laut Server bereits auf Spielzustand.
3. Entfernen Verzögerungszustand angewendet wurden, und setzen es zurück, damit es genau so aussieht wie Spielzustand.
4. Wir wenden alle Aktionen aus der Verzögerungswarteschlange auf Verzögerungszustand.
5. Basierend auf den Daten Spielzustand und Verzögerungszustand rendern wir das Spiel für den Spieler.

Das alles wird in jedem Takt wiederholt.

Zu kompliziert? Entspannen Sie sich nicht, das ist noch nicht alles. Um die Unzuverlässigkeit von Internetverbindungen auszugleichen, haben wir zwei Mechanismen entwickelt:

• Verpasste Takte: wenn der Server entscheidet, dass Input Actions im Spieltakt ausgeführt werden, und wenn er keinen Input Actions Spieler erhalten hat (zum Beispiel wegen erhöhter Verzögerung), wird er nicht warten, sondern diesem Client mitteilen: „Ich habe deine Input Actions, ich werde versuchen, sie im nächsten Takt hinzuzufügen." Dies wurde so gemacht, damit wegen Verbindungsproblemen (oder Computerproblemen) eines Spielers die Kartenaktualisierung für alle anderen nicht verlangsamt wird. Es ist erwähnenswert, dass Input Actions nicht ignoriert, sondern einfach nur aufgeschoben werden.
• Die Verzögerung der Hin- und Rückreise: Der Server versucht abzuschätzen, wie hoch die Round-Trip-Verzögerung zwischen dem Client und dem Server für jeden Client ist. Alle 5 Sekunden bespricht er gegebenenfalls mit dem Client die neue Verzögerung (abhängig davon, wie die Verbindung in der Vergangenheit funktioniert hat) und passt die Round-Trip-Verzögerung entsprechend an.

Diese Mechanismen sind für sich genommen recht einfach, aber wenn sie gemeinsam verwendet werden (was oft bei Verbindungsproblemen passiert), wird die Logik des Codes schwer kontrollierbar und hat viele Randfälle. Darüber hinaus müssen Server und Verzugsschlangen diese speziellen Mechanismen richtig implementieren. Eingabemaßnahme mit dem Namen BewegeStoppImNächstenTick. Dadurch läuft der Charakter bei Verbindungsproblemen nicht von selbst (zum Beispiel unter einen Zug).

Jetzt müssen wir Ihnen erklären, wie die Auswahl von Entitäten funktioniert. Einer der übermittelten Typen Eingabemaßnahme ist die Veränderung des Auswahlzustands einer Entität. Dies informiert alle darüber, auf welche Entität der Spieler den Mauszeiger bewegt hat. Wie Sie verstehen können, handelt es sich hierbei um eine der häufigsten Eingabemaßnahmen, die von den Clients gesendet werden. Daher haben wir es optimiert, um die Bandbreite zu schonen und so wenig Platz wie möglich einzunehmen. Dies wurde so umgesetzt: Bei der Auswahl jeder Entität speichert das Spiel anstelle von absoluten, hochpräzisen Kartenvorgaben eine niedrigpräzise relative Verschiebung im Vergleich zur vorherigen Auswahl. Das funktioniert gut, weil die Mausmarkierung normalerweise sehr nah an der vorherigen Auswahl erfolgt. Dadurch ergeben sich zwei wichtige Anforderungen: Input Actions dass niemals etwas übersprungen werden darf und dass sie in der richtigen Reihenfolge ausgeführt werden müssen. Diese Anforderungen werden erfüllt für Spielzustand. Aber da die Aufgabe Latency state darum geht, für den Spieler "ausreichend gut auszusehen", werden in den Latenzzuständen diese Anforderungen nicht erfüllt. Verzögerungszustand berücksichtigt viele Grenzfälle, die mit Taktüberschreitungen und Änderungen der Hin- und Retourlatenzen verbunden sind.

Sie können sich wahrscheinlich schon vorstellen, wohin das führt. Endlich beginnen wir, die Ursachen des Megapakets zu erkennen. Das Grundproblem liegt darin, dass die Entscheidungslogik, ob eine Handlung der Änderungswahl übergeben werden soll, auf Verzögerungszustand, und dieser Zustand enthält nicht immer die richtigen Informationen. Daher wird das Megapaket ungefähr so generiert:

1. Der Spieler hat Verbindungsprobleme.
2. Es kommen Mechanismen zur Taktüberspringung und zur Regelung der Hin- und Rückverzögerung ins Spiel.
3. Die Warteschlange der Verzögerungszustände berücksichtigt diese Mechanismen nicht. Das führt dazu, dass einige Aktionen vorzeitig entfernt oder in der falschen Reihenfolge ausgeführt werden, was zu falschen Verzögerungszustand.
4. Der Spieler hat seine Verbindungsprobleme nicht mehr und simuliert, um den Server einzuholen, bis zu 400 Takte.
5. In jedem Takt wird eine neue Handlung zur Änderung der Entitätswahl generiert und zur Sendung an den Server vorbereitet.
6. Der Client sendet dem Server ein Megapaket von über 400 Änderungen der Entitätswahl (und auch andere Aktionen wie Schuss- und Gehzustände waren von diesem Problem betroffen).
7. Der Server erhält 400 Eingabeaktionen. Da ihm nicht gestattet ist, auch nur eine einzige Eingabeaktion zu überspringen, verlangt er von allen Clients, diese Aktionen auszuführen und sie über das Netzwerk zu senden.

Die Ironie besteht darin, dass der Mechanismus, der zur Einsparung der Bandbreite des Kanals gedacht war, in der Folge riesige Netzwerkpakete erzeugte.

Wir haben dieses Problem gelöst, indem wir alle Randfälle bei der Aktualisierung und der Unterstützung der Verzögerungsschlange behoben haben. Obwohl dies ziemlich viel Zeit in Anspruch nahm, war es letzten Endes besser, alles richtig umzusetzen, als sich auf schnelle Hacks zu verlassen.

Quelle: habr.com