PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : (Siedler IV) Desyncs und eine Maßnahme diese evtl. seltener Auftreten zu lassen



CookieButton
28-01-19, 03:35
Hallo Community,

ich habe mich nochmals näher mit dem Spiel beschäftigt und seine Funktionsweise im Disassembly erörtert um zu verstehen was wo und wie passiert und was man (selber) vielleicht machen kann.
Durch diese Analyse bin ich zu folgender Funktionsweise gekommen (ich versuche das für Laien verständlich zu erklären):

Wie ein Desync erkannt wird:
Das Spiel arbeitet in Ticks. Man kann sich das so ähnlich vorstellen wie ein Bild von dem Spiel, das auf dem Bildschirm dargestellt wird.
Ein Tick repräsentiert den logischen Status des Spieles (wo steht welche Einheit, was macht diese etc.).
Sowohl in festgelegten Intervallen als auch zufällig vereinbaren alle Spielparteien, bestimmte Ticks zu vergleichen und auf Unterschiede zu testen.
Dazu wird entweder der ganze Tick oder evtl. ein festgelegter zufälliger Teil davon (das weiß ich nicht so genau, die Hashberechnung sollte aber zumindest heutzutage aufgrund der verwendeten Art sehr sehr schnell sein) serialisiert (Speicherstände sind zum Beispiel die Karte + serialisierte Restlogik + Komprimierung zwecks Größenersparnis). Diese Prüfsumme (in diesem Falle eine CRC Prüfsumme) wird dann untereinander ausgetauscht und mit dem eigenen Ergebnis verglichen. Kommt es zu unterschiedlichen Prüfsummen für denselben Tick, dann sind die einzelnen Spiele nachweislich nicht mehr synchron.

Wie der Multiplayer funktioniert:
Die einzelnen Spieler kriegen über das Netzwerk die Eingabeaktionen der anderen Spieler zugesendet zu einem bestimmten Tick (in der Zukunft), und machen diesen dann alle zusammen. Wieso das so ist erkläre ich gleich.

Beispiel:

Das Spiel hat einen Standardverzögerungswert von 500ms. Bei 30 Ticks pro Sekunde wäre das eine Verzögerung von 15 Ticks.

(Momentaner Tick): Aktion

(100): Spieler rot will einen markierten Soldaten bewegen und klickt auf die entsprechende Kartenposition. Das Spiel sendet den Befehl, dass gemeinsam bei Tick 115 diese Aktion ausgeführt werden soll.
(101): Keine Aktion
(102): Keine Aktion
(103): Keine Aktion
...
(115): Alle Computer erinnern sich daran, dass jetzt Spieler rot diesen einen Soldaten da und da hin bewegen will, und führen den Befehl gemeinsam aus.

Das Problem ist natürlich folgendes: Wenn eine Spielpartei diesen Befehl bekommt, ist einige Zeit vergangen und das eigene Spiel ist schon einen Tick oder mehr weiter. Dies passiert aufgrund der Netzwerkverzögerung. Viele Lösungen z.B. Server der Source-Engine haben mehrere Ticks gespeichert und "spulen" dann das Spiel zurück und entscheiden so z.B. über Treffer oder Verfehlung. Diese Lösungen sind zentralisiert und der Server entscheidet letzten Endes was passiert. Das führt dann gerne zu Unmut bei den Spielern ("Ich hab den doch getroffen").
Siedler IV umgeht dieses Problem teilweise. Das eigene Spiel selbst wird wie gezeigt lokal verzögert dargestellt (Die Source-Engine macht das auch, aber bitte schlagt mich jetzt nicht bei den Details tot, das ist nur zur Veranschaulichung). Das passiert auch im Einzelspieler. Man kann das selber leicht sehen:
Erfahrenen Spielern ist z.B. bestimmt schonmal aufgefallen, dass bei einer Baustelle, die pausiert und fortgesetzt wird, wenn die Priorität gesetzt ist, dass ganze etwas verzögert auftritt und hin und her flackert. Das Einzelspielerspiel ist auch hier verzögert und simuliert die Spielereingaben zu einer späteren Zeit. Das Einzelspielerspiel ist im Prinzip auch ein Mehrspielerspiel.

AI Berechnungen sind kostbar. Häufig ist mir auch bei größeren Kämpfen aufgefallen, dass das Spiel ruckelt, auch wenn es glaube ich nur mit 30 Ticks pro Sekunde läuft (auf jeden Tick folgt ein Bild).
Nun gibt es ein Problem, wenn das Spiel bei den Spielern unterschiedlich schnell läuft und diese Eingabeaktion als Paket erst dann kommt, wenn der Tick bereits ausgeführt ist. Das Spiel selbst hat nicht die Möglichkeit zurückzuspulen. Und die Verzögerung reicht nicht mehr.

Das obige Beispiel nochmal:

Alle Parteien sind bei Tick 115. Aufgrund eines Rucklers bei Spieler Rot liegt dieser genau 533ms bzw. 16 Ticks zurück, bei Tick 99.

(Roter Spieler bei Tick 99): Spieler rot will einen markierten Soldaten bewegen und klickt auf die entsprechende Kartenposition. Das Spiel sendet den Befehl, dass gemeinsam bei Tick 114 diese Aktion ausgeführt werden soll.
(Andere Parteien bei Tick 115): Erhalten den Befehl bei Tick 114 den Soldaten zu bewegen. Der Befehl wird guten Willens ausgeführt, obwohl die Ausführung zu spät ist.
...
(Roter Spieler hat schnell hintereinander ein paar Ticks berechnet um wieder aufzuholen und ist bei Tick 114 angelangt):
Rots Computer führt den Befehl bei Tick 114 aus. Weil das Spiel bei Tick 114 einen anderen Zustand hat als bei 115, verlaufen die Spiele unterschiedlich und diese Unterschiede kaskadieren.

Der Lösungsansatz

Genauergenommen ist dies kein Lösungsansatz. Er verändert nicht, wie das Spiel sich in diesem Falle verhält. Sollte die Erklärung aber richtig sein, wird es die Wahrscheinlichkeit, und nur die Wahrscheinlichkeit verringern, dass es zu einem Desync kommen sollte, ein Paket also durch Performanceunterschiede zu spät ankommt.
Diese "Verzögerung" ist im Spiel einstellbar.

Es handelt sich um die Variable "NetworkTimeDelta" unter "/Config/Network.cfg".
Standardwert ist hier bei 500ms. Große Werte können das Spiel beim Kartenladen abstürzen lassen. 1000 z.B. geht.
Das setzt voraus, dass alle Spielparteien denselben Wert eingegeben haben!!!

Möglichkeiten seitens der Entwickler dies zu beheben/verbessern, wären z.B.:
-Resynchronisation nach Erkennung eines Desyncs
-Verbesserung der Performance
-Kurze verabredete Pausierungen von Spielern die im Vergleich zu anderen etwas "voraus" sind im Laufe des Spieles, weil sie schneller und/oder weniger Berechnungen durchführen lassen. -> Das Spiel besitzt die Fähigkeit clientenabhängig zu pausieren, damit andere Spieler aufholen können. In welchem Rahmen und wie gut/ob das funktioniert, kann ich nicht beurteilen
-Erkennung verpasster Befehle und entsprechende Neuverabredung (die Neuverabredung müsste dann in obigem Beispiel aber auch rechtzeitig beim roten Spieler ankommen, bevor dieser seinen Schritt ausführt. Das Ganze wird komplizierter umso mehr Spieler an dem Spiel teilnehmen.)

Vorausgesetzt meine Einschätzung stimmt.
Es kann natürlich sein, dass trotz gleicher Eingaben zur gleichen Zeit unterschiedliche Systeme zu anderen Ergebnissen und damit Spielaktionen kommen können. Das geht z.B. durch Zufallszahlen, Gleitkommaberechnungen, unterschiedliche Betriebssysteme, Hardware, Multithreading, usw., und dass es dann dadurch zu Desyncs kommt.
Beispielsweise können verschiedene Computer für dieselbe Zahlenberechnung unterschiedliche Ergebnisse rausbekommen. Dies ist bei Gleitkommaberechnungen der Fall, da diese nur eine begrenzte Präzision haben, weil eine Kommazahl im Speicher immer denselben Speicherplatz hat, aber für den Menschen unterschiedlich komplexe Zahlen speichern muss.

Beispiel:
15.5 vs. 15.13 vs. 15.(Periode)15

In unserer Darstellung sind diese Zahlen 3, 4 oder unendlich viele Ziffern lang. Bei Computern legt man hier eine Genauigkeitsgröße fest und belässt es dabei. Diese betrifft sich nicht auf Nachkommastellen, sondern eine Kombination nach der Formel:
m*b^e

b ist idR festgesetzt auf 2.

Die mehr oder wenig beliebig gewählt werden um Zahlen mit derselben Speichergröße im Binärformat so präzise wie möglich darstellen zu können.

Beispiel Gleitkommazahlberechnung mathematisch korrekt:
15.0 / 2.0 = 7.5

Wäre bei einem Computer z.B.
15.00001 / 1.99999 = 7.4997

Da Systeme anders funktionieren können, kann das Ergebnis auf einem anderen Computer so aussehen:
14,9999 / 2.0001 = 7.5001

Mehrere Berechnungen hintereinander sorgen natürlich dafür, dass der Berechnungsfehler unterschiedlich groß ausfällt.

Sind solche Berechnungsfehler schuld daran, dass das Spiel auf unterschiedlichen Rechnern unterschiedlich läuft, kann der oben genannte Trick z.B. gar nicht helfen.

Achso, übrigens, nochmal an BB falls hier einer mitliest.
Ich würde gerne unentgeldlich an S4 arbeiten und die Fehler (es sind ja ehrlich gesagt extrem viele kleine und aber auch große das Spiel kaputt machende) beseitigen. S4 war das erste von mir selbst gekaufte Spiel in meinem Leben und ich würde es gerne nach 18 Jahren vernünftig spielen können. Ich wohne in der Nähe von Düsseldorf. Vielleicht geht sowas in Form eines unbezahlten Praktikums? Meine PNs sind offen. :p

Gute Nacht Leute und frohes Siedeln!

EDIT vom 04.04.2019: Mehr Details und Beispiele, Tippfehler korrigiert.

Morphoiz
28-01-19, 19:36
Danke für deine interessante Einschätzung! War auch für einen Laien wie mich ein interessanter Einblick.

Viel Glück im Hinblick auf deinen letzten Absatz, es wäre für die Community nur von Vorteil, wenn jemand der offensichtlich so leidenschaftlich beim Thema dabei ist, bei BB mitarbeitet. ;-)

TheNicklander
29-01-19, 19:22
Ich denke mal, Ubisoft ist den Spielern was schuldig. Irgendwie muss der Kaufpreis ja auch gerechtfertigt werden, ganz zu schweigen davon, dass Versprechen eingehalten werden müssen. Da die momentanen Entwickler ganz offensichtlich massive Probleme haben die Fehler zu beheben, kommt mir der Vorschlag von Cookie wie ein Segen. Fakt ist, dass Cookie/MuffinMario mit Fixes, Community Tools und Analysen bis jetzt mehr geleistet hat als so manch bezahlter Angestellter. Man erinnere sich, viele HE-Features gab es schon für das Original in der Form von Mods und Patches. Siehe zB meinen Widescreen Fix von 2014! Bitte nicht in den falschen Hals kriegen, aber die Kindheitskrankheiten sind nun mal immer noch da und das ist ein grosses Problem weil somit der Siedelspass gegen 0 tendiert.

Liebes Ubisoft Team, ich hoffe doch sehr Ihr geht auf diese einmalige Chance ein und zeigt somit Engagement gegenüber der Community. Im Gamedevelopment macht man keine halben Sachen, entweder man zieht es durch oder man lässt es. Die History Edition ist eine sehr schöne Hommage an die Fans. Ich hoffe es gibt noch viele weitere Updates, Bugfixes und neue Features. Ich bin davon überzeugt, dass eine enge Zusammenarbeit mit der Community sich auch vorteilhaft auf die Verkaufszahlen auswirkt !

lolerboon2010
09-02-19, 09:03
Ich kann nicht verstehen warum CookieButton nicht helfen darf er möchte ohne gegenleistung eure Probleme lösen
Warum lässt man ihn dann nicht
Mann hätte es ihn wenigstens probieren lassen können zb das desync problem zu behen
weil Wem hätte das geschadet

also wenn mir jemand anbieten würde mir gratis bei der arbeit zu helfen würde ich auch nicht nein sagen....


ich glaube auch das er um ein vielfaches mehr interessiert ist siedler 4 zu fixxen als eurer komplettes team.....


und als dank für sein angebot gibts noch nicht mal eine antwort:)

was ist billiger ein unbezahlter praktikant der mehr leisten kann und will
oder jemand aus eurem team dem das ganze nach feierabend eh am ar.... vorbei geht???

veränderter code kann man sich vorher ja angucken testen und dann wird man ja sehen ob der praktikant sein werk versteht......

Vieleicht habt ihr ja auch angst um den sourcecode-.- Da solltet ihr euch eben vorher schriftlich absichern......

Die Community möchte Siedler 4 spielen können ohne nervige fehler die es schon damals gab und wenn das zuviel vom team verlangt ist weil ihr ja auch alle anderen Teile Fixxxen müsst ... dann fragt mal CookieButton der mit dem herzen dabei wäre/ist