Arena Commander Patch Update

Grüße Bürger,
Grüße Bürger,

Letzte Woche haben wir über unseren Prozess zur Lösung der Probleme mit Verzögerungen und Gummibändern informiert, die sich derzeit auf den Mehrspielermodus des Arena Commander auswirken. Wie du weißt, haben wir die Spielerbasis um das Achtfache erhöht, als wir Patch 12.4 veröffentlicht haben. Dadurch wurden eine Vielzahl von auftretenden Problemen innerhalb des Spiel-Clients, der Spielserver und der Backend-Infrastruktur aufgedeckt, die sich erst bei der erhöhten Spielerauslastung bemerkbar machten. Wir haben viele Fortschritte bei der Lösung dieser Probleme gemacht und große Verbesserungen an allen drei Fronten erzielt, aber der Patch ist heute nicht releasefähig. Diese Art von Tests ist genau der Grund, warum wir uns für das offene Entwicklungsmodell entschieden haben. Die Entdeckung dieser Art von Problemen zu diesem frühen Zeitpunkt im Prozess wird das Spielerlebnis auf lange Sicht erheblich verbessern und unsere Effizienz erhöhen, indem wir es von Anfang an richtig machen.

Patch 12.5 ist dafür verantwortlich, die hier abgebildete Jukebox zu den Hangars der aktuellen Abonnenten hinzuzufügen, damit diese ihre Hangars mit ihrer Lieblingsmusik beleben können. Deine Jukeboxen wurden deinen Accounts zugeordnet, erscheinen aber erst in deinen Hangars, wenn der Patch live geht. Zusätzlich sprachen wir diese Woche in Around the Vers über eine mysteriöse neue Vanduul-Drohung, die UEE-Schiffe zerstört. Diese Bedrohung wird mit 12.5 hinzugefügt, ab diesem Zeitpunkt werden die Bürger ermutigt, nach ihr zu suchen!

Obwohl es heute keinen Patch geben wird, möchten wir Ihnen gerne mitteilen, woran wir bisher gearbeitet haben und wie wir das Problem angegangen sind. Das QA-Team hat intensiv an der Untersuchung der Verzögerung gearbeitet, die auf den öffentlichen Servern auftritt. Wir wissen, dass dies eine große Frustration war, und die Qualitätssicherung hat ihr ganzes Gewicht darauf verwendet, dieses Problem zu isolieren und zu reproduzieren, damit die Ingenieure diese Probleme lösen können.

Im Arena Commander-Multiplayer erhält Ihr Client Updates von Remote-Clients über den Server und im Falle einer Bewegung simuliert das IFCS Ihres lokalen Clients tatsächlich die Physik jedes Remote-Clients, die Sie anhand dieser Updates sehen. Ihr Client meldet dann alle Positions- und Orientierungsdaten für jeden der Remote-Clients, die Sie simulieren, an den Server zurück. Der Server überprüft dies autoritativ anhand seiner eigenen Berechnungen und derjenigen, die von den Remote-Clients selbst gemeldet werden. Wenn es Abweichungen in den gemeldeten Zahlen gibt, stellt der Server Ihrem Client zur Verfügung, wie weit seine Remote-Client-Simulationen aus sind, und injiziert diese in die IFCS-Physik-Berechnungen, um die Remote-Clients zu schubsen, die Sie beim Fliegen wieder an ihre richtige Position zurückbringen. Wenn die Divergenz zu groß wird, als dass IFCS die entfernten Clients sanft anstößt, werden sie in ihre richtige Position gebracht und die Simulation beginnt von neuem. Da wir dieses Problem untersucht haben, drehte sich alles darum, herauszufinden, was die Simulationen von Remote-Clients manchmal für einige Leute so unterschiedlich vom Server und den Remote-Clients selbst werden lässt, dass der Server einen Warp erzwingt.

Wir untersuchten zunächst mögliche Probleme mit den Spielservern, indem wir einige Optimierungen zum Lastausgleich durchführten und die Anzahl der Server auf einem physischen Computer von 8 auf 2 reduzierten, was den Netzwerkverkehr von jedem Computer drastisch reduzierte und das CPU-Pegging reduzierte, aber nicht die Verzögerung reduzierte, die die Spieler sahen. Es führte jedoch zu einer erhöhten Stabilität und minimiert Server-CPU-Frame-Spitzen, was die Leistung der Spieler auf der ganzen Linie verbessern wird.

Wir näherten uns der Situation dann von der Kundenseite aus und schufen eine kontrollierte Umgebung, in der niemand irgendwelche Waffen schoss oder einen Schub benutzte, und begannen dann, die Anzahl der Spieler im Laufe der Zeit zu erhöhen. Als wir feststellten, dass dies zu keiner Verzögerung führte, begannen wir dann, weitere Variablen in das Spiel einzubringen.

Das Schießen von Waffen, ohne einen Spieler zu treffen, verursachte kein Problem, aber sobald die Schiffe anfingen, aufeinander zu schießen, begann die Verzögerung, und die Spieler sprangen herum. Wir konnten diese Verzögerung reproduzieren, aber wir brauchten eine genauere Ursache, also haben wir versucht, sie einzugrenzen.

Im Gespräch mit dem Ingenieurteam spekulierten sie, dass der durch das Abfeuern von Waffen und das Abfangen von Schildaufschlägen verursachte Leistungsabfall wiederum die verfügbare Leistung für die Triebwerke reduzieren könnte. Es war möglich, dass aufgrund von Verzögerungen oder CPU-Spitzen die für Triebwerke verfügbare Energiemenge nicht richtig vom Remote-Client an den Server an Ihre Maschine übertragen wurde, damit Ihre Physiksimulation berücksichtigt werden konnte. Dies würde dazu führen, dass die Synchronisation der Triebwerke zwischen den Spielern ausgeschaltet war, was zu einem Positionssprung bei unregelmäßigen Manövern führte. Das Ingenieurwesen bewaffnete die QA dann mit einer Version des Spiels, die es uns ermöglichte, eine größere Kontrolle über die Triebwerke zu haben, so dass wir das Problem lokalisieren konnten.

Nachdem wir alle Energiefluktuationen zu den Triebwerken deaktiviert und die maximale Leistung für jedes Triebwerk aktiviert hatten, konnten wir das Problem trotzdem lösen, wenn auch seltener. Dieser Test offenbarte ein Problem in der Art und Weise, wie die Schilde in riesigen Spitzen Strom verbrauchen und führte zu einigen Verbesserungen des Gleichgewichts und der Codehärtung....

Unser Netzwerkteam untersuchte die Paketgröße und die Bandbreite. Ihre Bemühungen schienen auch das Spielerlebnis verbessert und die Paketgröße und damit den Netzwerkverkehr drastisch reduziert zu haben, aber sie haben das Problem nicht vollständig gelöst.

Gleichzeitig haben wir einige zusätzliche Änderungen an der Art und Weise eingeführt, wie Server Informationen protokollieren und speichern. Wir entdeckten zuerst, dass bestimmte unkritische Fehler die Serverprotokollierung spammen und Leistungseinbußen verursachen, die zu Simulationsunterschieden führen können. Wir haben die Einstellung auf das Protokollierungssystem angepasst, um Spam zu eliminieren, und wir werden die Protokollierungsfunktion auch komplett vom Haupt-Thread entfernen, so dass ihre Auswirkungen gemildert werden. Auch hier scheint dies die Probleme verbessert zu haben, aber nicht vollständig zu beseitigen. Es hat die Auswirkungen auf die Verbesserung der Serverstabilität und -leistung gehabt.

Wir generieren heute Abend einen Build, der Änderungen an der Art und Weise einführt, wie wir physikalische Berechnungen synchronisieren. Diese Änderungen, die dazu beitragen, dass alle Clients und der Server besser mit den Zeitschritten der Physik synchronisiert sind, sollten die Häufigkeit von Abweichungen zwischen Client-, Server- und Remote-Client-Physik-Simulationen stark reduzieren und uns bessere Werkzeuge an die Hand geben, um sie zu erfassen und zu korrigieren, ohne zu verzerren.

Nun, da ich dies schreibe, haben wir gerade ein neues potenzielles Problem aufgedeckt, das dazu beitragen könnte, dass die schlechte Mehrspieler-Synchronisation mit unsachgemäß gehandhabten Client-Trennungen zu tun hat. Wir müssen das am Wochenende untersuchen.

Die großartige Nachricht ist, dass wir selbst dann, wenn wir einen Weg eingeschlagen haben, der das Gummiband nicht direkt repariert hat, das Spiel verbessert haben. Die Arbeit, die in 12.5 steckt, wird nicht nur dieses spezielle Problem beheben, sondern auch das Arena Commander-Erlebnis rundum verbessern. Wir haben auch direkt an einigen anderen Korrekturen für 12.5 gearbeitet, die mehr Stabilität in der Mehrspielererfahrung bringen sollten und die Probleme beheben, die von den Unterstützern gesehen wurden. Wie folgt:

An einem Spiel teilnehmen: Derzeit wird beim Beitritt zu einem Server ein großer Datenstau übertragen, der zu Verzögerungen und Teleporting führen kann. Unsere Netzwerkingenieure haben an Möglichkeiten gearbeitet, diese Daten zu komprimieren, was die Größe dieser Verbindungspakete um 40% reduziert. Die aktuelle Bandbreitenauslastung können Sie dem mitgelieferten Datendiagramm entnehmen.

Versucht, vollständige Server zu verbinden: Server haben derzeit eine kleine Verzögerung, die anzeigt, dass eine maximale Spieleranzahl erreicht wurde. Das bedeutet, dass ein Server fast voll sein kann und eine beliebige Anzahl von Spielern versuchen kann, sich anzuschließen, wobei nur einer von ihnen einsteigt und der Rest zurück in den Hangar geworfen wird. Wenn die Spieler gehen und den Server wieder fast voll machen, kann dieses Problem während des gesamten Spiels auftreten, und in Verbindung mit der hohen Bandbreite einer Spielerverbindung verursacht dies eine ernsthafte Verzögerung. Unsere Serveringenieure arbeiten derzeit an einer Lösung für dieses Problem.

Zurück zum Hangar getreten: Unser bisher noch implementiertes VoIP-System verband sich mit allen Spielern, trennte sich aber nicht, wenn ein Spieler unerwartet abbrach, was dazu führte, dass die Mehrheit der Kickbacks zu Hangarproblemen in der Öffentlichkeit führte. Ein Fix dafür wurde erstellt.


Vielen Dank, dass Sie sich an dem Entwicklungs- und Testprozess mit uns beteiligen, Ihre Bemühungen, diese Art von Problemen aufzudecken und zu katalogisieren, waren äußerst hilfreich und wir wären nicht in der Lage, sie alle ohne Ihre Teilnahme zu finden! Wir beheben diese Multiplayer-Probleme so schnell wie möglich und freuen uns darauf, die Tests des Arena Commander so schnell wie möglich auf alle Bürger auszuweiten. Wie Sie sehen können, gab es eine Menge Arbeit, um den Multiplayer auf der ganzen Linie vom Client über den Server bis hin zur Backend-Infrastruktur zu verbessern, und wir sind der Meinung, dass der 12.5-Patch das Spielerlebnis erheblich verbessern wird, sobald er fertig ist. Wir werden Sie wissen lassen, wie es uns nächste Woche geht, und Patch 12.5 veröffentlichen, sobald wir überzeugt sind, dass es eine umfassende Verbesserung der Arena Commander Multiplayer-Erfahrung bietet.

Greetings Citizens,
Greetings Citizens,

Last week, we posted about our process for solving the lag and rubber banding issues currently impacting Arena Commander’s multiplayer mode. As you know, we increased the player base by eight fold when we released patch 12.4. Doing so exposed variety of emergent issues within the game client, game servers, and backend infrastructure that only became apparent under the increased player load. We’ve made a lot of progress in addressing these issues and have seen great improvement on all three fronts, but the patch is not ready for release today. This kind of testing is exactly the reason why we chose to pursue the open development model. The discovery of these kinds of issues this early in the process are going to greatly improve the player experience in the long run and increase our efficiency by getting it right from the beginning.

Patch 12.5 is responsible for adding the jukebox, pictured here, to the Hangars’ of current subscribers so they can liven up their hangars with their favorite music. Your jukeboxes have been attributed to your accounts, but will not appear in your Hangars until the patch goes live. Additionally, on this week’s Around the Verse, we talked about a mysterious new Vanduul threat destroying UEE ships. This threat will be added with 12.5, at which point Citizens are encouraged to go hunting for it!

While there will not be a patch today, we would like to share what we’ve been working on so far and how we’ve been approaching the problem. The QA Team has been hard at work investigating the lag that is being experienced on the public servers. We know that this has been a huge frustration, and QA has thrown its full weight against isolating and reproducing this problem so that engineers can solve these issues.

In Arena Commander multiplayer your client is receiving updates from remote clients via the server and, in the case of movement, your local client’s IFCS is actually simulating the physics of each remote client that you see based on these updates. Your client is then reporting back to the server all the positional and orientation data for each of the remote clients that you are simulating. The server is authoritatively checking this against its own calculations and those being reported by the remote clients themselves. If there is divergence in the reported numbers the server will provide your client with how far its remote client simulations are off and inject that into the IFCS physics calculations to nudge the remote clients you see back to their proper positions as they fly. If the divergence becomes too large for IFCS to gently nudge the remote clients then they are warped to their proper position and the simulation commences again. As we have been investigating this issue it has all revolved around discovering what is causing the simulations of remote clients to sometimes for some people become so divergent from the server and the remote clients themselves that the server is forcing a warp.

We first investigated potential issues with the game servers by performing some optimizations to load balancing and by reducing the number of servers on a physical machine from 8 to 2, which dramatically decreased network traffic from each machine and reduced CPU pegging but did not reduce the lag players were seeing. It did however result in increased stability and minimizes server CPU frame spikes which will generally improve performance for players across the board.

We then approached the situation from the client side, creating a controlled environment in which no one shot any weapons or used any boost, and then began increasing the number of players over time. Noticing that this yielded no lag, we then started to introduce more variables into the match.

Shooting weapons without hitting any players caused no issue, but once ships began to fire on each other, lag began to crop up with players skipping around. We were able to reproduce that lag, but we needed a more specific cause, so we attempted to narrow it down.

Speaking with the engineering team, they speculated that the power drain caused by firing weapons and absorbing shield impacts could in turn be reducing the available power to thrusters. It was possible that due to lag or CPU spikes the amount of power available for thrusters wasn’t being properly propagated from the remote client to the server to your machine for your physics simulation to account for. This would cause synchronization of thrusters across players to have been off, causing positional jumping when performing erratic maneuvers. Engineering then armed QA with a version of the game that allowed us to have greater control over the thrusters so that we could pinpoint the problem.

Once we disabled all energy fluctuations to the thrusters and enabled maximum power to each, we were still able to get the problem to occur, although less frequently. This testing exposed an issue in the way that the shields consume power in giant spikes and resulted in some balance improvements and code hardening..

Our networking team investigated packet size and bandwidth issues. Their efforts also seemed to have improved the player experience and drastically reduced packet size and thusly network traffic however it did not entirely resolve the issue.

Concurrently, we introduced some additional changes to the way that servers are logging and storing information. We first discovered that certain non-critical errors were spamming the server logging and causing performance drops which can lead simulation discrepancies. We’ve adjusted setting to the logging system to eliminate spam and we are going to be moving the logging function off the main thread entirely as well so that its impact is lessened. Again, this has seemed to have improved the issues but not eliminate them entirely. It has had the knock on effect of improving server stability and performance.

We are generating a build tonight that introduces changes to the way that we synchronize physics calculations. These changes to help better keep all clients and the server in better synch on physics time steps should greatly reduce the incidence of divergence between client, server, and remote client physics simulations and give us better tools to catch and correct for it without warping.

Now, as I am writing this we have just uncovered a new potential issue that could contribute to the incidence of poor multiplayer synchronization having to do with improperly handled client disconnections. We’ll have to investigate this over the weekend.

The great news is that even when we’ve pursued an avenue that hasn’t directly fixed the rubberbanding, we’ve still ended up improving the game. The work that’s going into 12.5 isn’t just going to fix this specific issue, it’s going to enhance the Arena Commander experience all around. We’ve also worked directly to on some other fixes for 12.5 that should bring more stability to the multiplayer experience and correct issues backers have been seeing. As follows:

Joining a Game: Currently when joining a server, a large spike of data is transmitted, which can cause lag and some teleporting. Our network engineers have been working on ways to compress this data which will reduce the size of these connection packets by 40%. You can see the current bandwidth usage in the included data graph.

Attempts to join full servers: Servers currently have a bit of a delay marking that a max player count has been hit. This means that a server can be almost full, and any number of players can try and join, with only one of them getting in, and the rest getting kicked back to hangar. With players leaving, making the server almost full again, this issue can consistently occur throughout the match, and coupled with the high bandwidth of a player connection cause some serious lag. Our server engineers are working on a fix for this right now.

Kicked back to hangar: Our as of yet implemented VOIP system was connecting to all players, but not disconnecting when a player dropped unexpectedly, causing the majority of kick back to hangar issues on public. A fix for this has been created. Thank you for engaging in the development and testing process with us, your efforts exposing and cataloging these types of issues has been immensely helpful and we wouldn’t be able to find them all without your participation! We fixing these multiplayer issues as quickly as possible and look forward to further expanding the testing of Arena Commander to all Citizens as soon as we can. As you can see there has been an awful lot of work going into improving the multiplayer across the board from the client to the server to the backend infrastructure and we feel that the 12.5 patch will greatly improve the player experience once it is ready. We’ll let you know how we’re doing next week, and will issue patch 12.5 as soon as we’re confident that it offers a broad improvement to the Arena Commander Multiplayer experience.