Netzwerkarchitektur für Spiele

[donelik]

Guten Tag!

Ich suche Informationen zur Architektur eines Netzwerkspiels (keine API sondern nur den Ablauf). Mich interessiert was die Best-Practices sind damit alle Clients stets das selbe sehen.

Ich bin mir bewusst dass alle Clients nie genau das selbe sehen können, aber genau da liegt der Knackpunkt. Wie kann ich dafür sorgen das diese Verzögerungen nicht für Ungereimtheiten im Spielablauf sorgen.

Mal ein konkretes Beispiel mit Ideen: Multiplayer-Moorhuhn.

Spieler 1 (S1) ist der Host und Spieler 2 (S2) verbindet sich als Client zum Host. Zusammen wollen die Dauerzocker so viele Hühner wie möglich kaltblütig töten.

Ich dachte daran dass S1 beim Starten der Multiplayer-Sitzung automatisch eine Server-Instanz startet und er sich mit privilegierten Rechten selbst als Client zu seiner Server-Instanz verbindet (m. E. wurde das bei Quake 3 Arena so gemacht).

Damit würde ich jeden Spieler gleich behandeln und habe "weniger" Arbeit.

Nun stellt sich mir aber die Frage wann ich welche Daten übertragen muss auch mit den Gedanken dass die Latenz ziemlich gering bleiben sollte. Auch die Synchronität ist selbstverständlich enorm wichtig.

Idee 1: Wie wäre es also wenn ich JEDE Spielaktion (Schießen, Fadenkreuz bewegen, Nachladen, ...) zum Server übermittle und nur der dann die ganze Logik ausführt und das Ergebnis zurück schickt. Vorteile sehe ich hier in der Kontrolle welche Betrügereien fast ausschließt. Nachteil ist die Netzlast und dass Clients immer etwas (vermutlich sogar spürbar) Verzögerung haben.

Idee 2: Solange das Ergebnis nicht da ist, kann der Client ja auch mit seinen Ergebnissen weiter rechnen. Nur wäre es schlimm wenn ein Huhn beim Client S1 gerade durch enorme Feuerkraft stirbt aber der Server schon weiß das S2 schneller war. Dann bekommt S1 von seiner Client-Logik schon +20 Punkte nur um dann vom Server gesagt zu bekommen: "Nääää so nicht Junge! Da war jemand schneller". Ein Teufelskreis.


Für Vorschläge, Ratschläge, Dokumente, Diskussionen, Erfahrungsberichte, Links, usw. bin ich sehr sehr dankbar.

Nein, ich bastle kein Moorhuhn-Multiplayer-Klon ;).

Viele Grüße,
euer erhabener DonElik.

[Despotist]

Wie wäre es also wenn ich JEDE Spielaktion (Schießen, Fadenkreuz bewegen, Nachladen, ...) zum Server übermittle und nur der dann die ganze Logik ausführt und das Ergebnis zurück schickt.

Du musst schauen welche Aktionen wirklich relevant für den Server sind. Den Server interessiert es normalerweise nicht wo der Spieler hinschaut. Nur in dem Moment wo er schießt wird das mit übermittelt und der Server prüft ob etwas getroffen wurde. Bei einem Shooter wo man sehen können sollte wo der Gegner hinschaut ist es wichtig aber bei Moorhuhn ist es egal wo der Gegner hinzielt.

Wie wäre es also wenn ich JEDE Spielaktion (Schießen, Fadenkreuz bewegen, Nachladen, ...) zum Server übermittle und nur der dann die ganze Logik ausführt und das Ergebnis zurück schickt.

Das Ergebnis musst du aber an alle beteiligten Spieler senden. Nicht nur an den betroffenen. Auf jeden Fall sollte jede Logik aber auf dem Server laufen um wie du schon erkannt hast Betrug zu vermeiden und auch das Sync-problem gleichmäßig auf alle Spieler zu verteilen (von Leitungsungleichheiten mal abgesehen) damit keiner einen Vorteil hat.

Beziehst du dich mit "Multiplayer" auf 2 Spieler oder mehr?

Wie kann ich dafür sorgen das diese Verzögerungen nicht für Ungereimtheiten im Spielablauf sorgen.

Bei vielen Spielen extrapoliert der Client die aktuelle Position aus der letzen bekannten Position und Geschwindigkeit/Richtung. Wenn der Spieler dann eine Änderung macht und sich beim nächsten Sync/Update an einer anderen Position als der berechneten befindet wird er einen Sprung machen was zwar unschön ist sich aber nicht vermeiden lässt. Es ist besser als wenn keine Extrapolation gemacht wird und der andere Spieler immer hinterherhängt oder sich ruckartig bewegt bei jedem Sync.

Solange das Ergebnis nicht da ist, kann der Client ja auch mit seinen Ergebnissen weiter rechnen. Nur wäre es schlimm wenn ein Huhn beim Client S1 gerade durch enorme Feuerkraft stirbt aber der Server schon weiß das S2 schneller war. Dann bekommt S1 von seiner Client-Logik schon +20 Punkte nur um dann vom Server gesagt zu bekommen: "Nääää so nicht Junge! Da war jemand schneller". Ein Teufelskreis.

Eine Client-Logik sollte es nicht geben. Nur zur Interpolation sollte eine (Physik)berechnung beim Client mitlaufen. Aber gerade Sachen wie Punkteverteilung, Schaden, Positionen usw sollten rein vom Server bestimmt werden.

euer erhabener DonElik.

Was macht dich denn so erhaben wenn ich fragen darf? ;)

[Chromanoid]

Nettes Tutorial, das auch für Nicht-Flash-Benutzer interessant ist:
http://playerio.com/documentation/tutor ... hitectures
Hier ein Überblick wie die Unreal Engine das macht:
http://udn.epicgames.com/Three/NetworkingOverview.html
Wenn der "Server" als Spielmodus von einem normalen Spieler gestartet wird, könntest du die Last auch verteilen und jeder kümmert sich bspw. um seine eigenen Schüsse.
Insgesamt wirst du eine Interpolation einbauen müssen. Das sieht sonst je nach Netzwerk usw. evt. so aus:

[donelik]

Hi, danke für deine schnelle Hilfe.

Beziehst du dich mit "Multiplayer" auf 2 Spieler oder mehr?

Bei meinem Projekt handelt es sich um ein Bis-zu-4-Spieler-Spiel.

Bei vielen Spielen extrapoliert der Client die aktuelle Position aus der letzen bekannten Position und Geschwindigkeit/Richtung. Wenn der Spieler dann eine Änderung macht und sich beim nächsten Sync/Update an einer anderen Position als der berechneten befindet wird er einen Sprung machen was zwar unschön ist sich aber nicht vermeiden lässt. Es ist besser als wenn keine Extrapolation gemacht wird und der andere Spieler immer hinterherhängt oder sich ruckartig bewegt bei jedem Sync.

Das ist eine gute Idee. So gebe ich den Clients am Besten immer ein Paket (PlayerGameObject-Paket) welches folgende Sachen enthält: Aktuelle Position, Aktuelle Aktion mit Parametern (Bewegung, in Richtung x,y). Zuvor muss ich natürlich, wie du schon sagst, die relevanten Aktionen identifizieren. (Dem Server interessiert es nicht dass Spieler 2 die Helligkeit hochgeschraubt hat usw.).

Punkte und weitere Daten werden separat geliefert.

Fein fein klingt sehr gut. Jetzt habe ich Lust das umzusetzen. Brauche nur die Zeit dafür :(.

Wann sollte versucht werden ein Paket zum Server zu versenden? In jede Frame? Immer wenn gerade "frei" ist? Oder nach einem bestimmten Zeitabstand? Ich würde ja meinen dass in jeder Frame ein Paket erzeugt wird und der Netzwerk-Code selbst entscheidet ob es jetzt an der Zeit ist dem Server das Paket zu übermitteln.

Der Server sollte m.E. immer versuchen alle Daten sofort raus zu schicken. Außer wenn er bereits das nächste Paket des Clients hat. Dann kann überflüssige Pakete übersprungen werden. (Da in einem PlayerGameObject-Paket ja sowieso immer die aktuelle Position mitkommt, bietet sich das sogar an).

Was macht dich denn so erhaben wenn ich fragen darf? ;)

Frag mal meine Freundin :lol:

@Chromanoid: Danke für die Links. Link 1 ermutigt mich dazu bei meinem Server-Client-architecture-Gedanken festzuhalten. Peer2Peer fällt aus. Die GIF zeigt genau das was ich vermeiden will :).

Wenn ich den Server-Betrieb vom Client-Betrieb trenne (wie oben erwähnt bei Q3A), fällt es mir später relativ leicht einen Standalone-Server anzubieten.

OT: Wow. Das phpBB erkennt automatisch dass während dem Tippen meiner Antwort Chromanoid geschrieben hat. Mein Beitrag wird nicht gespeichert sondern nochmal im Entwurfsmodus vorgelegt! Hat sich also dort einiges getan. Nice.

Vielen dank und viele Grüße,
DonElik

[pUnkOuter]

Normalerweise hast du für die Synchronisierung der Gamelogic auf den verschiedenen Clients einen fixen Takt, der von der Framerate entkoppelt ist. Heutzutage liegt dieser Takt oft zwischen 30 und 60 Hz. Ich glaube Aliens vs. Predator 2 hatte einen relativ niedrigen Logic-Takt, was man dann sogar im LAN durch stockende Bewegung vorbeizischender Aliens bemerkt hat.

Obwohl du bei einem Moorhuhn-ähnlichen Spiel tatsächlich nur relativ wenig vom Client zum Server schicken musst, ist dies umgekehrt leider nicht der Fall. Die Position der Hühner muss auf jedenfall der Server vorgeben, sonst schiesst ein Spieler bei sich auf ein Huhn und trifft, aber der Server hat eine andere Position des Huhns und gibt dann die Punkte nicht.

[Schrompf]

Ich glaube, die Update-Rate im Netzwerk liegt eher bei 5 bis 10 Updates pro Sekunde, selbst bei schnellen Spielen wie Unreal Tournament. D.h. der Server simuliert das Gameplay mit 30 bis 60 Updates pro Sekunde, aber der aktuelle Status wird nur 5 bis 10 mal pro Sekunde ins Netz geschickt.

[eXile]

Ich wollte hier auch noch eine Übersicht kundtun, welche Techniken im Netzwerkbereich der Source-Engine eingesetzt werden.

[pUnkOuter]

Ich glaube, die Update-Rate im Netzwerk liegt eher bei 5 bis 10 Updates pro Sekunde, selbst bei schnellen Spielen wie Unreal Tournament. D.h. der Server simuliert das Gameplay mit 30 bis 60 Updates pro Sekunde, aber der aktuelle Status wird nur 5 bis 10 mal pro Sekunde ins Netz geschickt.

Das kann sehr gut sein. Ein schnelleres Update wäre bei AvP2 wahrscheinlich auch nicht aufgefallen, aber 5Hz ist schon ein wenig tief und je nach Spiel wohl bemerkbar.

[klickverbot]

Im Bezug auf Physik-Simulationen in Multiplayer-Spielen könnte auch http://gafferongames.com/2008/02/27/gdc ... -released/ ganz interessant sein (»Mercenaries 2: Networked Physics in a Large Streaming World«). Die Folien sind zur Zeit nicht erreichbar (404), aber man findet sie leicht sonstwo.

[Zudomon]

Ich habe auch noch eine Frage zum Netzwerk.
Und zwar arbeite ich ja mit UDP und würde gerne Kommandos übertragen, z.B. dass der Charakter springt. Dabei könnte es nun sein, dass dieses Kommando nicht übertragen wird. Wie könnte man am geschicktesten lösen, dass das Event auch ankommt? Spontan würde ich sagen, am besten, wenn der Kommando-Sender auch auf eine Antwort warten, also empfangsbestätigung, ansonsten nochmal schicken. Habt ihr eine bessere Lösung?

[Biolunar]

Dann ist doch TCP eher angebracht oder sehe ich das falsch?

[pUnkOuter]

Irgendwo hab ich mal gelesen, dass du nie Ereignisse, sondern Zustände übertragen sollst, wenn du mit UDP arbeitest. Du würdest also in die normale Positionskommunikation noch ein Flag reinpacken, ob der Spieler am Springen ist, oder nicht. Wenn dann einzelne Pakete verloren gehen, ist das nicht weiter schlimm, evtl. läuft dann die Animation ganz leicht verzögert.

[Jaw]

Also aus der Praxis kenne ich es so: Alles wird auf dem Server auf Logik geprüft, validiert und entschieden und dann zurück an den Client gesendet. Kann man z.B. bei World of Warcraft erleben, wenn die Leitung mies ist, da gehen schon mal 1 - 2 Sekunden ins Land, nachdem man einen Knopf gedrückt hat, bis die jeweilige Aktion dann auch geschieht.

Auch üblich ist aber, dass der Client schon mal ne Prognose macht. Das kenne ich auch verschiedenen Spielen, z.B. Shootern, die schon mal einen Treffer ausgeben, z.B. Blutspritzer, passender Sound, der dann nachher aber gar nicht statt findet. Oder manchmal sieht man auch Spieler wie bekloppt gerade aus an die Wand laufen, weil es ein Lag gibt. Der Client behält für die Figur einfach Richtung und Geschwindigkeit bei, bis eine neue Nachricht mit Position, Richtung und Geschwindigkeit kommt. So lange Nachrichten oft genug kommen, passen Prognose und Realität meist gut zusammen und man merkt nix. Aber wenn man so nein Loch hat und ne Sekunde keine Updates kommen, kann es schon mal zu Sprüngen kommen. Oder das allseits bliebte nix nix nix man ist tot. Weil genau in dem Moment wer um die Ecke kam und geballert hat, während man ein Verbindungsloch hatte.

Wie oben beschrieben ist es wohl üblich bei schnellen Titeln im Client stets mit den aktuellen Infos weiter zu simulieren und stets mit dem abzugleichen, was der Server sendet. UDP ist da meist geeignet, da auch wenn ein Paket verloren geht, jedes Paket hat Position, Richtung und Geschwindigkeit und man ist sofort wieder auf dem richtigen Stand. Wenn mehrere Pakete entfallen kann es halt mal einen kleinen Hupfer geben. Das was wirklich gilt, also z.B. wer wen abschießt, entscheidet dann der Server. Fortschrittliche Netzwerkcodes rechnen angeblich sogar den Ping mit ein. Wenn A und B gleichzeitig aufeinander schießen, aber B hat den höheren Ping, ist seine Nachricht ja eigentlich älter als die von A und zuerst. Man kann aber auch eine ständig synchronisierte Zeit mitlaufen lassen, so dass jeder Client seinen Zeitstempel ins Paket einträgt. Muss natürlich validiert werden, der Client könnte da betrügen.

Ich plädiere dann normalerweise dafür, dass man bei Hobby Projekten auch mal Logik auf dem Client machen darf, wenn es dadurch deutlich einfacher wird, weil ich Betrugsschutz im kleinen Hobby Bereich nicht so dringlich finde.

Grüße
-JAW

[donelik]

Vielen Dank für die Antworten und die tollen Tipps.

10 Hz haben sich als ausreichend erwiesen. Auch dass der Server die Logik leitet und die Clients in der Zwischenzeit mit ihren Daten weiter rechnen hat sich als ziemlich praktisch erwiesen. Ich habe mal absichtlich zu jeder Bewegung vom Server etwa 50% hinzu addiert und es wurde stets korrekt angepasst.

Läuft also :).

[odenter]

Was mich mal interessieren würde wäre wie das genau mit Zonenservern läuft. Also wie die Zonen eingeteilt werden.
Wie grundsätzlich die Spielwelt zerlegt wird ist mir klar, sage ich dem Server sowas in der Art wie
"Du berechnest alles innerhalb der Koordinaten xyz - xyz"? Also vermutlich schon oder?

Denn irgendwie muss ich ja feststellen welche Objekte ich nun in welche Liste auf welchem server verschieben bzw. laden muss?

[Chromanoid]

Stell dir das ganze eher wie einen Scenegraph vor. Jede Zone ist ein "Node" und Trigger-bereiche regeln die Übergänge der Clients zu anderen "Nodes". Die Server verarbeiten dann immer die Nodes (Zonen). Jede Zone hat i.d.R. auch ihren eigenen Ursprung.
Meld dich mal bei HeroEngine an und schau dir folgendes an:
http://hewiki.heroengine.com/wiki/Area_Architecture
http://hewiki.heroengine.com/wiki/Seamless_area_link
http://hewiki.heroengine.com/wiki/Proxied_node
http://hewiki.heroengine.com/wiki/Refer ... Adjustment
http://hewiki.heroengine.com/wiki/Transition_Topology

[odenter]

Das sieht interessant aus, danke.

[joggel]

Alle Links verlangen ein PW... :(

[Chromanoid]

Ich weiß :)

Meld dich mal bei HeroEngine an

--> https://account.heroengine.com/signup/

[joggel]

Ich weiß :)

Meld dich mal bei HeroEngine an

--> https://account.heroengine.com/signup/

Ah, mist. Mal wieder nicht alles gelesen, sondern nur auf die Links geklickt :?

[odenter]

Hab hier auch noch was aus einem anderen Forum.
http://pikkotekk.com/pikko-server-tech-summary.pdf