Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Mit dem Thema hatte ich mich bisher noch nicht befasst. Der Einfachheit halber würde ich die Prediction _erstmal_ vernachlässigenThema Prediction ist hier auch nicht ganz unwichtig. Ich weiß nicht ob du dir darüber schon Gedanken gemacht hast, bzw überhaupt viel damit anfangen kannst. Guck da vielleicht mal ein wenig im Internet. Was auch ganz nützlich ist, ist zu gucken wie andere Engines mit dem ganzen umgehen. Hier gab es im Forum mal einen Thread in dem drei Links genannt wurden. Einer zur Source Engine, in einem gings glaube um Quake und in einem ging es um allgemeine Konzepte. Die drei Links haben mir bei einem Projekt mal sehr gut weitergeholfen. Ich finde sie grad nicht. Ich gucke gleich aber noch mal.
edit: in diesem Beitrag. Fred hat recht weit oben drei Links gepostet. Die fand ich alle drei ziemlich informativ. Aber es war Unreal und nicht Quake Naja hilft dir sicher weiter.
Warum sollte ein Mix aus TCP und UDP zu Problemen führen? Ich bin bisher davon ausgegangen, dass das häufig zusammen verwendet wird. Klar sollte ich aufpassen, dass ich die Verwendung beider Protokolle nicht so ineinander verzahne, dass der Verlust eines UDP-Paketes die TCP-Verbindung aus dem Konzept bringt. Aber ich würde auch das mit den Wegpunkten bevorzugen. Der Client hat dann nur noch die Aufgabe den Weg zwischendrinnen zu interpolieren.er wenn ich dann wirklich zyklische Updates (Objekt X steht an Pos Y) sende, würde ich UDP vorziehen - für andere Kommunikation (die ggf. sicherer ankommen soll) nehme ich dann TCP.Meine (persönlichen) Tipps zu dem Thema (gibt nat immer die Ausnahmefälle wo diese Tipps nicht greifen, aber die sind selten):
-(eigentlich) nie TCP und UDP mixen. UDP wird TCP in fast jedem Fall aus dem Konzept bringen und die UDP Verlustrate wird auch nicht unbedingt besser dadurch.
-wenn möglich Zustände statt Nachrichten verwenden. Weil mit 100% Wahrscheinlichkeit geht irgendwann doch irgendwas schief und der berühmt berüchtigte OoS betritt die Bühne. Für ein Nachrichtne basiertes System ist dass äquivalent zum Gameover. Für ein Zustand basiertes ist das höchstens ein "ups" oder fällt garnicht auf.
Und warum sollte Gott keine Aktualisierungen über UDP verschicken?Zitat
Außerdem (hast du ja eh vor):
-server-client basiertes System & Server = Gott
Wenn du bei deinem Rollenspiel allerdings eine Pfeiltastensteuerung wie in Egoshootern drinnen hast, ist der Zielpunkt bzw. der Weg nicht vorhersehbar, daher würde ich z.B. jede 20 ms die aktuelle Transformation senden
und den Client halt zwischen den Daten interpolieren lassen. (Ich glaub das machen moderne Egoshooter auch so)
Sagen wir mal es gibt auf der Map 50 Objekte (Spieler, Gegner und rechnen wir mal Geschosse wie Pfeile und Feuerbälle mit ein, die sich bewegen). Wenn ich 50 Pakete (der Einfachheit halber ein Paket pro Objekt) sende, sind das 2.500 Pakete pro Sekunde. Nun könnte so ein Update-Paket z.B. 10 Byte groß sein (eine ID zur Identifizierung, eine Blickrichtung, eine ID für die aktuelle Animationsart - Idle, Move, Attack etc. - und noch eine Position in der Ebene). Dann sind wir bei ca. 24,4 KB. Nach einer gespielten Stunde wären das ca. 86 MB Daten, die durch Update-Pakete zustande kamen. Rein von der Menge der Daten her sollte das kein Problem sein. Allerdings habe ich keine Erfahrung damit, ob das zu Performance-Problemen führen könnte.Ein Rollenspiel ist kein Ego-Shooter. 50 Pakete pro Sekunde sind schlicht Irrsinn und zudem unnötig.
Zumindest bei den meisten.
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Glocke« (03.03.2013, 16:56)
Characteristics of UDP Packet Loss: Effect of TCP Traffic [via UDP vs. TCP - gafferongames.com]Warum sollte ein Mix aus TCP und UDP zu Problemen führen? Ich bin bisher davon ausgegangen, dass das häufig der Fall ist. Klar sollte ich aufpassen, dass ich die Verwendung beider Protokolle nicht so ineinander verzahne, dass der Verlust eines UDP-Paketes die TCP-Verbindung aus dem Konzept bringt. Aber wenn ich dann wirklich zyklische Updates (Objekt X steht an Pos Y) sende, würde ich UDP vorziehen - für andere Kommunikation (die ggf. sicherer ankommen soll) nehme ich dann TCP.
Das sehe ich 1:1 genausoBei RPGs kannst Du auf viele Details verzichten. Bei Diabloartiger Steuerung würde ich für die Bewegung nur die Zielpunkte ggf. relativ zu einem Grid übertragen. Wenn Du wirklich willst wirst Du ziemlich viel Komprimieren können.
Zitat
Alles was sich nicht bewegt, sollte möglichst nur einmal "Hallo" sagen und sich dann erst bei einem Zustandswechsel wieder über Netzwerk melden.
Kp wie ich das zu verstehen habe Also meine bisherige Idee war, dass der Client weiß, welche Animationsart (z.B. Idle) das Objekt gerade durchlebt. Bekommt es dann ein Update "Animationsart ist jetzt Move", dann startet es die Bewegungsanimation (die Frames sollte es schon lokal aus einer oder mehreren Dateien laden). Irgendwann kommt dann noch ein Richtungswechsel und der Client malt für das Objekt wieder einen anderen Frame (dem es lokal auf der Platte gefunden hat)Zitat
Was nützt Dir die Animationsart, wenn Du nicht den Frame mitschickst (so macht das AFAIR Quake2).
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Genau so hatte ich das vor. Hab ich das anders geschrieben, oder bezieht sich das auf Chromanoid?Bei einem RPG muss der Server überhaupt keine Animation schicken. Das kann der Client ganz allein machen anhand der Informationen wie:
- Objekt fängt an zu laufen
- Objekt hält an
- Objekt nutzt Skill XYZ
- Objekt nutzt Item XYZ
- ...
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Chromanoid« (03.03.2013, 18:01)
Ich arbeite mit C++ und habe mit SDL_net bisher sowohl mit TCP- als auch UDP-Sockets experimentiert. Derzeit arbeite ich an einem kleinen Framework, um Events (mit Primitivdaten) über TCP- oder UDP-Sockets zu versenden und an der Gegenseite in einer Warteschlange anzusammeln (dort warten die Events dann auf die Weiterbearbeitung).An Deiner Stelle würde ich erst mal nur mit TCP/IP arbeiten (das ist einfacher) oder vielleicht ein Framework einsetzen. Falls Du mit Java entwickelst wäre kryonet sicher was. Ansonsten kannst Du Dir mal Raknet anschauen.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Chromanoid« (03.03.2013, 18:18)
Werbeanzeige