Megapack: Wie Factorio-Entwickler es geschafft haben, das 200-Spieler-Multiplayer-Problem zu lösen

Im Mai dieses Jahres nahm ich als Spieler am KatherineOfSky MMO-Event teil . Mir ist aufgefallen, dass alle paar Minuten, wenn die Anzahl der Spieler eine bestimmte Anzahl erreicht, einige von ihnen „abfallen“. Zum Glück für Sie (aber nicht für mich) war ich einer der Spieler, die sich jedes Mal getrennt haben , auch wenn eine gute Verbindung bestand. Ich nahm dies als persönliche Herausforderung und begann nach den Ursachen des Problems zu suchen. Nach drei Wochen Debuggen, Testen und Beheben wurde der Fehler endgültig behoben, aber diese Reise war nicht so einfach.

Die Probleme von Multiplayer-Spielen sind sehr schwer zu finden. Normalerweise treten sie unter sehr spezifischen Bedingungen von Netzwerkparametern und unter sehr spezifischen Bedingungen des Spiels auf (in diesem Fall der Anwesenheit von mehr als 200 Spielern). Und selbst wenn es möglich ist, das Problem zu reproduzieren, kann es nicht ordnungsgemäß getestet werden, da das Einfügen von Kontrollpunkten das Spiel stoppt, die Timer verwirrt und normalerweise zur Beendigung der Verbindung führt, weil die Wartezeit überschritten wird. Aber dank der Sturheit und des wunderbaren Werkzeugs namens ungeschickt gelang es mir herauszufinden, was los war.

Kurz gesagt: Aufgrund eines Fehlers und einer unvollständigen Implementierung der Simulation des Verzögerungsstatus befindet sich der Client manchmal in einer Situation, in der er ein Netzwerkpaket in einem Taktzyklus senden muss, das aus den Aktionen des Spielers zur Auswahl von etwa 400 Spieleinheiten besteht (wir nennen es ein „Megapackage“). Danach sollte der Server alle diese Eingabeaktionen nicht nur korrekt empfangen, sondern auch an alle anderen Clients senden. Wenn Sie 200 Kunden haben, wird dies schnell zu einem Problem. Der Kanal zum Server ist schnell verstopft, was zu Paketverlust und einer Kaskade von erneut angeforderten Paketen führt. Das Verschieben von Eingabeaktionen führt dann dazu, dass noch mehr Kunden Megapackets senden und ihre Lawine noch stärker wird. Erfolgreiche Kunden können sich erholen, der Rest fällt ab.


Das Problem war ziemlich grundlegend und ich habe 2 Wochen gebraucht, um es zu beheben. Es ist ziemlich technisch, daher werde ich im Folgenden die saftigen technischen Details erläutern. Aber zuerst müssen Sie wissen, dass seit der Veröffentlichung der Version 0.17.54 am 4. Juni angesichts vorübergehender Verbindungsprobleme der Mehrspielermodus stabiler geworden ist und das Verbergen von Verzögerungen viel weniger fehlerhaft ist (weniger Bremsen und Teleportieren). Außerdem habe ich die Art und Weise geändert, wie Verzögerungen im Kampf versteckt werden, und ich hoffe, dass sie dadurch etwas reibungsloser werden.

Mehrbenutzer-Megapack - Technische Details

In einfachen Worten funktioniert der Multiplayer im Spiel wie folgt: Alle Clients simulieren den Status des Spiels und empfangen und senden nur die Eingaben des Spielers (sogenannte „Eingabeaktionen“, Eingabeaktionen ). Die Hauptaufgabe des Servers besteht darin, Eingabeaktionen zu übertragen und zu steuern, dass alle Clients dieselben Aktionen in einem Zyklus ausführen. Lesen Sie mehr dazu in der Post FFF-149 .

Da der Server Entscheidungen darüber treffen muss, welche Aktionen ausgeführt werden sollen, bewegen sich die Aktionen des Spielers auf diesem Pfad: Aktion des Spielers -> Spielclient -> Netzwerk -> Server -> Netzwerk -> Spielclient. Dies bedeutet, dass die Aktion jedes Spielers erst ausgeführt wird, nachdem er einen Hin- und Rückweg durch das Netzwerk gemacht hat. Aus diesem Grund scheint das Spiel furchtbar langsam zu sein, so dass fast unmittelbar nach dem Erscheinen des Multiplayers im Spiel ein Mechanismus zum Verbergen von Verzögerungen eingeführt wurde. Das Ausblenden einer Verzögerung imitiert die Eingabe eines Spielers, ohne die Aktionen anderer Spieler und Serverentscheidungen zu berücksichtigen.


Factorio hat einen Spielstatus namens Spielstatus - dies ist der vollständige Status der Karte, des Spielers, der Entitäten und aller anderen Elemente. Es wird in allen Clients basierend auf den vom Server empfangenen Aktionen deterministisch simuliert. Der Spielstatus ist heilig, und wenn er sich jemals vom Server oder einem anderen Client unterscheidet, erfolgt eine Desynchronisierung.

Zusätzlich zum Spielstatus haben wir einen Latenzstatus . Es enthält eine kleine Teilmenge des Grundzustands. Der Latenzstatus ist nicht heilig und zeigt lediglich ein Bild davon, wie der Status des Spiels in Zukunft aussehen wird, basierend auf den vom Spieler eingeführten Eingabeaktionen .

Dazu speichern wir eine Kopie der erstellten Eingabeaktionen in der Verzögerungswarteschlange.


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

1. Wenden Sie die Eingabeaktionen aller Spieler auf den Spielstatus an, da diese Eingabeaktionen vom Server empfangen wurden.
2. Wir entfernen alle Eingabeaktionen aus der Warteschlange der Verzögerungen, die laut Server bereits auf den Spielstatus angewendet wurden.
3. Löschen Sie den Latenzstatus und setzen Sie ihn zurück, sodass er genauso aussieht wie der Spielstatus .
4. Wenden Sie alle Aktionen aus der Verzögerungswarteschlange auf den Latenzstatus an .
5. Basierend auf den Daten aus Spielstatus und Latenzstatus rendern wir das Spiel für den Spieler.

All dies wiederholt sich in jedem Takt.

Zu kompliziert? Entspann dich nicht, das ist noch nicht alles. Um die unzuverlässigen Internetverbindungen auszugleichen, haben wir zwei Mechanismen geschaffen:

• Verpasste Ticks: Wenn der Server entscheidet, dass die Eingabeaktionen im Spieltakt ausgeführt werden, wird er nicht warten, wenn er die Eingabeaktionen einiger Spieler nicht erhält (z. B. aufgrund der erhöhten Verzögerung), sondern diesem Client mitteilen, dass ich dies nicht berücksichtigt habe Ich werde versuchen, Ihre Eingabeaktionen zur nächsten Kennzahl hinzuzufügen. " Dies geschieht, damit aufgrund von Problemen mit der Verbindung (oder mit dem Computer) eines Spielers die Kartenaktualisierung für alle anderen nicht langsamer wird. Es ist erwähnenswert, dass Eingabeaktionen nicht ignoriert, sondern einfach verschoben werden.
• Roundtrip-Verzögerung: Der Server versucht zu erraten, wie hoch die Roundtrip-Verzögerung zwischen Client und Server für jeden Client ist. Bei Bedarf bespricht er alle 5 Sekunden mit dem Client eine neue Verzögerung (abhängig davon, wie sich die Verbindung in der Vergangenheit verhalten hat) und erhöht oder verringert dementsprechend die Verzögerung beim Hin- und Herübertragen von Daten.

Diese Mechanismen sind an sich recht einfach, aber wenn sie zusammen verwendet werden (was häufig bei Verbindungsproblemen auftritt), wird die Logik des Codes schwierig zu verwalten und es gibt eine Reihe von Grenzfällen. Wenn diese Mechanismen ins Spiel kommen , müssen der Server und die Verzögerungswarteschlange außerdem eine spezielle Eingabeaktion namens StopMovementInTheNextTick korrekt implementieren. Aus diesem Grund läuft der Charakter bei Verbindungsproblemen nicht von alleine (z. B. unter dem Zug).

Jetzt müssen Sie Ihnen erklären, wie die Entitätsauswahl funktioniert. Eine der Arten der übergebenen Eingabeaktion ist die Änderung des Status der Entitätsauswahl. Es sagt jedem, über welcher Entität der Spieler schwebte. Wie Sie verstehen, ist dies eine der häufigsten Eingabeaktionen, die von Clients gesendet werden. Um Bandbreite zu sparen, haben wir sie so optimiert, dass sie so wenig Platz wie möglich beansprucht. Dies wird wie folgt implementiert: Bei der Auswahl jeder Entität behält das Spiel anstelle der absoluten, hochpräzisen Koordinaten der Karte einen relativen Versatz mit geringem Strom gegenüber der vorherigen Auswahl bei. Dies funktioniert gut, da die Mausauswahl normalerweise sehr nahe an der vorherigen Auswahl erfolgt. Aus diesem Grund ergeben sich zwei wichtige Anforderungen: Eingabeaktionen dürfen niemals übersprungen und in der richtigen Reihenfolge ausgeführt werden. Diese Anforderungen sind für den Spielstatus erfüllt. Da es jedoch die Aufgabe des Latenzzustands ist, für den Spieler „gut genug auszusehen“, sind sie im Zustand der Verzögerungen nicht zufrieden. Der Latenzstatus berücksichtigt nicht viele Grenzfälle, die mit Überspringzyklen und sich ändernden Umlaufverzögerungen verbunden sind.

Sie können bereits erraten, wohin alles geht. Schließlich beginnen wir, die Ursachen des Megapackage-Problems zu erkennen. Die Wurzel des Problems besteht darin, dass bei der Entscheidung, ob die Aktion der Auswahländerung bestanden werden soll, die Entitätsauswahllogik auf dem Latenzstatus beruht und dieser Status nicht immer die richtigen Informationen enthält. Daher wird ein Megapaket wie folgt generiert:

1. Der Player hat ein Verbindungsproblem.
2. Die Mechanismen zum Überspringen von Uhren und zum Regulieren der Umlaufverzögerung kommen ins Spiel.
3. Verzögerungen im Warteschlangenstatus berücksichtigen diese Mechanismen nicht. Dies führt dazu, dass einige Aktionen vorzeitig gelöscht oder in der falschen Reihenfolge ausgeführt werden, was zu einem falschen Latenzstatus führt .
4. Der Spieler hat ein Problem mit der Verbindung und simuliert, um den Server einzuholen, bis zu 400 Taktzyklen.
5. In jedem Taktzyklus wird eine neue Aktion generiert, die die Auswahl einer Entität ändert, und zum Senden an den Server vorbereitet.
6. Der Client sendet ein Megapaket mit mehr als 400 Änderungen bei der Auswahl der Entitäten an den Server (und bei anderen Aktionen: Der Zustand des Schießens, Gehens usw. litt ebenfalls unter diesem Problem).
7. Der Server empfängt 400 Eingabeaktionen. Da er keine einzelne Eingabeaktion überspringen darf, weist er alle Clients an, diese Aktionen auszuführen, und sendet sie über das Netzwerk.

Die Ironie ist, dass ein Mechanismus zum Einsparen von Kanalbandbreite infolgedessen riesige Netzwerkpakete erzeugt hat.

Wir haben dieses Problem gelöst, indem wir alle Grenzfälle der Aktualisierung und Unterstützung der Warteschlange für Verzögerungen korrigiert haben. Obwohl es eine Weile gedauert hat, hat es sich am Ende gelohnt, alles richtig zu implementieren und sich nicht auf schnelle Hacks zu verlassen.