Wenn bei einem anderen Spieler die Fahne erst später erscheint, passiert doch nix
schlimmes, in wie fern soll denn da etwas asyncron werden?
Wenn eine Baracke besetzt wird, das ist etwas anderes, es vergrößert das Land und kann
sich so auch auf andere Spieler auswirken, aber ob nun die Flagge 2 Sekunden später
erscheint sollte keinen Unterschied machen. Vorrausgesetzt ist nur, dass TCP benutzt wird,
damit auch alle Befehle eines Spielers in der richtigen Reihenfolge ankommen, außerdem
dürfen die Clients das Spiel eines anderen Spielers in keinster Weise selber berechnen.
z.B. Situation: Ein Stück Holz liegt an einer Fahne, ein Gehilfe soll es weiter transportieren.
Die anderen Clients dürfen jetzt nicht eigenständig in ihrem Spiel den Gehilfen losschicken
um das Holz abzuholen, sondern auf Befehle des Clients, der diesen Spieler kontrolliert,
warten. Das ganze müsste so ablaufen:
Der Client sendet:
"Gehilfe X läuft jetzt zur Fahne Y"
-> Alle anderen Clients stellen dies dar
Wenn der Gehilfe an der Fahne ankommt, sendet der Client:
"Gehilfe X nimmt Holz und läuft zur Fahne Z"
-> Andere Clients zeigen das wieder entsprechend
und schlussendlich sendet der Client:
"Gehilfe liegt Holz an der Fahne Z ab."
Unter der vorraussetzung eines konstanten Pings läuft diese Vorgang auf allen Clients
flüssig ab. Würde der Ping zwischen dem 1. und den 2. Befehl stark ansteigen, würde
es bei anderen Spielern so aussehen, dass der Gehilfe zur Fahne geht, dort erstmal stehen
bleibt und dann erst das Holz nimmt und los geht.
Diese "zerstückelung" von Vorgängen muss so weit gehen, dass nurnoch atomare Vorgänge
existieren, die nicht zu desync führen können.
Würde z.B. der erste Befehl lauten: "Gehe zur Fahne und hole das Holz ab", könnte
folgendes bei starken Lags passieren:
Der Geholfe rennt los zur Fahne, kurz bevor er da ist reißt der Spieler den Weg ab,
was zur Folge hat, dass das Holz liegen bleibt. Die anderen Clients bekommen den Abriss-
befehl erst ein bisschen später, nachdem der Gehilfe das Holz schon aufgenommen hat.
Zumindest im originalen Siedler 2 führte das dazu, dass das Holz verschwand, und der
Gehilfe ins nächste Lager rannte. Das ganze führt jedenfalls dazu, dass der Client des
Spielers dort noch Holz liegen hat, und die anderen nicht.
Im oben genannten Ablauf wartet der Gehilfe extra auf den "nimm Holz auf" Befehl des
Clients dieses Spielers, sodass dieser Fall nicht eintreten kann.
Gleiches Beispiel könnte man bringen, wenn der Spieler einen Weg mit einer weiteren
Fahne unterteilt, und beim Client des Spielers der die Fahne sitzt ist der Gehilfe
schon hinter der neuen Fahne, und bei den anderen Clients noch davor. Überließe man
die Entscheidung, auf welches Wegstück sich der Gehilfe nun platziert, jedem Client
für sich, würde das Spiel wieder asyncron werden, sagt der Client aber explizit, dass
dieser Gehilfe sich jetzt auf das Straßenstück X stellt, ist alles paletti. Es hätte halt
nur zur Folge, dass der Gehilfe bei den anderen Spielern, wo er schon an der Fahne vorbei
gerannt ist, plötzlich wieder umdreht und zurück rennt.
Die Zerlegung aller Vorgänge des Spiels in atomare abläufe ist zwar recht kompliziert im
Vergleich zur Verwenung der "handelsüblichen" Frames Technik, hat aber eben den großen
Vorteil, dass Aktionen eines Spielers im eigenen Land nicht laggen, egal wie
hoch der Ping ist. Ausnahme sind wie eben schon angesprochen Ereignisse, die das globale
Spielgeschehen beeinflussen. Diese muss man alle korrekt isolieren und berücksichtigen.
Dazu gehört z.B. auch Steine abbauen, Holz fällen, Bäume pflanzen etc, wobei dies ja auch
nichts ist, was der Spieler direkt macht, also sollte man Lags hier nicht spüren.
Es gilt nur abzuwägen, ob der Mehraufwand sinnvoll ist.
Ich habe mal eine recht lange englische Dokumentation über diese Technik gelesen, aber
finde sie ums Verrecken nicht wieder. :(
Bin leider auch nicht so der Überflieger in gut und präzise Erklähren, darum dieser
doch etwas ausgedehntere Text, sry ;)
creation needed 0.04921s and 261 mysql-queries.
Zur Navigation
