spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich habe RakNet vor einigen Jahren mal verwendet und war ganz zufrieden damit. Es hat gut funktioniert, UDP-Unterstützung hat man auch.
Wie es aber in letzter Zeit aussieht weiß ich nicht. Wurde ja von Oculus VR aufgekauft, sollte aber immernoch gut laufen.

Zitat von »Kitarios«

In beiden Fällen möchte ich auf UDP setzen, da ich für das schnelle Gameplay mit TCP keine annehmbare Latenz erwarte.

Ernsthaft, sowas sollte dringend getestet werden, bevor man irgendwelche wüsten Erwartungen aus dem Nichts erschafft. UDP hat gegenüber TCP diverse Probleme, die man eigentlich sehr ungern haben will. Man kann sich da oft eine Menge Ärger sparen, wenn man TCP nutzt. Selbst mit TCP ist ein Ping von 30ms und weniger drin. Also sollte das echt erst probiert werden. Ich frage mich eh woher dieses Vorurteil immer kommt. Es kursiert hier gefühlt in letzter Zeit immer die Meinung, dass TCP für alles zu langsam sei und das halte ich für großen Unsinn.

Zitat

Raknet ist sicherlich toll, aber ich verwende nix was Lizenzen braucht.

Ich weis ja nicht wann du das letzte mal bei RakNet geschaut hast, aber interessanter weise hat die von dir gepostete Lib einen recht langen Lizenztext (im vergleich zu RakNet).

Vergleich:

Lizenz SFNUL: https://github.com/binary1248/SFNUL/blob/master/LICENSE

Lizenz RakNet: https://github.com/OculusVR/RakNet/blob/master/LICENSE

Ich hab mein Bomberman-Spiel mit UDP komplett gelöst und das hat zumindest im lokalen Netz hervorragend funktioniert. Glaube das ist vielleicht genauso ein Vorurteil zu sagen man sollte immer TCP nehmen.

Der Vorteil der Benutzung von UDP ist, dass man selbst bestimmen kann, welche Nachrichten unbedingt und in der Originalreihenfolge ankommen müssen (indem man das selbst implementiert, bzw. es durch eine Library machen lässt), und welche nicht. Nehmen wir mal das Beispiel eines Multiplayer-Shooters. Ist es wichtig, dass jedes Positions-Update anderer Spieler 100%ig und in der originalen Reihenfolge beim Spieler ankommt? Ich würde sagen nein. TCP würde hier bei einem verlorenen/beschädigten Paket sämtliche nachfolgende Pakete aufhalten, was für mich nicht hinnehmbar wäre. Andere Nachrichten wie "Du bist jetzt tot!" oder "Spieler X hat Spieler Y getötet!" sollten natürlich zuverlässig ankommen.

Zitat von »BlueCobold«

Ernsthaft, sowas sollte dringend getestet werden, bevor man irgendwelche wüsten Erwartungen aus dem Nichts erschafft.

Oder man glaubt den erfahrenen Spieleentwicklern:

Zitat von »https://1024monkeys.wordpress.com/2014/04/01/game-servers-udp-vs-tcp/«

Writing a few test programs showed the WiFi occasionally dropping packets, and every time that happened, server response time shot up from 100-150 ms to 1000-2000 ms.

No amount of tweaking of TCP settings could get around this issue.

We replaced the TCP code with a custom reliable UDP implementation which cut the penalty of a lost packet down to an additional 50 ms(!) – less than the time of a complete roundtrip. And that was only possible due having complete control of the reliability layer on top of UDP.

Zitat von »http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/«

Using TCP is the worst possible mistake you can make when developing a networked action game like an FPS! To understand why, you need to see what TCP is actually doing above IP to make everything look so simple! (...)

Na dann nenn mir mal die Lösung, die du gehst, wenn es sich bei dem verlorenen Paket um etwas wichtiges handelt - wie z.B. einen Schuss-Befehl, Bewegungs-Request des Spielers oder eigentlich überhaupt alles, was ein Spieler als Request an den Server schickt. Dass der Server Responses droppen kann, die Informationen darüber enthalten, was andere Spieler tun und dass das meist kein Problem darstellt, das ist mir auch klar.

Zitate kann auch ich aus dem Internet viele zaubern. Aber da steht noch lange nicht drin wie viel Ärger und Aufwand man sich einhandelt, damit man solche Probleme lösen kann.

Zudem glaube ich nicht jedem Neuling, dass er tatsächlich so heftig große Performance benötigt, wie er angibt, ohne dass er mit Netzwerk überhaupt schon jemals irgend etwas gemacht hat. Ich habe mehrere Jahre an einem Fast-Paced-PvP-MMORPG mitgearbeitet, da lief alles über TCP und ich habe es nicht ein einziges Mal erlebt, dass Performance und Latenz-Probleme mit TCP zu tun gehabt hätten. Sicherlich hatten auch wir Latenzen, aber die wichtigen sind immer die ausgehenden Befehle, die der User selbst auslöst - und da hast du überhaupt gar nichts davon, wenn diese nicht zuverlässig zum Server übermittelt werden - außer natürlich wütende Spieler ("ich habe 5mal geklickt und kein Schuss ging raus"). Du kannst natürlich Deiner UDP-Bibliothek sagen, dass diese Dinge wichtig sind und immer zuverlässig ankommen sollen, aber dann ist das schlecht und langsam implementiertes TCP auf UDP oben drauf. Na bravo.
Wie wäre es denn stattdessen Verbindungen sinnvoll zu trennen? Die Daten, die nicht wichtig sind und die, die es sind? Eine moderne Bibliothek kann das sicherlich, ohne dass ich sie dazu zwinge alles als Fake-TCP-over-UDP zu behandeln.

Zitat von »TrommlBomml«

zumindest im lokalen Netz

'nough said.

Zitat von »BlueCobold«

Na dann nenn mir mal die Lösung, die du gehst, wenn es sich bei dem verlorenen Paket um etwas wichtiges handelt - wie z.B. einen Schuss-Befehl, Bewegungs-Request des Spielers oder eigentlich überhaupt alles, was ein Spieler als Request an den Server schickt.

Nochmal schicken. Aber nicht zwingend den kompletten Paketfluss stoppen, bis das verlorene Paket dann auch irgendwann angekommen ist, wie es bei TCP der Fall ist. Bei einigen Nachrichten wie z.B. “Ich will schießen!“ bringt es dir auch wenig, wenn sie dann mit großer Verzögerung ankommen. Manchmal ist es besser, die dann komplett fallenzulassen, sonst verärgerst du den Spieler noch mehr, weil nicht nur ein Schuss nicht ausgeführt wurde, sondern eine ganze Salve mit einer großen Verzögerung, dir alles sinnlos macht.

Zitat von »BlueCobold«

Sicherlich hatten auch wir Latenzen, aber die wichtigen sind immer die ausgehenden Befehle, die der User selbst auslöst - und da hast du überhaupt gar nichts davon, wenn diese nicht zuverlässig zum Server übermittelt werden - außer natürlich wütende Spieler ("ich habe 5mal geklickt und kein Schuss ging raus").

Siehe oben. In einem “schnellen Spiel“ habe ich lieber einen verschluckten Schuss von 4 als 5 Schüsse mit großer Verzögerung.

Zitat von »BlueCobold«

Du kannst natürlich Deiner UDP-Bibliothek sagen, dass diese Dinge wichtig sind und immer zuverlässig ankommen sollen, aber dann ist das schlecht und langsam implementiertes TCP auf UDP oben drauf. Na bravo.

Das klingt jetzt aber nach Vorurteil deinerseits, sämtliche Implementierungen als schlecht und langsam zu bezeichnen. Außerdem will man ja gar nicht TCP nachbauen, denn sonst könnte man es ja direkt benutzen. Es gibt Garantien, die TCP macht, die du ggf. gar nicht brauchst (wie z.B. die Einhaltung der Originalreihenfolge der Pakete), die du aber nicht abschalten kannst und mit denen du dir letztlich ins Knie schießt. Durch eine Implementierung, die auf UDP aufbaut, kannst du diese Garantien selbst auswählen und auf deinen konkreten Anwendungsfall zuschneiden.

Zitat von »BlueCobold«

Wie wäre es denn stattdessen Verbindungen sinnvoll zu trennen? Die Daten, die nicht wichtig sind und die, die es sind? Eine moderne Bibliothek kann das sicherlich, ohne dass ich sie dazu zwinge alles als Fake-TCP-over-UDP zu behandeln.

Dann hast du entweder alle Garantien oder gar keine. Was dazwischen gibt's dann nicht.

Na wie ihr meint. Empfehlt ruhig UDP, wenn Ihr Euch so sicher seid, dass das hier wirklich benötigt wird und zum Ziel führt. Mir soll das ja egal sein.

Zitat von »Bambi«

Ich weiss jetzt nicht wo der Aberglaube herkommt, dass TCP besser sein soll für Echtzeit-Spiele.

Du musst lernen zu lesen und zu verstehen. Das da hat nämlich niemand behauptet. Ich habe behauptet, dass er so eine Anforderung eventuell gar nicht hat und sich mit TCP viel Ärger spart. Aber wie gesagt, da Ihr es alle genau wisst, soll er doch machen wie er/Ihr denkt. Is nicht mein Problem
Übrigens switcht man nicht einfach zwischen UDP und RUDP hin und her, denn UDP ist ein Standard, während RUDP ein eigenes, proprietäres (also kein Standard) Protokoll ist. Da gibt's nicht einfach ein Flag bei den UDP-Paketen oder ähnliches, denn UDP selbst sieht das gar nicht vor.

Zitat von »David Scherfgen«

Manchmal ist es besser, die dann komplett fallenzulassen, sonst verärgerst du den Spieler noch mehr, weil nicht nur ein Schuss nicht ausgeführt wurde, sondern eine ganze Salve mit einer großen Verzögerung, dir alles sinnlos macht.

Oder natürlich das genaue Gegenteil ist der Fall - wie etwa bei Spielen, die Skills einsetzen im Gegensatz zu "point & click Shootern". Da kann es dann sogar sehr wichtig sein die Reihenfolge einzuhalten und alles andere zerstört komplett das ganze Match, wohingegen die Verzögerung verkraftbar gewesen wäre. Ich denke jetzt auch mal ein ein RTS, wie fatal wäre es da wohl wenn zwischendrin mal hier und da Klicks verschwinden würden oder sich deren Reihenfolge ändert? Bei den APM, die in den Ranking-Spielen ablaufen, wohl eher inakzeptabel.
Aber nun ja, mehr als nochmal zu sagen, dass man seine Anforderungen kennen sollte, bevor man irgendwas empfiehlt oder Annahmen trifft, kann ich nicht tun. Man kann ja schließlich auch mit einer Rohrzange eine Schraube in die Wand drehen...