WIE APEX TICKT: EIN ENTWICKLER-DEEP DIVE ÜBER SERVER UND NETCODE

[EA_Vendcera]

EINLEITUNG

Hello, I'm @ricklesauceur, lead engineer on Apex Legends, and today I want to offer you a bit of insight into the online infrastructure that supports Apex Legends. 

In the past, we haven’t often talked publicly about servers, netcode, or online infrastructure for Apex Legends, and today we want to begin to change that. In short, today we want to:

• Share a bit about how we’re working to improve your online experience in Apex Legends
• Acknowledge and explain some common online issues or connectivity problems you may encounter while playing Apex
• Specifically address commonly-asked questions about topics like slow-mo servers, hit-registration, and how our lag compensation system works
• Offer some comprehensive notes on our server tickrate, and explain our thinking behind what it affects, and what it doesn’t

A warning: This post is long because it’s intended as a true deep-dive into the online infrastructure for Apex Legends—something we’ve seen some players requesting for a long time. 

We’re thinking of this as the starting point of a longer conversation, so even though we do cover a lot of ground here, there’s probably plenty of topics (DDOS attacks! Server-crashing bugs! Etc.!) that we could spend more time addressing. By all means, if you like this blog, let us know what you’d like to hear about next time, and we’ll keep it going.

For those of you who are ready to geek out about netcode, servers, tickrate, and more… welcome! Let’s kick things off by talking about some recent improvements we’ve shipped.

VERKÜRZUNG UNSERER REAKTIONSZEIT DURCH LEISTUNGSMETRIKEN

In Saison 6 haben wir die Leistungsanzeige eingeführt. So sieht sie aus, und sie gibt euch Basisinformationen über eure Leistung.

"In" und "out" ist die vom Spiel verbrauchte Bandbreite (in kB/s). Außerdem wird die Latenz (in Millisekunden) angezeigt. Paketverlust und Paket-Choke werden als Prozent der Pakete pro Sekunde angegeben.

Diese Zahlen helfen euch – und uns –, zu verstehen, was ihr beim Spielen erlebt. Mit anderen Worten, wir können das, was gerade abläuft, in nutzbare und technische Informationen übersetzen.

Vor dieser Erweiterung haben die Spieler zwar gesagt, dass "etwas" nicht stimmt, aber darüber hinaus konnten sie uns oft nicht viel sagen. Jetzt lautet die präzise Information: "Ich habe 10 % Paketverlust, 300 ms Latenz" usw. Das ändert alles, weil diese Zahlen oft die bestmöglichen Hinweise darauf geben, was gerade schiefläuft. Ich werde auf diesen Punkt noch zurückkommen.

Während wir an der Leistungsanzeige arbeiteten, haben wir auch damit begonnen, wichtige Leistungsmetriken für Spieler und Server zu erfassen. Das bedeutet, wenn jemand Probleme meldet, können wir sein Spiel abrufen und die Daten aller Spieler im Spiel zum fraglichen Zeitpunkt einsehen, einschließlich der Informationen über den spezifischen Server, auf dem das Spiel gehostet wird. 

Das war unser erster großer Vorstoß, unser Team mit personalisierten und gezielten Ermittlungsmaßnahmen zu versorgen. Wir hatten mit diesem Ansatz durchaus Erfolg, glauben aber, dass er langfristig nicht skalierbar ist. Wir brauchen dabei nämlich zunächst eine Meldung von euch, dann muss ein Techniker die Ursache des Problems herausfinden, und erst im Anschluss (je nach Problem) können wir nach einer Lösung suchen.

In den letzten Saisons haben wir damit begonnen, mithilfe unseres fantastischen Data Science-Teams im Wochenturnus Daten zu sammeln und zu analysieren, um extreme Paketverluste und Probleme mit der Serverleistung zu erkennen. Dieser Ansatz hat sich bereits ausgezahlt. Wir haben zum Beispiel herausgefunden, dass ein Teil der Netzwerkausstattung in unserer Datenzentrale fehlerhaft war, was dazu führte, dass die Netzwerkleistung aller Spiele auf etwa einer Handvoll Server miserabel war. Die Server selbst waren in Ordnung, aber die Hardware, die die Spieler mit den fraglichen Servern verband, verursachte enorme Paketverluste. Solche Beispiele gibt es viele.

Der Hauptvorteil der systematischen Datenanalyse besteht darin, dass wir dadurch Metriken und Spieler vergleichen können, um Muster zu finden. Wir können also Woche für Woche verlässlich sagen, ob die Gesundheit unserer Serverflotte besser oder schlechter geworden ist. Die Datenanalyse ist außerdem ein großartiges Tool, um unseren Partnern dabei zu helfen, Probleme zu beheben, die außerhalb unserer Kontrolle sind. Statt einfach nur zu sagen, dass "etwas" nicht stimmt, heißt es jetzt: "Mit diesem speziellen Ding stimmt etwas nicht" – was allen Beteiligten Zeit spart. (Ihr müsst dabei übrigens nicht mitmachen. Ihr findet die Einstellung im Einstellungen-Menü unter "Gameplay" und dann bei "Weitergabe von Nutzungsdaten".) 

Automatisierung ist also eine große Hilfe. Aber sie reicht nicht aus. 

Wir reagieren auch mit diesem Ansatz noch zu langsam auf Probleme. Wir müssen nämlich eine Woche warten, bis die meisten Daten verlässlich gesammelt und gemeldet werden, und dann dauert es oft noch eine Woche, bis eine vollständige Untersuchung durchgeführt wird. Ab dem Moment, an dem ihr ein Problem bemerkt, kann es also bis zu zwei Wochen dauern, bis wir eine Lösung finden – und noch länger, um sie zu implementieren, falls dafür ein Server-Patch erforderlich ist.

Das können wir besser machen. Wir werden das besser machen. Reden wir also über Lösungen.

Erstens werden wir zusätzlich zu unserem wöchentlichen Bericht einen Echtzeit-Alarm einführen. Dadurch erhalten wir dieselben Informationen wie jetzt, nur schneller. Wir können Hardwareprobleme sofort beheben bzw. die Untersuchung und Arbeit an einem Patch umgehend einleiten. Wir verstehen die Frustration beim Warten und versuchen aktiv, die Zeit zwischen einem Alarm und einem Fix zu verkürzen.

Zweitens werden wir eine neue serverspezifische ID ("SID") in die Leistungsanzeige integrieren, um den Server, auf dem ihr spielt, schneller zu finden. Derzeit nennt ihr uns Zeit und Datum, und wir korrelieren das mit den Daten, die wir über euch haben, um den Server zu finden, auf dem ihr gespielt habt. Bald wird das nicht mehr erforderlich sein. 

Wir gehen davon aus, dass beide oben genannten Lösungen während unserer kommenden Saison, Apex Legends: Vermächtnis, erscheinen werden. Das Ergebnis für Spieler werden schnellere Lösungen von Serverproblemen sein – bis zu doppelt so schnell wie aktuell.

EIN TIEFER EINBLICK IN HÄUFIGE PROBLEME

Kommen wir nun zum unterhaltsamen Teil: der Kategorisierung von Serverproblemen, die euch begegnen können. Die folgende stehende Liste ist nicht vollständig, aber ich hoffe, sie beantwortet die meisten eurer Fragen.

Der Server läuft in Zeitlupe.

Everybody loves this one. Our servers are running at 20Hz. This means that they simulate the entire world state once every 50ms (1 second—or 1,000ms—divided by 20).

We don’t speak about FPS (frame per second) when discussing server performance because a server does not display pictures. Instead, a server computes “states” but the underlying principle is the same. It takes user inputs (from the network), runs the physics, sends back the new world state to clients, then repeats. If this process takes more than 50ms consistently, your game will slow down to permit the server to finish the simulation. Thus, you get slow-mo servers.

Anzeige der Frametime für einen Server. Spalte 5 ist das Ziel von 50 ms. Alles darunter ist schneller. Ihr seht, dass dieser Server stabil und schneller war als erforderlich.

Zum Vergleich: Dieser Server hat die Frametime nie erreicht und lief meistens mit ungefähr 200 ms (also 4 Mal langsamer). Ein typischer Zeitlupen-Server.

Dieses Problem kann verschiedene Ursachen haben, und manchmal geht es auf Maschinen in der Datenzentrale zurück, die nicht so laufen wie gewünscht. Das kann ein untertakteter Prozessor sein, Überhitzung, usw. 

Wenn wir solche Geräte identifizieren, entfernen wir sie üblicherweise. Das heißt, wir rufen (telefonisch) den zuständigen Dienstleister an, melden das Problem mit dem jeweiligen Gerät und bitten darum, es offline zu nehmen. 

Die bereits in diesem Blog erwähnte Echtzeiterkennung, die im Verlauf der nächsten Saison an den Start gehen wird, sollte dieses Problem deutlich reduzieren. Wir haben viel Zeit in diese Lösung investiert, also werden wir sie auch genau im Auge behalten.

Meine Latenz steigt und sinkt ständig.

Wenn ihr über WLAN spielt, können wir nicht viel für euch tun! Anderenfalls kann die häufige Änderung der Latenz manchmal auch mit unserer Serverleistung in Verbindung stehen.

Wir alle wissen, dass auch ein Spiel, das normalerweise stabil mit 60 FPS läuft, absacken kann, wenn auf dem Bildschirm viel passiert. Und selbst ein Abfall von nur wenigen Frames ist spürbar. Bei Servern ist das ähnlich. Hier ist eine automatische Erkennung bei der Bestimmung der Problemursache nicht sonderlich hilfreich. Früher mussten wir die Bedingungen der Verlangsamung auf einem Entwicklerserver nachstellen, aber das ist ziemlich zeitaufwendig und immer irgendwie ein Schuss ins Blaue – euer System läuft wahrscheinlich nicht auf derselben Server-Hardware oder mit denselben Einstellungen, daher ist es schwierig, alles bis ins Detail zu replizieren.  

Zum Glück hat unser Produktionsteam ein Tool entwickelt, das uns eine sogenannte RPROF-Datei erstellt. Dabei handelt es sich im Grunde um einen Überblick, was der Server während jedes einzelnen Frames macht (ballistische Simulation, In- und Output im Netzwerk, Spielerbewegungen, usw.). Die RPROF-Dateien nennen uns die Ursache einer Verlangsamung, und dann kann ein Techniker mit der Optimierung beginnen. Meistens ist dieses Problem auf erhöhte Leistungsanforderungen zurückzuführen, die Saison für Saison durch neue Features entstehen. 

Ihr erinnert euch sicher an die Verlangsamung auf dem Champion-Bildschirm am Spielbeginn in den Saisons 7 und 8. Die Ursache dafür war, dass alle Spieler im Spiel an derselben Stelle übereinander spawnten und sich dabei sogar überlappten. (Und wegen der UI konntet ihr sie nicht einmal sehen!) Physiksimulationen hassen es, wenn Objekte überlappen, und unsere Physik-Engine hat versucht, alle Körper voneinander zu trennen, was zu massiven CPU-Spitzen auf dem Server führte.

Prozentsatz der Spiele, die von einem langsamen Server (nicht notwendigerweise Zeitlupe) beeinflusst werden, nach Region. Ihr seht, dass einige Regionen mit der Zeit besser werden, andere hingegen schlechter (X-Achse ist die Zeit).

Eine detaillierte Ansicht der Region Westliche USA, durch die wir fehlerhafte Maschinen ausfindig machen können (X-Achse ist die Zeit). Ausfälle sind deutlich zu erkennen. Einige Maschinen sind davon betroffen, andere bleiben stabil.

Wir gehen davon aus, dass unsere Nutzung von RPROF-Dateien uns dabei helfen wird, neue Funktionen für das Spiel zu optimieren und die Latenz in Zukunft insgesamt zu verringern. Die Reduzierung der Latenz für alle Spieler ist für uns sehr wichtig, und bessere Tools wie dieses sind entscheidend, damit wir dieses Ziel erreichen. 

Ich habe eine Menge Paketverluste / Paket-Choke.

Dieses Problem ist extrem knifflig. Euch trifft daran wahrscheinlich keine Schuld, uns normalerweise aber auch nicht! 

Die Sache hängt damit zusammen, wie Internet-Traffic von eurem Anschluss zu unserer Datenzentrale und wieder zu euch zurück kommt. Am Anfang befindet sich euer Netzwerk-Traffic auf dem Netzwerk eures Internetanbieters. Tritt bei diesem ein Fehler auf, können eure Informationen und die Daten anderer Kunden verlorengehen. Dadurch weiß der Spiel-Client nicht, was mit den Spielern in eurer Umgebung los ist, und der Spiel-Server weiß nicht, ob ihr mit eurer Waffe schießen oder in eine bestimmte Richtung gehen wollt. Daneben besteht eine Verbindung zwischen dem Netzwerk Eures Internetanbieters und dem unserer Datenzentrale. Überall unterwegs können Probleme auftreten.

Funktioniert alles reibungslos, nennen wir das "Peering". Peering-Probleme entstehen häufig durch eine schwache Verbindung zwischen zwei Netzwerken. Unterwegs können mehreren solcher Stolperstellen auftreten. Und dann müssen natürlich alle Informationen der Apex-Server zurück zu euch gelangen, oftmals über einen anderen Weg. Es ist also kein Wunder, dass diese Aufgabe entsprechend komplex ist. 

Zur Lösung müssen wir zunächst in der Lage sein, festzustellen, wo der Ausfall genau auftritt. Das lässt sich nur schwer automatisieren, da wir dazu Daten von euch und vom Server benötigen , damit uns beide "Perspektiven" vorliegen und wir entlang des Weges prüfen können, wo das Problem liegt. 

Aktuell bitten wir Spieler, irgendwelche Netzwerkabläufe bereitzustellen, und wir machen dasselbe auf unserer Seite der Datenzentrale, um den Punkt zu ermitteln, wo die Daten sich stauen. Dieser Prozess ist extrem zeitaufwendig und langsam, weil wir je nach Ergebnis mit verschiedenen Geschäftspartnern auf der ganzen Welt Kontakt aufnehmen müssen. Wir hoffen darauf, diesen Ablauf durch Automatisierung zu verbessern, und arbeiten an einigen Ansätzen, die sich allerdings noch in der Startphase befinden. 

Wenn es um Probleme mit dem Netzwerk-Traffic geht wie die gerade besprochenen, ist es zumindest von Vorteil, dass sie meist gehäuft auftreten und nicht nur bei einer Einzelperson. Das bedeutet, dass die Behebung des Problems bei einem betroffenen Spieler in der Regel auch vielen anderen zugutekommt. Außerdem reduzieren wir aktiv die vom Spiel genutzte Bandbreite, um das Problem zu reduzieren.

Das hier ist ein Netzwerkablauf (der die Latenz anzeigt) eines unserer Profispieler, von seinem Internetmodem bis zu einem unserer Server. Wir prüfen mehrmals, um bewerten zu können, wie gut die Internetverbindung wirklich ist. Wie ihr seht, ist der beste Wert eine Latenz von 31 ms. Aber der schlechteste liegt bei etwa 522 ms. Sein Spielerlebnis ist also extrem schlecht, weil seine Verbindung mit einer Differenz von 500 ms oszilliert. In seinem lokalen ISP-Netzwerk ist die Verbindung ein wenig wackelig, aber der Durchschnitt zeigt uns, dass die Störung ziemlich selten ist (ein Durchschnitt von 31 ms, wenn der schlechteste Wert 264 ms beträgt, deutet auf einen isolierten Zwischenfall hin). Aber dann kommt es zu einer Latenzsteigerung zwischen dem lokalen ISP und ISP 1, einem der Knoten zwischen dem Spieler und unserem Spielserver. Wir können fast sicher sein, dass es dort zu Paketverlusten und Routing-Problemen kommt. Der Vorgang liegt außerhalb unserer Kontrolle, aber wir können die betroffenen Partner über dieses Problem informieren. In der Regel liegt es im Interesse aller, die Situation zu lösen.

Ich werde getötet, während ich hinter einer Tür/Wand bin, und manchmal lande ich dann wieder auf meiner vorherigen Position.

Das ist ein heikles Thema. Es hat mit dem Lag-Ausgleich zu tun. 

Seit dem Beginn des Online-Gamings müssen Entwickler das Hauptproblem lösen, Echtzeit-Action vorzutäuschen, obwohl das Spiel selbst nicht in Echtzeit funktioniert. Letztlich ist jede Aktion in Online-Spielen aufgrund der Latenz zum Server und zurück verzögert. Dazu kommen weitere Aspekte: Eingaben, Rendering und sogar die Server-Tickrate. 

Noch schlimmer ist, dass euer Gegner mit ziemlicher Sicherheit mit einer anderen Latenz spielt als ihr. Um das zu lösen, müssen unsere Server nicht nur ständig prüfen, was in jedem Moment für dich und deinen Gegner passiert, sondern auch, was aus beiden Perspektiven zu dem Zeitpunkt passiert ist, als ihr die Eingaben für eure Aktionen gemacht habt. Lag-Ausgleich ist die Kunst, zeitlich minimal verschobene Ereignisse zu einer gemeinsamen Realität zu verschmelzen. 

Dafür gibt es keine perfekte Lösung. Es gibt keine ultimative Wahrheit. Unter dem Strich ist der Server eine Art Zeitmaschine. Er dreht den Weltstatus ständig zurück, um festzustellen, ob euer Schuss jemanden getroffen hat, und aktualisiert dann die Welt für alle entsprechend. 

Um das alles besser zu veranschaulichen, hat mein Kollege Earl Hammon einen kurzen Text über Fairness, Lag-Ausgleich und deren Funktionsprinzip in Apex Legends geschrieben. Lest ihn am besten mal kurz durch:

Wir sehen uns nun verschiedene Szenarien mit zwei Spielern in Apex Legends an, die wir HOCH und NIEDRIG nennen. HOCH hat einen hohen Ping von 300 ms und NIEDRIG einen niedrigen von 50 ms. Der Unterschied ihrer Pings beträgt also 250 ms.

Was passiert, wenn sie in Echtzeit gleichzeitig aufeinander schießen? Nun, der Schuss von NIEDRIG trifft lange vor dem Schuss von HOCH auf den Server ein, damit ist NIEDRIG im Vorteil.

Was passiert, wenn einer von ihnen um eine Ecke biegt, sodass sie einander plötzlich sehen können? Auch dann ist NIEDRIG im Vorteil. NIEDRIG ist weniger "in die Vergangenheit" und sieht HOCH damit zuerst. NIEDRIG profitiert durch seinen niedrigeren Ping. Dazu kommt, wie gesagt, dass NIEDRIGs Kugeln schneller beim Server ankommen.

Diese Fälle sind insofern "unfair", weil sie NIEDRIG einen Vorteil vorschaffen, aber sie sind irgendwie auch "fair", weil es naheliegend ist und man davon ausgehen kann, dass der Spieler mit dem niedrigeren Ping in solchen Situationen genau diesen Vorteil hat.

Und was passiert nun, wenn NIEDRIG sich hinter eine Ecke begibt, um in Deckung zu gehen? HOCH ist immer noch in der Vergangenheit, in der NIEDRIG nicht in Deckung ist, kann also auf NIEDRIG schießen, bevor dieser in Deckung geht, aber das wird NIEDRIG erst erfahren, wenn die Datenpakete von HOCH zum Server und anschließend zu NIEDRIG gelangt sind. Zu dem Zeitpunkt sieht NIEDRIG dann, dass er sicher in Deckung sind, aber dennoch getroffen wurde. Aus der Perspektive von NIEDRIG ist das wenig nachvollziehbar.

Genauso wenig nachvollziehbar wie die Effekte zugunsten von NIEDRIG vorhin! Wenn NIEDRIG aus der Deckung kommt, um HOCH anzugreifen, sieht er HOCH und kann auf ihn schießen, während HOCH den Eindruck hat, NIEDRIG befinde sich noch in Deckung. Aus der Perspektive von HOCH ist es wenig nachvollziehbar, von jemandem erschossen zu werden, der noch in Deckung war. Dieses Paradox kann nicht beseitigt, sondern nur von Spieler zu Spieler übertragen werden, weil die Realität des Pings nun einmal besteht und er bei verschiedenen Spielern unterschiedlich hoch ist. 

Manche argumentieren, es sei unfair, dass NIEDRIG von HOCH getroffen werden kann, während er denkt, schon in Deckung zu sein. Sie schlagen darum als Alternative vor, HOCH müsse seinen hohen Ping selbst ausgleichen. Dazu müssten wir eine ungleiche und asymmetrische Methode des Umgangs mit Latenzen implementieren. 

Es fühlt sich schlecht an, wegen eines niedrigen Pings erschossen zu werden, während ihr glaubt, in Deckung zu sein, aber genau das kann NIEDRIG passieren. Genauso schlecht fühlt es sich an, wegen eines hohen Pings erschossen zu werden, bevor ihr den Gegner überhaupt seht, was wiederum HOCH passieren kann. Aber zumindest sind Nach- und Vorteile gerecht verteilt.

Damit das völlig klar ist: Nicht alle Online-Spiele funktionieren so wie Apex. Bei einigen Spielen sind Spieler mit einem niedrigen Ping immer im Vorteil, aber wir haben aktiv beschlossen, das bei unserem System nicht so zu handhaben. Diese Entscheidung wurde getroffen, nachdem wir uns die jeweiligen Situationen genau angesehen und ernsthaft über Fairness im Online-Wettbewerb nachgedacht haben. 

Unser System lautet einfach gesagt wie folgt: Spieler mit niedrigem Ping sind gegenüber Spielern mit hohem Ping nicht immer im Vorteil und erleben darum manchmal Unsinn (für uns ist das ein technischer Begriff). 

Dieser Kompromiss wurde absichtlich in unser System integriert. Der Vorteil davon ist, dass ihr Apex Legends auch mit überdurchschnittlicher Latenz relativ gut spielen könnt, was vor allem für Spieler in ländlichen Regionen bzw. in Regionen mit instabiler Konnektivität sehr wichtig ist. Natürlich wollen wir den "Unsinn" reduzieren, wo wir nur können, aber wenn wir nun einmal mit nicht perfekten Umständen zurechtkommen müssen, sollte das Ergebnis für alle Spieler vergleichbar und fair sein.

Das ist die Erklärung für den "Unsinn", dass ihr hinter einer Wand erschossen oder getroffen werdet, wenn ihr gerade um eine Ecke biegt – Ursache ist fast immer ist eine Varianz der Latenz bzw. deren Verteilung durch unser System, die wir nicht verhindern können. Trotzdem geben wir weiterhin unser Bestes, derartige Situationen zu vermeiden, wo wir nur können. Das Spielerlebnis soll für jeden fair sein, und jeder soll dabei Spaß haben.

Manche meiner Schüsse werden nicht registriert.

Reden wir über Trefferregistrierung. Wird ein Schuss nicht registriert, bedeutet das, dass ihr denkt, ihr hättet das Ziel getroffen, aber der Server ist anderer Meinung. Aus eurer Sicht ist die Sache wegen Blutspritzern und entsprechender Geräusche klar, aber es erscheint kein Schadenszähler, und das ist in einem Shooter wie Apex Legends extrem unerfreulich. 

Ursachen dafür gibt es mehrere. Manchmal kann eine hohe Latenz oder Paketverlust dazu führen, dass eure lokale Simulation mit dem Server nicht völlig synchron ist. Ihr habt auf einen Punkt geschossen, wo ihr jemanden gesehen habt, aber tatsächlich war der zu dem Zeitpunkt schon nicht mehr dort. Leider erfahrt ihr das erst, wenn eure Version der Welt wieder aufgeholt hat.

Manchmal ist es auch nur ein Bug in der Physiksimulation des Spiels. Damit ihr sofort ein Feedback bekommt, verlassen wir uns in hohem Maße auf ein Prognosekonzept. Wenn ihr schießt, kennen wir die Ballistik der Waffe und können voraussagen, wo die Kugel lokal einschlagen wird, ohne diese Information vom Server holen zu müssen. Dadurch fühlt sich das Spiel reaktionsschneller an. 

Normalerweise sind sich Client und Server einig, und die Kugel schlägt an der prognostizierten Stelle ein. Früher hatten wir einige Bugs bei der Berechnung von Ballistik und Projektilflugbahnen (bei allen Waffen mit einer Kugelgröße, die kein Punkt war, wie zum Beispiel Scharfschützengewehre). Solche Bugs können schwer aufzuspüren sein, also haben wir für unsere Tests einen grafischen Hinweis eingebaut, durch den das Problem sofort zu erkennen ist. Leider ist dieser Diagnosecode (aufgrund von Problemen mit der Bandbreite) zu groß für das Live-Spiel, also müssen wir uns auf unsere internen Tests verlassen.

Immer wenn ein Treffer nicht registriert wird, zeichnen wir die Hitbox und die Flugbahn der Kugel (ungefähr, weil sie eine Kurve beschreibt, aber gut genug!). Dank dieser visuellen Hilfe erfahren wir, dass es passiert ist, und werden in unseren Server-Logs schneller fündig.

Unsere Fortschritte bei diesem Problem basieren auf zwei Ansätzen:

Zunächst einmal untersuchen wir ständig die verschiedenen Bugs, die zu Problemen bei der Treffererkennung führen. Außerdem haben wir Tools zur Automatisierung der Erkennung entwickelt, sodass Entwicklern neue Bugs gar nicht erst passieren. Daran werden wir weiterhin kontinuierlich arbeiten.

Der zweite Ansatz ist die Zusammenarbeit mit euch! Wenn Spieler uns Videos mit Problemen bei der Treffererkennung schicken, können wir leichter ermitteln, ob es sich um einen Bug handelt, den wir beheben müssen. Oft stellt sich bei diesen Videos nämlich heraus, dass ein Problem mit der Latenz und nicht mit der Treffererkennung vorliegt, also überprüft bitte eure Leistungsanzeige, bevor ihr ein Problem mit der Trefferregistrierung meldet. Wie bereits erwähnt, haben wir auf diese Weise aber auch schon diverse Bugs gefunden und behoben, sodass eine Meldung immer hilfreich ist, um das Spiel für alle Spieler besser zu machen. Vielen Dank im Voraus!

 

Was ist mit Bugs, die verhindern, dass ich mich anmelden kann, wie etwa "code:net"?

"Code:net" ist eine allgemeine Fehlermeldung, die angezeigt wird, wenn euer Spiel aus dem Server entfernt wurde. Ursache kann eine Vielzahl von Problemen sein, sowohl auf unserer als auch auf eurer Seite. Tatsächlich ist es so, dass einige der schwerwiegenden code:net-Bugs (und damit verbundener Bugs wie code:leaf usw.) eher mit den Diensten von Respawn zu tun haben, die das Spiel unterstützen. Dem gilt es nachzugehen.

Wir haben mehrere Maßnahmen ergriffen, um die Wahrscheinlichkeit eines code:net-Bugs zu verringern, und viele Spieler konnten ihr Problem lösen, indem sie unser Support-Team kontaktierte haben. Wenn ihr euch nicht anmelden könnt und die code:net-Meldung oder eine ähnliche erhaltet, meldet das bitte über die EA Hilfe-Website.

Da code:net eine allgemeine Meldung ist, kann sie durch eine Reihe unterschiedlicher Probleme ausgelöst werden. Wir konnten in den letzten Wochen einige davon erfolgreich lösen, wissen aber, dass noch einiges an Arbeit vor uns liegt. Meldet uns eure Probleme, dann geben wir unser Bestes, um sie so schnell wie möglich zu beheben. Glaubt uns, wir hassen diesen Bug genauso sehr wie ihr.

ÜBER DIE SERVER-TICKRATE

Jetzt kommt das ganz große Thema. Wir wollen damit transparent umgehen. Viele Spieler haben nach unserer Server-Tickrate gefragt, und warum wir nicht einfach von 20 Hz erhöhen, wie einige andere Online-Shooter auch. 

Wir haben erklärt, wie sich die Tickrate auf die allgemeine Aktualisierungsrate der Inhalte auf dem Bildschirm auswirkt, somit ist die Frage also völlig berechtigt. Allerdings ist es kniffliger, als ihr vielleicht denkt, die Tickraten von zwei Spielen miteinander zu vergleichen. Wir werden versuchen, zu erklären, warum das so ist. 

Die Tickrate eines Servers ist die Anzahl der Simulationen, die der Server pro Sekunde ausführt. Sie ist eine feste Zahl (siehe Abschnitt über Zeitlupe). Apex verwendet ein Schnappschussmodell zur Replikation. Das bedeutet, dass der Server am Ende jedes Ticks den Weltstatus speichert und an alle Clients repliziert. Dazu gehören viele Informationen, damit das Design unserer Waffen, Karten und Legenden optimal abgebildet wird. 

Um in Apex Legends erfolgreich zu sein, müsst ihr zahlreiche Informationen berücksichtigen, die überall auf der Karte passieren: Taktikfähigkeiten werden benutzt, passive aktiviert oder ultimative laufen ab, Carepakete werden abgeworfen, oder ein neuer Squad kommt in die Reichweite von Cryptos Drohne. Wir wollen, dass die Spieler nichts davon verpassen. Und unsere Designer können Spielzeuge und Tools mit wirklich globalen Auswirkungen erstellen. Viele Spiele berechnen bei jedem Tick nicht den kompletten Weltstatus, wodurch es irreführend wird, einen Vergleich zweiter Spiele nur aufgrund einer Zahl wie "20 Hz" vs. "30 Hz" anzustellen. 

Die Frage lautet: Was genau passiert bei jedem Tick? Wir wollen, dass der Weltstatus so präzise wie möglich ist, und deshalb speichern unsere Server bei jedem Tick den gesamten Weltstatus. Anderenfalls würden wir zwar wahrscheinlich einen Teil der Rechenlast auf unseren Servern einsparen, aber gleichzeitig auch an Präzision in unseren Simulationen verlieren, und das ist es uns nicht wert. 

Einfach gesagt: Je höher die Tickrate, desto höher die an alle Spieler gesendete Bandbreite. Bei einem Umstieg von einem Server mit 20 Hz auf einen mit 60 Hz würde die Bandbreite, die das Spiel nutzt, mit drei multipliziert. Heute verbraucht Apex Legends zu Beginn eines Spiels etwa 60 kB/s. Ein Server mit 60 Hz würde 180 kB/s verbrauchen. Das klingt vielleicht nicht nach sonderlich viel, ist es aber, und wir sind immer auf der Suche nach Möglichkeiten, die erforderliche Bandbreite zu reduzieren. 

Aber wo läge das Problem, wenn die Bandbreite ein wenig größer würde? Die Bandbreite für Spiele niedrig zu halten, ist viel entscheidender als zum Beispiel für Videostreams. Bei Anwendungen mit hoher Bandbreite (Streaming, Downloads usw.) lassen sich Schwankungen oder Ruckler leicht ausgleichen, indem Minuten eines Streams gebuffert werden, die Qualität etwas abgesenkt wird usw. In einem Download werden euch Schwankungen wahrscheinlich nicht angezeigt, und es ist euch vermutlich egal, ob die Geschwindigkeit um einige oder sogar Hunderte Millisekunden variiert. 

Spiele können sich diesen Luxus nicht leisten. Schon das Überspringen weniger Intervalle von 50 ms kann sich bereits schlecht anfühlen. Überspringt ihr dann noch ein paar, kommt es zu einer Todesspirale, weil immer größere Updates geschickt werden müssen, um euch wieder auf den aktuellen Stand zu bringen. Es gibt keine Ausnahmen, ihr müsst diese Updates erhalten, weil eurer Client einen perfekten Status der Welt benötigt, um präzise zu sein.

Dieses Beispiel zeigt, dass der Vergleich der Tickrate zwischen Spielen eine heikle Sache ist, da in den einzelnen Ticks unterschiedliche Informationen enthalten sind. Daneben gibt es eine weitere Komplikation: Die Obergrenzen für Eingaben, die Server empfangen und versenden können, sind nicht immer identisch, auch wenn sie dieselbe Tickrate haben. Um genau zu sein: In vielen Spielen ist es so, dass ein Server mit 60 Hz läuft und der Client auch nur 60 Hz-Eingaben senden kann. Wenn ihr 60 FPS habt, ist das in Ordnung, aber wenn euer Client mit 120 FPS läuft, verliert ihr die Hälfte eurer Eingaben. Das ist bei Apex Legends nicht der Fall. Wir verarbeiten problemlos eine variable Anzahl von Eingaben. (Nebenbei bemerkt: Je mehr FPS ihr in Apex habt, desto höher ist eure Bandbreitennutzung.)

Okay, wir haben nun einige potenzielle Nachteile einer höheren Server-Tickrate besprochen. Aber hat es nicht auch Vorteile, wenn man von 20 Hz auf 60 Hz umstellen würde? Kommt schon, Respawn! Würde das die Server nicht dreimal schneller und dreimal besser machen? Macht es einfach!

Unseren Erkenntnissen nach würde das nicht zu einem sinnvoll anderen Spielerlebnis führen, und wir wollen euch auch erklären, warum. 

Nehmen wir an, ihr habt im Durchschnitt einen Ping oder eine Latenz von etwa 50 ms. Denkt daran, dass euer Ping die Dauer einer vollständigen Hin- und Rückreise zwischen eurem System und dem Server misst. Falls also keine weiteren Probleme auftreten, wie schwankende Latenz oder ein Hardware-Lag (Anzeigeräte sorgen zum Beispiel für eine Verzögerung von 20-50 ms), erhält der Server eure Eingabe 25 ms (halber Ping), nachdem ihr eine Taste gedrückt oder die Maus bewegt habt. 

Da unsere Server 20 Hz haben, aktualisieren sie den Weltstatus alle 50 ms (1.000 ms in jeder Sekunde / 20 Ticks pro Sekunde = 50 ms pro Tick). Im schlimmsten Fall werden eure Eingaben also nach 75 ms (25 ms + 50 ms) vom Server verarbeitet. 

Um zu verstehen, was diese Verzögerung von 75 ms für euer Spielerlebnis bedeutet, müssen wir kurz über eure Framerate reden. Die Mathematik wird jetzt etwas knifflig, aber es muss sein: In einem Spiel mit 60 FPS braucht jedes Frame etwa 16,67 ms (1.000 ms pro Sekunde / 60 Frames pro Sekunde = 16,67 ms pro Frame). Wenn eure Eingaben wie in obigem Beispiel nach 75 ms vom Server verarbeitet werden und euer Spiel mit 60 FPS läuft, bedeutet das, dass die Verzögerung zwischen eurer Eingabe und ihrem Einfluss auf das Spiel ungefähr bei fünf Frames liegt (75 ms für jedes Update / 16,67 ms pro Frame = etwa 4,5 Frames, aufgerundet auf 5 Frames, weil es kein Halbbild gibt). 

Wenn man dieselben Berechnungen nun für einen Server mit 60 Hz durchführt, ergibt sich als maximale Verzögerung zwischen Eingabe und Verarbeitung durch den Server ein Wert von 41,67 ms (25 ms Ping + [1.000 ms / 60 Ticks pro Sekunde = 16,67 ms pro Tick] = 41,67 ms). 

41,67 ms sind definitiv besser als 75 ms, aber was bedeutet das für die Framerate? Gehen wir erneut davon aus, dass wir mit 60 FPS laufen. Da jeder Frame 16,67 ms erfordert, beträgt die Verzögerung zwischen euren Eingaben und dem Server etwa drei Frames (41,67 ms für jedes Update / 16,67 ms pro Frame = etwa 2,5 Frames, wieder aufgerundet auf 3 Frames, weil es immer noch kein Halbbild gibt). 

Zusammenfassend ergibt sich, dass Server mit 20 Hz etwa fünf Frames Verzögerung und Server mit 60 Hz drei Frames haben. Für die dreifache Bandbreiten- und CPU-Last spart ihr also zwei Frames Latenz, und das im besten Fall. Der Vorteil ist also tatsächlich vorhanden, aber er ist nicht sonderlich groß und hilft vor allem nichts bei anderen Problemen mit dem Lag (wie in Deckung erschossen werden), dem Internetanbieter oder Bugs (wie Trefferregistrierung und Zeitlupen-Server). 

Unser Beispiel hat die Veränderung der Umstellung von 20 Hz auf 60 Hz untersucht. Für andere Umstellungen, wie von 20 Hz auf 30 Hz oder auch 40 Hz, könnt ihr die Berechnungen selbst durchführen und werdet dann feststellen, dass der Gewinn bei der Framerate ähnlich gering ausfällt. Ihr müsstet die Tickrate schon drastisch erhöhen, bevor sie sich wirklich auswirken würde – selbst der Sprung von 20 Hz auf 60 Hz würde sich lediglich wie der Unterschied zwischen 58 FPS und 60 FPS anfühlen. Natürlich ist das mehr als nichts, aber wir sind fest davon überzeugt, dass es nicht ausreicht, um Änderungen an der Tickrate zur Priorität zu erklären, solange wir andere, effektivere Verbesserungen vornehmen können.

SCHLUSSGEDANKEN

Zum Schluss möchten wir noch eine Sache offen und deutlich anerkennen: Online-Probleme sind für Spieler ein realer und relevanter Frustrationsfaktor. Wenn ihr mit Lags, fehlenden Trefferregistrierungen oder Zeitlupen-Servern zu kämpfen habt, dann nervt das. Es holt euch aus dem Spiel und ist schlecht für die Motivation, denn eigentlich wollt ihr doch in der Rangliste nach oben klettern, kurz mal mit Freunden spielen oder einfach nur einen entspannten Abend verbringen. 

Über Online-Probleme zu sprechen, ist schwierig, denn wenn wir unsere Systeme erklären oder unseren Standpunkt zu Problemen wie Lag-Ausgleich oder Tickrate darlegen, kann das für Spieler, die einfach nur ein besseres Spiel wollen, ziemlich frustrierend sein. Solltet ihr selbst Probleme mit der Latenz, Bugs, die Server zum Absturz bringen, gehackten Konten oder sonst etwas haben, das euch beim Spielen von Apex Legends begegnet, wollt ihr wahrscheinlich gar nicht wissen, was wir gerade nicht machen. 

Letztlich geht es nur darum, das Spiel zu verbessern. Je besser das Online-Erlebnis für euch ist, desto mehr Menschen werden das Spiel spielen, und dadurch können wir diesen Job, den wir so lieben, weiterhin machen. 

Deshalb haben wir in diesem Blog einige Verbesserungen aufgeführt, die wir in naher Zukunft verfolgen werden:

• Echtzeit-Alarm zur schnelleren Identifizierung und Reaktion bei Problemen
• Implementierung von Tools zur Server-Identifizierung, damit wir problematische Server rasch entfernen und ersetzen können
• Konzentration auf Zeitlupen-Server – das Entfernen problematischer Server ist ein wichtiger Schritt, aber unser Ziel ist es, deren Häufigkeit bei Code-Änderungen drastisch zu reduzieren
• Reduzierung der Latenz mit besserer Optimierung neuer Features
• Behebung von Bugs bei der Trefferregistrierung und Entwicklung automatisierter Erkennungstools, um neue Bugs zu vermeiden

Aber ihr sollt wissen, dass das nicht alles ist, woran wir arbeiten. Wir arbeiten mit Partnern von der Server- bis zur Internetanbieter-Ebene daran, in unsere Online-Infrastruktur zu investieren und sie zu verbessern, damit am Ende die Spieler weniger Probleme melden müssen und insgesamt ein besseres Spielerlebnis haben. Wir werden in einem künftigen Post mehr zu diesen Bemühungen sagen, sobald wir erkennen, dass unsere Arbeit Früchte trägt. 

Wir werden mit euch mehr über die Probleme kommunizieren, die uns beschäftigen, und dabei hoffentlich eine gemeinsame Sprache finden, in der wir über die Ursachen dieser Probleme diskutieren können. Deshalb haben wir diesen Blogartikel geschrieben. Wir hoffen, dass er unsere Denkprozesse nachvollziehbar macht und das technische Hexenwerk eines Online-Shooters entmystifiziert. Und wir hoffen, dass es der Beginn weiterer Gespräche ist.

Danke fürs Lesen! 

- Samy (Ricklesauceur) & das Apex Legends-Team

[Quelle findet ihr noch auf der EA Website: https://www.ea.com/de-de/games/apex-legends/news/servers-netcode-developer-deep-dive]