JLI Spieleprogrammierung

[RayJunx]

Hi All!

Bin gerade mit ein paar Freunden am experimentieren was Multiplayer angeht, aber noch keiner hat wirklich Erfahrung was das angeht.

Einfaches Beispiel... nehmen wir an wir wollen ein ganz einfaches Spiel spielen. Jeder Spieler läuft mit seiner figur auf einer 2D gekachelten landschaft umeinander. Das soll gleichzeitig über LAN oder das internet geschehen. So wie binden wir das ein... erstmal geht es um den Grundaufbau, welche Struktur... gibt es einen Server der das ganze Spiel verwaltet und alle berechnungen durchführt, oder macht das jeder client selbst und der Server Synchronisiert nur?

nächstes Problem, die bewegung der Spieler soll ja sehr flüssig ablaufen, sagen wir 60Frames die sekunde oder schneller je nach bildrate, entsprechend auch die Berechnungen und Eingabeverwertung des Spielers. Die Syncro über den server dürfte aber keine ahnung langsamer sein, bei pings zwischen 10 und 100millisecs also ca 100bis10 frames die sekunde. wenns schlecht geht und jemand aus japan mitspielt, haben wir also 10 syncs die sekunde. Was dann? wir können dann nicht jedes Spielframe die daten abgleichen. Dann müßte das spiel praktisch ein stück weit "blind bzw autark" laufen... Wie handelt man sowas?

Wenn zum Beispiel keine Spieler gleichzeitig auf ein Kachelfeld laufen dürfen, kann ich das ja prüfen wenn ich jede runde weiß was der andere getan hat, wenn ich das aber nur alle 10 runden geupdatet bekomme... was mach ich da? davon ausgehen das er jetzt an mehreren punkten sein kann? no matter. Hat jemand von Euch Erfahrung bei sowas? Würde mich über Euer Feedback sehr freuen.

Grüße an alle,
Euer RayJunx
_________________
Just a Freak

[Dragon]

Multiplayerspiele sind eine etwas kompliziertere Sache als normale Spiele. Wir haben bei Tournament ein System, dass Serverobjekte automatisch bei den Clients anmeldet, bewegt und löscht. Alles besiert auf Events. Ist für dich vieleicht etwas schwierig umzusetzen, darum will ich dir ein einfaches Bespiel bringen.

Erstmal etwas Theorie

Es gibt verschiedene Architekturen: Client-Server und Peer2Peer. Bei Client-Server gibt es einen Obermacker der für das Spiel zuständig ist. Alle Nachrichten von den Clients gehen erst an den Server und werden dann evtl. weitergeleitet oder verarbeitet. Bei Peer2Peer sind alle Mitspieler gleichberechtigt, d.h. du musst die Nachricht von einem Client an alle Clients verschicken. Vorteil bei dieser Methode ist, dass wenn der Spielstarter das Spiel verläst das Spiel trotzdem weiterläuft. Bei Client-Server wird das Spiel beim runterfahren des Server beendet.

Folgendes Szenario: Es sollen sich 2 Akteure auf einer Fläche bewegen.

Erstmal müssen die Clients in Kontakt treten. Entweder mit Peer2Peer oder über einen Server. Ein Client aber auch zugleich Server sein. Klingt etwas verwirrend ^^. Okey, zurück zum Thema. Wenn sich also ein Client anmeldet muss ein Akteur für ihn erzeugt werden. Der Benutzer macht seine Eingaben und bewegt die Figur damit. Je nach dem, welche Architektur kannst du die eingaben verschieden übertragen. Bei einer Client-Server architektur kann man das wie folgt machen. Man schickt ein Packet mit dem Inhalt "Bewege mal meinen Akteur nach links" an den Server. Der Server bewegt nun den Akteur des Clients auf dem Server und sendet die neue Position sowie Bewegungsdaten für evtl. Interpolation an alle Clients, auch an den Packetsender. Bei einer Peer2Peer-Architektur kann man die Postions- und bewegungsdaten, ich wiederhole mich, für evtl Interpolation. Meldet sich ein Client vom Spiel ab oder Timeout, dann wird der Akteur aus dem Spiel gelöscht.

Zum Thema Ping: Der Ping kann einem ganz schön zum Verhängnis werden. Bei einen hohen Ping kommt es zu extremen verzögerungen. Das lässt sich aber mit etwas Makeup verschönern. Z.B. kannst du die bewegung erst etwas schneller machen, bis es wieder mit der Server-Version synchron ist und dann normal bewegen. Dafür brauch man dann die Bewegungsdaten. Kann in form eines Vectors sein aber auch in Form von einem Feld für Links, Rechts, blablablub.

Okey, ich hoffe, das kann die eine kleine Hilfe sein. Für weitere Informationen steh ich dir zu verfügung. Eine gute seite ist www.gamedev.net da einfach mal bei Network reinschauen, da gibt es massig tutorials.

Achso, ein paar Netzwerkprogrammiertipps: Immer nur dann Daten senden, wenn sich auch wirklich was ändert, aber nicht jeden Frame. Die Daten immer klein halten und Absolute daten für absolute Positionierung verwenden.
_________________
Nur wenn man ein Ziel sieht, kann man es auch treffen.
___________
Mein Leben, Freunde und die Spieleentwicklung

[FH]

Nochwas zu der Frage, was man macht, wenn man keine neuen Daten hat: Ich würde, wie Dragon sagte, einfach nen Bewegungsvektor mitschicken, so dass die anderen praktisch zumindest ungefähr mitrechnen können, wo sich der andere befindet. Wenn sie dabei etwas entschieden ändert, hat der langsame Client halt mehr oder minder gelitten. Angenommen, er rennt zu einem Teleporter, auf dem er sich wegbeamt. Kurz bevor er auf dem Ding draufsteht, kommen einige Zeit lang keine Daten mehr von ihm zum Server. Wenn er in dieser Zeit abgeschossen wird, hat er halt gelitten...
Gruß

FH
_________________
goto work, send your kids to school
follow fashion, act normal
walk on the pavement, watch T.V.
save for your old age, obey the law
Repeat after me: I am free

[Hazel]

Was meine beiden Vorgänger gesagt haben ist richtig.

Außerdem ist es wichtig, dass du deine Net Events in RELIABLE(MUSS ankommen) und UNRELIABLE(nicht so dringend, wird aber häufiger gesendet) aufteilst.

Beispiele für reliable: Spieler stirbt, Neuer Map wird geladen, ein Entity wird gespawnt

Beispiele für unreliable: Spielerbewegung aller Art.


Außerdem würde ich dir empfehlen mit jedem Päckchen einen Zeitstempel mitzuschicken. Wenn ein Spieler zum Zeitpunkt 10 losrennt und das Paket bei den anderen erst 20 ticks später ankommt, dann musst du die Bewegung extrapolieren damit das Spiel einigermaßen synchron läuft. Wo wir gerade beim Thema sind: Die Clients sollten folgende wichtige Techniken beherrschen: Interpolation(Bewegung und Rotation), Extrapolation(hier das gleiche) und Prediction(Annahmen machen auf Grund älterer Daten um Lag zu kompensieren).

Es gibt im Netz zu den Themen einen Haufen interessanter Artikel und wirklich schwer ist das nicht umzusetzen.
_________________
*click* Dabuu!?
Twitter: http://twitter.com/Ollie_R

[Chriss]

[GreveN]

Naja, eine 4 Byte 'unsigned long' kennt 2^32 Werte. Das heißt, das Spiel müsste 4294967296 Millisekunden laufen, bevor der Zeitstempel auf 0 springen würde, das wären ~4294967 Sekunden oder anders ausgedrückt ~71583 Minuten, was ~1193 Stunden entspricht, was immerhin knapp 50 Tage sind.

Wenn man einen kleineren Typ für den Stempel nutzt, überall synchron bei 0 beginnt, könnte man ja irgendwie global refreshen wenn die Zeit um ist und alle eventuell noch umher streunenden, älteren Päckchen ungültig machen oder so.

[Chriss]

Ok einen kleinen Aussetzer nach 50 Tagen kann man wohl verkraften

Das globale Synchronisieren würde ja noch gehen wenn man den Stempel des Servers anforder und die halbe Pingzeit adiert. Nur wie bekommt man die Pingzeit raus? Gibt es bei den Sockets was fertiges? UDP und TCP fallen ja eigentlich flach da Ping ein niedrigeres Protokoll verwendet.

[abc_d]

ICMP ist in der gleichen Schicht wie TCP oder UDP. Ich denke nicht das das klappt was du vorhast, die Latenzzeit (ping) kann man nicht vorausberechnen, sie ist bei jedem Paket unterschiedlich.
_________________
http://mitglied.lycos.de/sarti/linuxisevil.gif Linux is evil - get the fact.

Never touch a running System - der Systemling

[Dragon]

[abc_d]

Ok, da gebe ich dir recht.

Jetzt wo ich darüber nachdenke, denke ich das man die Latenzzeit dadurch herausfindet, das man ein Paket verschickt, und wartet bis die Antwort kommt, die Zeitdifferenz ergibt die Latenzzeit. Das ist viel besser, das auch die Verarbeitung der Pakete berücksichtigt wird.
_________________
http://mitglied.lycos.de/sarti/linuxisevil.gif Linux is evil - get the fact.

Never touch a running System - der Systemling

[Jonathan_Klein]

Ich hab mir auch schnomal Gedanken darüber gemacht.
Im Pirnzip ist es ein sehr schweres Thema, und nie perfekt zu lösen.
Zum Beispiel sollte es ja zu Anno 1503 einen MP Patch geben, der leider nix gegeben hat, und die haben estimmt keine Anfänger- oder Hobbyprogrammierer...
Naja, bei Netzwerk hat man wohl weniger Probleme, mehr Kapazität, kürzere Zeiten usw.
nachdem ich n bisschen rumexperimentiert hab, wollte ich ersteinmal SP Siele machen. Neztwerk ist wirklcih eines der schwersten Themen die es gibt...
_________________
https://jonathank.de/games/

[Fallen]

@Anno: Gross MP Modus Ankündigen aber Spielgerüst nicht darauf auslegen, haha, das schaffen aber wirklich diverse Hobbyprogrammierer besser.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[abc_d]

Da kann ich mir dir nur anschließen
_________________
http://mitglied.lycos.de/sarti/linuxisevil.gif Linux is evil - get the fact.

Never touch a running System - der Systemling

[OLiver]

[Jonathan_Klein]

ja stimmt, höchstwahrshceinlich lag es an der gesamt Konzeption des Spiels, das der Multiplayer teil so schwierig einzubauen wurde.

Diese Eventsystem ist natürlich eine gute Möglichkeit, wahrshceinlich sogar die beste. Aber therretisch ist es immernoch minimal asynchron, da die Befehle ja zum Beispiel zu einem ein wenig länger brauchen könnten, oder jemand der nur die halbe Framerate hat, doppelt so lange warten muss, bis die neuen Situation dargestellt wird. Die Unterschiede sind natürlich minimal und gerade wenn alles zentral berechnet wird, kann das eigentlich kaum auffallen. Aber perfekt synchron ist es nicht
_________________
https://jonathank.de/games/