Multiplayerspiel Netzwerktechnik ?

[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 :?