spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Du kannst dir mal diese Tutorial Reihe anschauen:
http://playerio.com/documentation/tutori…torial/realtime
http://playerio.com/documentation/tutori…synchronization
http://playerio.com/documentation/tutori…l/interpolation
http://playerio.com/documentation/tutori…utorial/latency
http://playerio.com/documentation/tutori…rial/tipstricks
erklärt die allg. Konzepte (nur der Quellcode und einige Hinweise sind für AS3, was aber eigentlich überhaupt nichts macht)...

Ich würde wie in den Tutorials vorgeschlagen eine Mischung aus state und event synchronisierung wählen. Interpolieren wirst du wohl in allen Fällen müssen, zumindest wenn das ganze realtime action werden soll und die Spielgeschwindigkeit nicht von Latenz und Framerate der Clients abhängig sein soll (in diesem Fall könntest du das Spiel sonst als rundenbasiert sehen).

Die Frage mit den Vektoren oder absoluten Koordinaten verstehe ich nicht so richtig.

Bewegung über Vektoren ist ein inkrementelles Modell. Inkrementelle Modelle sind immer numerisch instabil, führen also irgendwann meist zu total abstrusen Positionen bei den Clients und sollten daher vermieden werden. Ziel-Koordinaten einer Bewegung sollten daher absolut sein und man sollte ebenfalls über Start-Koordinaten nachdenken um eine weitere Synchronisierung erzielen zu können.

Zitat

Du kannst dir mal diese Tutorial Reihe anschauen:
http://playerio.com/documentation/tutori…torial/realtime
http://playerio.com/documentation/tutori…synchronization
http://playerio.com/documentation/tutori…l/interpolation
http://playerio.com/documentation/tutori…utorial/latency
http://playerio.com/documentation/tutori…rial/tipstricks
erklärt die allg. Konzepte (nur der Quellcode und einige Hinweise sind für AS3, was aber eigentlich überhaupt nichts macht)...

Oh ja, sehr gutes Tutorial. Kommt direkt mal in meine Favourites.
Dem ist eigentlich nichts mehr hinzuzufügen.
In der englischen Fachsprache heißt es teilweise auch "Dead Reckoning " statt Interpolation.

Zitat

A disadvantage of dead reckoning is that since new positions are calculated solely from previous positions, the errors of the process are cumulative, so the error in the position fix grows with time.

Inkrementelle Modelle sind ungünstig, sagte ich ja schon
Koppelnavigation ist auch kein alternatives Wort für "Interpolation" - deine Antwort klingt nämlich so, als ob du das so aufgefasst hast.

Zitat

Inkrementelle Modelle sind ungünstig, sagte ich ja schon
Koppelnavigation ist auch kein alternatives Wort für "Interpolation" - deine Antwort klingt nämlich so, als ob du das so aufgefasst hast.

Die inkrementellen Fehler treten aber nur bei falschen Realisierungen auf und auch nur in folgenden Fällen:
1. Server und Client verwenden ein unterschiedliches Zeitmaß.
2. Der Server führt die Koppelnavigation nicht lokal aus, um die aktuelle Position mit der Koppelposition zu vergleichen. Sprich (Pseudocode)



Um genau zu sein ist Koppelnavigation schon eher Extrapolation, während Interpolation immer zeitlich hinterher hinkt.

Nein, die inkrementellen Fehler treten immer dann auf, wenn die Server- und Client-Hardware nicht identisch sind und verschieden runden, bzw. mit unterschiedlicher Genauigkeit rechnen.

Ich sehe auch keinen Grund, warum man relative Angaben an den Client schicken sollte anstatt absolute. Welchen Sinn soll das haben außer die Synchronisation leiden zu lassen? Wo soll der Vorteil von "SendKoppelPosition" gegenüber "SendPosition" liegen? Da sehe ich weder weniger Traffic, noch weniger Logik dahinter.

Zitat

Ich sehe auch keinen Grund, warum man relative Angaben an den Client schicken sollte anstatt absolute. Welchen Sinn soll das haben außer die Synchronisation leiden zu lassen? Wo soll der Vorteil von "SendKoppelPosition" gegenüber "SendPosition" liegen? Da sehe ich weder weniger Traffic, noch weniger Logik dahinter.

Es war nur Pseudocode ...
Im Endeffekt läßt sich durch entsprechend übertragene Geschwindigkeitsvektoren (Δs) der Traffic auf weniger als 10% drücken,
gegenüber stumpfen Versenden der Position in jedem Tick, bei gleichbleibender Genauigkeit.
Der Logik-Aufwand steigt da natürlich an. Die Daten müssen natürlich auch beim Sender zur Verfügung stehen.
Die Extrapolationsgenauigkeit läßt sich weiter erhöhen, wenn man auch Kenntnis über die Beschleunigung (Δv) hat.
Solange die Genauigkeit beim Client ausreicht, wird überhaupt kein Update versandt.

Auf 10%? Wie soll das gehen? Ein Vektor hat so weit ich das sehe vermutlich die typischen 3 Komponenten, jede vermutlich 4 Byte groß. Das haben absolute Angaben vermutlich ebenfalls. Wo sind das 10%?
Zudem ist es absolut nicht notwendig in jedem Tick gewisse Angaben zu senden, sondern lediglich bei jedem Start oder Ende einer Bewegung mit deren jeweiligen Richtung (eventuell sogar noch die Zeitpunkte und den korrekten, serverseitigen Startpunkt). Ob ich da absolute Angaben mache oder relative zum letzten Update, das spielt überhaupt keine Rolle, nur sind letztere auf Dauer ungenau und führen zu nicht vorhersagbaren Offset-Fehlern). Auch braucht der Client (fast) keine Positions-Angaben an den Server schicken, da der Client ohnehin nur das anzeigt, was der Server befiehlt und aus den Start- und End-Punkten einer Bewegung die Positionen dazwischen selber extrapolieren/interpolieren kann.
Das hat bei unserem MMORPG-Server mit mehr als 1000 Spielern in einem Siege super funktioniert und ich sehe da auch keinen Weg, wie man das auf 10% hätte reduzieren wollen.

@BlueCobold: Falk hat genau das gesagt was du da geschrieben hast Und der Server muss auch die Client-Position gesendet bekommen --> Cheaten, weil wenn sich der Char auf einmal 5000m weiter vorne befindet, kann da was nicht stimmen