Multiplayerspiel Netzwerktechnik ?

[arbu man]

Hi,

ich suche für ein Spiel nach einer möglichkeit den netzwerk verkehr zu regeln, bisher hab ich versucht durch einen timer die positionen der spieler mit einen record(393 byte für alles) über udp zu übertragen. Diese Lösung funktioniert allerding nicht wirklich da erstens die spieler "flackern" und man zweitens gigabit netzwerk benötigt (was noch nicht viele leute haben). Deswegen suche ich jetzt nach einer anderen? Lösung.
Welche möglichkeiten gibt es da noch, bzw. wie lösen andere Spiele das ?

[edit=Christian Seehase]Rechtschreibfehler im Titel korrigiert Mfg, Christian Seehase[/edit]

[inherited]

Andere SPiele lösen das, indem sie auch die Richtung und die GEschwindigkeit der anderen SPieler übermitteln, und sie dann, in der Annahme das sie den Weg weiterlaufe, immer mitsetzen lassen

[Tubos]

Zitat:

Andere SPiele lösen das, indem sie auch die Richtung und die GEschwindigkeit der anderen SPieler übermitteln, und sie dann, in der Annahme das sie den Weg weiterlaufe, immer mitsetzen lassen

Genau, so wird das normalerweise gemacht.
Desweitern kriegst du Probleme wenn ein Client zum Spiele-Server eine hohe Pingzeit haben - zum Beispiel 100ms. Dann sieht der Client nämlich eine andere Ansicht der Spielwelt als der Server. Auch dafür gibt es Algorithmen, die das ausbügeln.

Benutz Google, irgendwo gibt es ein Tutorial zu dem Thema - ich glaube, es war auf gamedev.net.
Aber erwarte nicht, dass das einfach zu realisieren ist!

[arbu man]

Ping Zeiten sind mir im LAN ziehmlich egal erst mal muss es flüssig laufen.

Aber zum übertragen der geschwindigkeiten und richtungen. An diese möglich keit hab ich auch schon gedacht. Ich habe mich allerdings gegen diese möglichkeit entschieden, da sich mir folgendes problem eröffnet hat:
Ich versende die daten über das udp protokoll da können ja pakete verloren gehen d.h. wenn ich diesen weg gehen könnten die spiele "auseinander driften". Was kann ich dagegen machen ? Auf das langsame TCP ausweichen oder etwas anderes ?

Werde mich jetzt erst mal auf gamedev.net umschauen.

[3_of_8]

Ich nehme mal an, es gibt einen Server?
Wenn es einen gibt, dürfte es egal sein, wenn mal ein Paket in den Bit Bucket fliegt, dann bemerkt man halt ein Ruckeln oder so, das ist in Battlefield zum Beispiel auch so.

[igel457]

Um das auseinanderdriften zu vermeiden kannst du ja neben dem Richtungsvektor noch die Aktuelle Position übermitteln. Nachteil ist, dass dann allerdings Objekte "springen" können, was nicht sehr schön aussieht.

Ich würde dir wirklich TCP ans Herz legen. Wenn man das Spiel übers Internet mit UDP Spielt, dann kommt hinten vermutlich nicht mehr sehr viel an...

[arbu man]

Nein einen richtigen server gibt es nicht. Ich werde jetzt aber wahrscheinlich auf tcp umsteigen und einen richtigen server machen.

[arbu man]

Ich habe mir grade die Indy TCPServer und Client angeschaut, jedoch vermisse ich bei diesen Komponenten das OnReceive Event, wie ich das verstehe wird alles über einen Theard geregelt. Gibt es eine möglich dass man da keine OnReceive Event hinzufügen kann oder gibt es eine andere TCP Komponente mit einen solchen ?

mfg, Björn

[Tubos]

Zitat:

Ich würde dir wirklich TCP ans Herz legen. Wenn man das Spiel übers Internet mit UDP Spielt, dann kommt hinten vermutlich nicht mehr sehr viel an...

Worauf basiert diese Behauptung? Hast du das auch selber ausprobiert?
Es passiert in der Tat eher selten, dass Pakete verschwinden! Mach mal "ping -t google.at" und schau dir das Ergebnis an!

TCP ist für ein Spiel in den meisten Fällen unbrauchbar. Beispiel: Wenn das Datenpaket mit der aktuellen Geschwindigkeit und Position verloren geht, dann wird es wiederholt. Kommt es dann schließlich an, ist es zu spät - die Daten sind nicht mehr aktuell. Genau deswegen ist TCP auch für VoIP und Videokonferenzen ungeeignet.

[arbu man]

Zitat:

TCP ist für ein Spiel in den meisten Fällen unbrauchbar. Beispiel: Wenn das Datenpaket mit der aktuellen Geschwindigkeit und Position verloren geht, dann wird es wiederholt. Kommt es dann schließlich an, ist es zu spät - die Daten sind nicht mehr aktuell. Genau deswegen ist TCP auch für VoIP und Videokonferenzen ungeeignet.

Welches Protokol wird denn in den meisten Spielen verwendet ? bzw ist gut ?

[DGL-luke]

naja UDP halt... viel mehr gibts ja auch gar nicht.

einfach immer, wenn du ein paket kriegst, den spieler, zu dems gehört, aktualisieren - und wenn kein paket kommt, ja mei, must halt noch ein bisschen interpolieren.

[alias5000]

Also wenn ich ein Multiplayer-spiel starte, kann ich mich recht gut erinnern, dass ich da immer TCP/IP (oder auch IPX, oder wie das hieß) zur Auswahl hab, man nenne Anno (1602, 1503), Empire Earth (1+2) und eigentlich sinds doch alle, oder? Mir ist noch nie udp in dem Zusammenhang über den Weg gelaufen.

So spontan könnte man es nicht so machen, grundsätzlich nur Richtungsvektoren zu verschicken und in gewissen Abständen die genaue Position zusätzlich? Das wäre evtl. ein Ansatz um mögliche Fehler auszubügeln, wobei du bei TCP/IP schon recht sicher laufen würdest

[Tubos]

Zitat:

Also wenn ich ein Multiplayer-spiel starte, kann ich mich recht gut erinnern, dass ich da immer TCP/IP (oder auch IPX, oder wie das hieß) zur Auswahl hab, man nenne Anno (1602, 1503), Empire Earth (1+2) und eigentlich sinds doch alle, oder?

Der Protokollstapel, der im Internet verwendet wird, wird meist als "TCP/IP" bezeichnet.
UDP gehört jedoch auch zum TCP/IP-Protokollstapel dazu!

[igel457]

Zitat:

TCP ist für ein Spiel in den meisten Fällen unbrauchbar. Beispiel: Wenn das Datenpaket mit der aktuellen Geschwindigkeit und Position verloren geht, dann wird es wiederholt. Kommt es dann schließlich an, ist es zu spät - die Daten sind nicht mehr aktuell. Genau deswegen ist TCP auch für VoIP und Videokonferenzen ungeeignet.

Allerdings kannst du dir bei TCP sicher sein, dass es wirklich angekommen ist. Bei UDP hingegen kannst du das nicht und musst deshalb wirklich kontinuierlich Daten senden. Auch wenn der Client immer eine Antwort sendet, wer garantiert mir, dass diese wirklich angekommen ist?
Ein weiteres Problem ist:

Nehmen wir an, in dem Spiel haben wir 20 Figuren, die jedes Frame ihre Richtung ändern können. Hinzu kommen weitere Sondertasten (Schießen, Waffe wechseln, etc), gehen wir mal von 16 Tasten, also 2 Byte aus. Hinzu kommt für jede Figur noch mal an Header, also noch mal 2 Byte. Macht zusammen 4 Byte pro Figur.
Das können bei 20 Figuren und 50 Frames pro Sekunde maximal 1000 Datensätze sein. Bei 4 Clients und 4 Byte pro Figur macht das schon mal 15,625 KB Upload/Sekunde. Da kommt jeder normale DSL Anschluss ins Schwitzen.

Bei UDP musst du jetzt davon ausgehen, dass ein Packet verloren gegangen ist und immer noch die Aktuelle Position mitsenden. X,Y noch mal 8 Byte zusätlich (integer). Macht schon 12 Byte pro Figur. Bei Maximalbelastung wären das dann 31,25 KByte Upload!

Natürlich muss man auch bei TCP ab und zu die Position der Objekte übertragen um eventuelles Auseinanderdriften zu verhindern.

Bei Lokalen Netzwerk spielen ist es Praktisch egal was du nimmst. Aber hier würde auch ich UDP Favoritisieren. Aber beim Internet muss man (je nach Spiel) den Upload im Auge behalten...

Ich hoffe das war jetzt kein kompletter Müll, aber das ist meine aktuelle Meinung zu dem Thema. Ich programmiere gerade eine Netzwerkengine für mein Spiel (Link siehe Signatur) und wenn es da Irgendwelche, neuen Erkenntnisse geben sollte (die mich eines anderen Belehren), dann werde ich euch diese nicht vorbehalten.

Ich glaube arbu man meinte nicht die Standart Protokolle sondern das Spiele-Byteebene-Protokoll.
Ich werde folgendes versuchen: (Beispiel)

Code:

1. Byte = 0 //Stream Start
<--Block Start-->
2. Byte = 1 //Header (Irgendwelche Nummern z.B. 1 = Figur, 2 = Haus, 3 = Neues Objekt)
3. Byte = 10//Nr. (Figur Nr. 10)
4. Byte = B1//Richtung, Tasten byte 1
5. Byte = B2//Richtung, Tasten byte 2
<--Block Ende -->
<--Block Start-->
6. Byte = 3 //Header (Irgendwelche Nummern z.B. 1 = Figur, 2 = Haus, 3 = Neues Objekt)
7. Byte = 10//Typ (Kiste)
8. Byte = X //X Position (4 byte)
9
10
11
12. Byte = Y//Y Position (4 byte)
13
14
15
16
<--Block Ende -->
.
.
.
17. Byte = 255 //Stream Ende

Igel457

[arbu man]

Wahrscheinlich werde ich jetzt ein Mischung aus TCP und UDP nehmen dann hab ich auch noch zusätzlich eine "sichere Leitung" und einen Server. Allerdings frage ich mich wie ich die Pakete am besten auslese ? bisher habe ich das mit einen record gemacht aber das scheint auch nicht das beste zu sein...

[SirThornberry]

warum ist ein Record nicht das beste? ein Record ist nur eine Definition wie die Daten im speicher behandelt werden sollen. Letzendlich liegen die Daten direkt hintereinander.

[arbu man]

Das dachte ich zuerst auch jedoch wird ein record schnell zu groß wenn man mal nur wenig informationen zu senden hat (z.B. genau 1 Byte), des wegen gehe ich jetzt denn umweg über einen stream ich packe zu erste einen Command Integer in den stream und dann alles was für das command gebraucht wird dann pack ich alles in eine array of byte und schick es mit SendBuf raus (so soll es zumindest werden)

[supermuckl]

Ich würde dir raten, wenn du dich mit C++ auskennst, den Netzwerk-Sourcecode von Q2 oder Q3 zu studieren (google hilft)

Ansonsten kann ich dir ein wenig über die Grundlagen erzählen, die ich im laufe von Dokumentation-Schnüffeleien in Multiplayer Netcodes entdeckt habe.

1. Es werden nur Veränderungen gesendet - Das hat eine art Grundkomprimierung der Daten, die übertragen werden zur Folge und somit weniger Traffic

2. Es werden meistens gemischte Protokolle gleichzeitig verwendet. TCP für Sicherheitsrelevante Daten und "Ping ist egal" Übertragungen. UDP für alle restlichen Übertragungen (z.b. Spielerpositionen usw)

3. Zu den "komprimierten" Spielerdaten kommen noch die Forcierten "Komplettdatensätze" dazu. Diese beschreiben ein Volltelegramm, das komplett alle Daten überträgt, falls mal viele Pakete verloren gingen. Dieses wird in regelmäßigen Zeitabständen gesendet.

4. Es gibt mehrere "Prioritäten" an Datenpaketen mit mehr oder weniger großen Transferintervallen. Die Spielerbewegungen, Blickrichtungen, Schusswechsel, Flugbahn der Geschosse usw haben z.B. eine hohe Prio und werden mit z.B. der Framerate vom Server gesendet ( bei COD2 z.b. 20FPS ).
Die Weltobjekte wie z.B. Powerups oder Waffen, die rumliegen, werden mit einem langsameren Intervall aktualisiert usw.

5. Es werden verschiedene Techniken verwendet, um dem Lag, der über Internet entsteht (Lan ist zu vernachlässigen), zu kompensieren. Es wird beispielsweise auf Clientseite der Spieleverlauf ein paar ms in die Vergangenheit gesetzt. Und Treffer werden bei Lagkompensierung Clientseitig ausgewertet und im Server nachgeprüft (der dann auch einige Zeitverschiebungen intern verrechnet). Ohne Lagkompensierung trifft man z.b. nur durch Vorhalten, da man ja die Vergangenheit sieht, und in die Zukunft schiessen muss.

6. Die Spielerpositionen und Sichtwinkel (egoshooter) werden interpoliert dargestellt (weshalb man auch ein paar ms in der Vergangenheit zockt). Das heist, ein Paket das ankommt, wird nicht direkt umgesetzt in Grafik, sondern wird zwischengespeichert und erst mit dem nächsten Paket wird es verrechnet (und dazwischen wird der Weg interpoliert und als Grafik dargestellt). Somit gibt es keine "Ruckler".

Ich hoffe geholfen zu haben.

[Daniel G]

Zitat:

Zitat von igel457

Nehmen wir an, in dem Spiel haben wir 20 Figuren, die jedes Frame ihre Richtung ändern können. Hinzu kommen weitere Sondertasten (Schießen, Waffe wechseln, etc), gehen wir mal von 16 Tasten, also 2 Byte aus. Hinzu kommt für jede Figur noch mal an Header, also noch mal 2 Byte. Macht zusammen 4 Byte pro Figur.
Das können bei 20 Figuren und 50 Frames pro Sekunde maximal 1000 Datensätze sein. Bei 4 Clients und 4 Byte pro Figur macht das schon mal 15,625 KB Upload/Sekunde. Da kommt jeder normale DSL Anschluss ins Schwitzen.

Bei UDP musst du jetzt davon ausgehen, dass ein Packet verloren gegangen ist und immer noch die Aktuelle Position mitsenden. X,Y noch mal 8 Byte zusätlich (integer). Macht schon 12 Byte pro Figur. Bei Maximalbelastung wären das dann 31,25 KByte Upload!

Ich würde einen zentralen Server verwenden. Dann schickt jeder Client seine Position an den Server und der Server schickt die Daten in Pakete an die Clients zurück. Dann benötigt der Server zwar eine schnelle Anbindung, für die Clients würde dann aber schon ISDN reichen.

[arbu man]

Zitat:

Ich würde dir raten, wenn du dich mit C++ auskennst, den Netzwerk-Sourcecode von Q2 oder Q3 zu studieren (google hilft)

Leider kann ich C++ überhaupt nicht :(

Aber danke für die 6 Punkte werde mal versuchen ob ich etwas davon umsetzen kann :?

[supermuckl]

Natürlich gehe ich auch von einem zentralen Server aus. Das ist und bleibt die beste Architektur bei Netzwerkspielen.

//edit:
hier die webseite mit dem Q3 source
Q3SRC

[arbu man]

Nun ja also bei mir wären das pro spielfigur an daten

Delphi-Quellcode:

TPOS =  packed record { 12 Byte }
  X, Y, Z: Single;    { 3 * 4 byte}
end;

Zum ständigen über tragen brauche ich:
Direction und Gescwindigkeit(Single) also (16 Byte + 4 Byte Header) => 20 * 25 FPS = 500 Byte/s { + 16 Byte Position und evtl. Aktionen wie Schuss aber nur 3 mal in einer sekunde also nochmal 15 Byte [3 * 5 Byte] }

Dann noch gelegentlich die position mit senden macht noch mal 16 Byte für ein paket nur mit der position.

Um das senden der information wie "fighter7" bin ich durch die ip herrum gekommen :)

Nach dieser Rechnung sollten 531 Byte ausreichen das sollte das LAN schaffen nur wie übertrage ich die informationenich muss ja auf jeden fall das ganze mit sendbuf(var b; count: integer) raussenden. Nur was soll am besten b sein record(s) stream, etc ?