AW: Battlefield: Technik zur Zerstörung der Spielwelt powered by Cloud
Die Idee ist sehr gut. Bei Physiksimulationen in Spielen verwendet man oft einen fixen Zeitschritt unabhängig der Bildwiederholungsrate, z.B. 16.7 ms oder 33.3 ms. Jedoch gibt es da eine Varianz, man wird nie genau wissen wieviel das Delta zwischen zwei Frames ist. Es ist lediglich im Mittel genau. Die Varianz kann weniger Bruchteile einer Millisekunde sein. Das hört sich nach wenig an, wenn man jedoch ein semi-stabiles Integrationsverfahren verwendet, divergiert das Ergebnis ziemlich schnell über mehrere Zeitschritte. D.h. Berechnen wir dasselbe Objekt mit denselben Startbedingungen, kann die Simulation eine andere Flugbahn berechnen, wenn wir z.B. den Fall eines Mauerstücks darstellen wollen. Der Effekt dieser Divergenz ist klein und nicht merkbar zwischen zwei Simulationen, aber er ist da.
Nun machen auch bei einem Multiplayerspiel wie Battlefield 64 Leute diesselbe Physikberechnung aber mit Abweichungen ohne, dass diese jemals zum Konsensus geführt werden. Was heisst das? Bröckelt ein Haus in Battlefield V, dann gibt es genau ein paar vordefinierte Zustände, in dem sich das Haus befinden kann, z.B. sind die Wände wie Legobausteine zusammengefügt, von denen man nach und nach Teile entfernen kann und das kann man mit wenig Information zu übertragen, allen Clients mitteilen. Für diese gibt Zustände es auch Kollisionsabfragen. Das Geröll hingegen, das herunterfällt während der Zerstörung eines Gebäudes, das hat keine Kollisionsabfrage, d.h. als Spieler bleibt man darin nicht stecken. Warum? Es ist eine super komplexe Physiksimulation, die wir alle Clients berechnen, mit Fehlern, und diese wird nicht über den Servern zwischen allen Clients abgeglichen und zum Konsensus gebracht. Würde man jetzt z.B. deine Kollisionsabfrage verwenden, um deinen Spielerstandard an die anderen Clients zu schicken, kann es Abweichungen geben, die den Spielverlauf erheblich stören. Ein Geröllstück stoppt aus deiner Sicht einen Schuss des Gegners, von seiner Sicht aber nicht. Der Server kann das nicht auflösen. Wie würde mann in diesem Fall vorgehen? Welcher Spielzustand ist gültig?
Die Lösung? Wir berechnen die Physiksimulation auf dem Server für jeden Servertick. Schicken dann die Transformationsmatrizen an die Clients, diese können dann die 3D Objekte bewegen, ohne die Bewegung simulieren zu müssen. Wir sparen also alle massiv CPU Power, haben das Konensusproblem gelöst und das bei einem Problem, dass so wenige Bytes zur Übermittlung benötigt, dass es kein Problem ist.
Übrigens ist genau dies, was Stadia meint mit "1000 Spieler Multiplayer". Mit der Cloud kann man das Konsensusproblem viel besser lösen. Das ist unabhängig davon, ob man nun alle Clients auch in der Cloud rendern lässt und den ganzen Output komprimiert und streamed. Was DICE hier tun möchte, ist nur den Konsensusaspekt von Physiksimulationen lösen, womit man dann Kolissionsabfragen auf allen Physiksimulationen erlauben kann. Grundsätzlich ist dies übrigens die einzige grosse theoretische Hürde, die man für Multiplayerspiele mit so vielen Spielern hat. Konsensus. Was übrigens auch ein Faktor ist. Server kann nur Konsensus erreichen, wenn genügend Spieler innerhalb der Tickrate Information zurück schicken. Wenn man eine Varianz an Latency bei den Spieler erlaubt, dann gibt es immer eine untere Schranke für die Zeit in der ein Server Konsensus mit den Clients erreichen kann. D.h. bei 1000 Spielern wird ein Server mit einer Tickrate von, sagen wir mal, 200ms laufen müssen, damit der Spielstand abgeglichen werden kann, nur weil man auf die Antwort aller Clients warten will. Wenn nun im Falle von Stadia auch alle Clients in der Cloud sind, dann kann Stadia garantieren, dass die 1000 Clients und der Spieleserver immer 1ms Latenz zueinander haben. D.h. plötzlich kann man auch mit einer Varianz von 1ms immernoch bis zu 500 mal pro Sekunde einen Konsensus erreichen. Dann ist dies nicht mehr der entscheidende Faktor, sondern der Spieleentwickler entscheidet, was er alles in der im nun neu frei zur Verfügung stehenden Zeit berechnen will.