Spielerpositionen

rapso

ich glaube ihm geht es um den netzwerk, nicht um input

aber auch in der hinsicht gibt es verschiedene implementierungen. jedoch wird wohl jedes spiel zumindestens ab und zu die absoluten daten uebergeben, weil sowas immer ein wenig divergieren kann.

Uchuujinsan

Naja, das Problem am übergeben von absoluten Daten, is das vom Konstruktionsprinzip her damit der Client ja als der vertrauenswürdigere angesehen wird, d.h. "im Zweifelsfalle hat der Client recht". Glaub kaum dass das mit MMoRPG wirklich vereinbar is.

Denke es gibt 2 wichtige Prinzipien.
1. Der Server hat im Zweifelsfalle immer recht
2. Es findet immer eine clientseitige Prüfung statt, und wie die erfolgreich war eine serverseitige Prüfung.
Kann mir zumindest nicht vorstellen wir man das sonst vernünftig handhaben soll.

rapso

Uchuujinsan schrieb:

Naja, das Problem am übergeben von absoluten Daten, is das vom Konstruktionsprinzip her damit der Client ja als der vertrauenswürdigere angesehen wird, d.h. "im Zweifelsfalle hat der Client recht". Glaub kaum dass das mit MMoRPG wirklich vereinbar is.

der zusammenhang entgeht mir irgendwie. der server beaufsichtig doch die regeln, wieso sollte da ein client echt haben?

HMarkus

Hallo!

Ich habe mich nur mal kurz in das Thema eingelesen, aber noch nichts dergleichen umgesetzt. Aber das Hauptproblem, das zu lösen gilt, ist ja folgendes: Jeder Spieler muss den gleichen Spielstand (also etwa die Speilerpositionen, ...) sehen.

Ein Ansatz wäre der folgende: Jeder Client teilt dem Server mit, was er eigentlich will, also etwa um 10 Positionen nach links laufen. Der Server und der Client berechnet dann den Positionsverlauf über die Zeit, wobei der Server das Ergebnis an den Client zu festen Zeitabschnitten zusendet und der Client dann dieses ggf. als das "richtige Ergebnis" ansieht.

Richtig interessant wird es natürlich bei Ballerspielen, wo es auf 10ms ankommt. Ob da eine bessere Methode verwendet wird, kann ich leider auch nicht sagen.

zwutz

Zum Teil (auch in Shootern) läuft es so ab, dass die Berechnung zum großteil vom Server ausgeht... der Client sagt ihm, was er machen will und der Server setzt das ganze um und teilt das Ergebnis dem Client mit. Erst dann bewegt man sich weiter (oder was auch immer man grad machen wollte). Der Server macht das eine bestimmte Anzahl pro Sekunde (oft zwischen 30-60 mal, aber Gameabhängig. Shooter öfter, MMORPGS seltener).

Das ganze ist natürlich noch extrem verfeinert... so exisitieren Algorithmen, die die Paketlaufzeiten kompensieren und gewisse Toleranzgrenzen, was verlorene Pakete angeht, da im Gegenzug zum normalen Netzwerk ein Paket nicht einfach mehrmals geschickt werden kann, wenn es mal nicht ankommt

Man könnte die Berechnung auch dem Client überlassen, allerdings würde dann ein schneller Rechner öfter dazu kommen, seine Position zu aktualisieren als ein langsamer...

Andreas XXL

rapso schrieb:

Uchuujinsan schrieb:

Naja, das Problem am übergeben von absoluten Daten, is das vom Konstruktionsprinzip her damit der Client ja als der vertrauenswürdigere angesehen wird, d.h. "im Zweifelsfalle hat der Client recht". Glaub kaum dass das mit MMoRPG wirklich vereinbar is.

der zusammenhang entgeht mir irgendwie. der server beaufsichtig doch die regeln, wieso sollte da ein client echt haben?

Ich glaube es war gemeint, das es gefährlich ist, wenn der Spieler absolutwerte übermittelt. Also anstatt zu sagen ich will da hin (Z.B Vectorangabe) einfach zu sagen ich BIN an Position (Vectorangabe). Dann könnte man cheaten, indem man einfach Positionen angibt, die z.B direkt neben einem Gegner sind und sich sozusagen da "hinteleportieren".

Denn es ist schwieriger für den Server zu überprüfen, ob eine Absolutangabe richtig ist, also ob der Spieler diese Position seit der letzten Absolutangabe erreicht haben kann oder nicht, als einfach nur zu prüfen, ob die Angabe der gewünschten Bewegungsrichtung erlaubt ist oder nicht.

Fazit: Absolutangaben darf nur der Server an den Client schicken, damit dieser prüfen kann, ob es Abweichungen gibt oder ob Server und client noch synchron laufen. Der Client sendet nur "Bewegungswünsche" also die Richtung in die man gehen will (oder das Ziel wo man hinwill). Dann kann der Server testen ob dies möglich ist oder nicht.
Diese vorgehensweise macht es cheatern schwerer zu cheaten.

rapso

Andreas XXL schrieb:

rapso schrieb:

Uchuujinsan schrieb:

Naja, das Problem am übergeben von absoluten Daten, is das vom Konstruktionsprinzip her damit der Client ja als der vertrauenswürdigere angesehen wird, d.h. "im Zweifelsfalle hat der Client recht". Glaub kaum dass das mit MMoRPG wirklich vereinbar is.

der zusammenhang entgeht mir irgendwie. der server beaufsichtig doch die regeln, wieso sollte da ein client echt haben?

Ich glaube es war gemeint, das es gefährlich ist, wenn der Spieler absolutwerte übermittelt. Also anstatt zu sagen ich will da hin (Z.B Vectorangabe) einfach zu sagen ich BIN an Position (Vectorangabe). Dann könnte man cheaten, indem man einfach Positionen angibt, die z.B direkt neben einem Gegner sind und sich sozusagen da "hinteleportieren".

der server rechnet eh einen bewegungsradius aus zu dem ein spieler sich 'positionieren' darf, weil der server auch pruefen muss, ob ein spieler z.b. durch eine wand laufen wuerde, selbst wenn er nur 1cm laeuft. wenn man spiele mal mit sehr schlechtem ping und packetloss spielt, dann sieht man auch, wenn man sich zu schnell fortbewegt, dass man vom server auf die alte position 'reseted' wird.

Denn es ist schwieriger für den Server zu überprüfen, ob eine Absolutangabe richtig ist, also ob der Spieler diese Position seit der letzten Absolutangabe erreicht haben kann oder nicht, als einfach nur zu prüfen, ob die Angabe der gewünschten Bewegungsrichtung erlaubt ist oder nicht.

idas duerfte eigentlich nicht schwer sein, es kostet den server nur wenig rechenoperationen und er kann aus alter und neuer position den bewegunsvector selbst errechnen. (natuerlich unter der voraussetzung, dass sowohl relative als auch absolute bewegungen im gleichen takt an den server uebersand werden wuerden). oder versteh ich euch beide falsch?

Fazit: Absolutangaben darf nur der Server an den Client schicken, damit dieser prüfen kann, ob es Abweichungen gibt oder ob Server und client noch synchron laufen. Der Client sendet nur "Bewegungswünsche" also die Richtung in die man gehen will (oder das Ziel wo man hinwill). Dann kann der Server testen ob dies möglich ist oder nicht.
Diese vorgehensweise macht es cheatern schwerer zu cheaten.

ich denke es laeuft eher so, dass der server sich ausrechnet wo ein spieler im naechsten datenpaket sein kann, bekommt das packet (ob relativ oder absolut ist dabei erstmal egal) und prueft dann ob es die position im rahmen des moeglichen ist.

der unterschied den ich zwischen relativen und absoluten bewegungn sehe ist, dass man relative sehr einfach komprimieren kann. man weiss wieviel der spieler laufen kann. normalisiert den bewegungsvector darauf und schickt das dann als 3 int8_t statt 3 floats. leider entstehen dadurch prozessorbedingte unterschiede an positionen, die sind sehr sehr klein, aber wenn der spieler vom einen ende des levels zum anderen laeuft, selbst bei 0.01grad, kann es sich dadurch auf einen merklichen unterschied akkumulieren.
deswegen wird wohl kaum ein spiel das das mit float rechnet drumrum kommen ab und zu mit absoluten positionen zu synchronisieren. aus diesem grund haben manche spiele dafuer auch immer noch eine fixpoint representation der daten.
ein weiteres problem koennte packetlos sein. gerade shooter arbeiten mit udp und pfeifen drauf wenn ein packet verloren geht. mit relativen daten kann das schon sehr bloed sein. bei einem rpg (die ja noch mit nem ping von 300ms ertraeglich sind), hat man das problem vielleicht nicht, falls tcp.
ganz alte spiele haben garkeine positionen uebertragen, sondern den spielerinput. dann wurden auf allen rechnern, alle spieler durchsimuliert, nur so lief das mit nem 3k modem noch.

Uchuujinsan

der server rechnet eh einen bewegungsradius aus zu dem ein spieler sich 'positionieren' darf

Also ganz ehrlich, ich glaub es is für den server etwas einfacher zu rechnen ob eine bestimmte Bewegung erlaubt ist, als zu berechnen welch Bewegungen alles denn erlaubt sind (was z.b. bei schrägen gelände mit gegenständen richtig kompliziert werden kann)
Also das mit dem Bewegungsradius.. neeee, das glaub ich erst wenn ichs im quellcode seh :>
Andreas hat mich glaub schon richtig verstanden.

Außerdem, wenn eine neue Position als ungültig angesehen wird, würde es so ja keine teilbewegung bis zur gültigen position mehr geben, der befehl als solches müsste abgelehnt werden (der server weiß ja nicht auf welcher route der spieler versuchte auf diese position zu kommen, oder aber man müsste das komplette pathfinding dann auch noch immer berechnen lassen)

natuerlich unter der voraussetzung, dass sowohl relative als auch absolute bewegungen im gleichen takt an den server uebersand werden wuerden

Auch etwas, was im normalfall eben nicht gegeben sein dürfte.

deswegen wird wohl kaum ein spiel das das mit float rechnet drumrum kommen ab und zu mit absoluten positionen zu synchronisieren. aus diesem grund haben manche spiele dafuer auch immer noch eine fixpoint representation der daten.

Das denke ich hingegen auch, allerdings nur zur verwendung das der Client (wie du oben gesagt hast) mit dem server synchronisiert wird, d.h. der server sagt dem client wo er denn eigentlich wirklich steht (position wird resettet)

rapso

Uchuujinsan schrieb:

der server rechnet eh einen bewegungsradius aus zu dem ein spieler sich 'positionieren' darf

Also ganz ehrlich, ich glaub es is für den server etwas einfacher zu rechnen ob eine bestimmte Bewegung erlaubt ist, als zu berechnen welch Bewegungen alles denn erlaubt sind (was z.b. bei schrägen gelände mit gegenständen richtig kompliziert werden kann)

damit meinte ich eben sowas wie den bewegungsradius (oder eben zonen die zugaenglich sind), versucht sich jemand an soeine stelle zu positionieren kann der server das gleich als fehler behandeln, also ne ganz schnelle sache, unabhaengig davon ob mittels relativer oder absoluter position gearbeitet wird.

dann erst wird z.b. die collisionspruefung angestrengt um zu testen ob zwischen alter und neuer position ueberhaupt ein weg ist.

Also das mit dem Bewegungsradius.. neeee, das glaub ich erst wenn ichs im quellcode seh :>

ich glaube ich wuerde dich mit meinem quellcode nur wenig ueberzeugen ;). aber es gibt genug freien MP quellcode, kannst ja in ein paar reinschauen und uns sagen, ob es so wie ich es mache sonst nirgens gemacht wird weil es bloedsinnig ist

Außerdem, wenn eine neue Position als ungültig angesehen wird, würde es so ja keine teilbewegung bis zur gültigen position mehr geben, der befehl als solches müsste abgelehnt werden (der server weiß ja nicht auf welcher route der spieler versuchte auf diese position zu kommen, oder aber man müsste das komplette pathfinding dann auch noch immer berechnen lassen)

es gibt kein pathfinding, es wird eine direkte verbindung angenommen, deswegen ist man auf nen guten ping angewiesen bzw gute bandbreite. bei nem ping von 100ms wirst du es kaum schaffen einen weg zu bestreiten der ein pathfinding noetig macht.

natuerlich unter der voraussetzung, dass sowohl relative als auch absolute bewegungen im gleichen takt an den server uebersand werden wuerden

Auch etwas, was im normalfall eben nicht gegeben sein dürfte.

wieso sollte eine implementierung mit relativen angaben in einer anderen frequenz die packete verschicken als eine mit absoluten positionen?

deswegen wird wohl kaum ein spiel das das mit float rechnet drumrum kommen ab und zu mit absoluten positionen zu synchronisieren. aus diesem grund haben manche spiele dafuer auch immer noch eine fixpoint representation der daten.

Das denke ich hingegen auch, allerdings nur zur verwendung das der Client (wie du oben gesagt hast) mit dem server synchronisiert wird, d.h. der server sagt dem client wo er denn eigentlich wirklich steht (position wird resettet)

das resetten passiert aber nur in spielen wenn vom server ein fehler angenommen wird (z.b. weil packetloss auftratt). ansonsten uebernimmt der server die position die der client ihm sagt, sofern sie innerhalb der moeglichkeit liegt die der server annimmt.
Der server kann den client in normalen situationen hingegen nicht steuern, bei einem ping von z.b. 50ms wuerdest du eben min 50ms warten bis nach deiner eingabe endlich auch dein programm reagiert. das ist manchmal selbst bei den extrapolierten gegnern seltsam anzusehen.

btw. schaut bei mir in etwa so aus:

struct ...
{
  int16_t PosX,PosY,PosZ;//absolute position
  int16_t Alpha,Beta,Speed;//momentane bewegung fuer extrapolation
  int16_t ID, TimeStamp;//
};

aber wie gesagt, das ist keine referenz, aber solange niemand was besseres postet kann sich der fragesteller ja mal dran orientieren.

Airdamn

Danke für die ganzen Antworten.
Es ist, wie man schon sieht, ein relativ kompliziertes Thema.