spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Schorsch«

Thema 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.

Mit dem Thema hatte ich mich bisher noch nicht befasst. Der Einfachheit halber würde ich die Prediction _erstmal_ vernachlässigen

Zitat von »Nox«

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.

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.

Zitat

Außerdem (hast du ja eh vor):
-server-client basiertes System & Server = Gott

Und warum sollte Gott keine Aktualisierungen über UDP verschicken?

Zitat von »birdfreeyahoo«

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)

Zitat von »BlueCobold«

Ein Rollenspiel ist kein Ego-Shooter. 50 Pakete pro Sekunde sind schlicht Irrsinn und zudem unnötig.
Zumindest bei den meisten.

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.

Ach ja: und dazu kommt noch das, was das Protkoll an Daten eh noch mitschleift. Die 86 MB sind also reine Nutzlast ohne Informationen wie Absender und Empfänger! Wenn ich das dann per TCP sende, bekomme ich (vermute ich) sehr schnell ein Problem (Stichwort Three-Way-Handshake )

LG Glocke

Zitat von »Chromanoid«

Bei 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.

Das sehe ich 1:1 genauso

Zitat

Alles was sich nicht bewegt, sollte möglichst nur einmal "Hallo" sagen und sich dann erst bei einem Zustandswechsel wieder über Netzwerk melden.

Also z.B. Truhen ... das hat was von einem der asdf-Movies mit der Parkuhr "Hallo Parkuhr" - "Hallooooo"
Würdest du dann bei beweglichen Objekten regelmäßige Updates versenden? Prinzipiell kann man eine neue Zielposition ja als Zustandswechsel ansehen. Dann passt es auch für bewegte Objekte in dein Schema

Zitat

Was nützt Dir die Animationsart, wenn Du nicht den Frame mitschickst (so macht das AFAIR Quake2).

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)

Keine Ahnung ob das das ist was du meinst, oder etwas anderes

Zitat von »BlueCobold«

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
- ...

Genau so hatte ich das vor. Hab ich das anders geschrieben, oder bezieht sich das auf Chromanoid?


@Chromanoid: Was sollte man dann im Bezug auf die Verwendung von TCP und UDP machen? Nur TCP / nur UDP?

LG Glocke

Zitat von »Chromanoid«

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.

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).


Wie gesagt: bisher war ich davon ausgegangen TCP und UDP (für jeweils eigenständige Zwecke) parallel zu verwenden; UDP eben für Dinge die auch mal verloren gehen können und TCP für quasi alles andere. Wenn ich die Lösung mit den Wegpunkten (bei der Objektbewegung) verwende (statt der mit den Pfeiltasten und Bewegungsrichtungen), habe ich dann (aus derzeitiger Sicht) gar keine Daten mehr, die ich per UDP schicken würde. Also im Endeffekt würde ich dann mit TCP auskommen.


Einige Aussagen auf http://gafferongames.com wie "Using TCP is the worst possible mistake you can make when developing a networked game!" lassen TCP irgendwie als Teufelszeug dastehen. Dort wurde ja empfohlen UDP zu verwenden und die TCP-Features, die man benötigt - mit UDP zu implementieren. Das wäre dann aber das Rad zu 90% neu zu erfinden
Ich weiß nicht so recht, was ich davon halten soll


Wahrscheinlich muss ich das Spiel erst einmal mit meinem kleinen Framework implementieren ("Writing Games, not Engines" ) um herauszufinden, ob ich mit TCP überhaupt an die rechentechnischen Grenzen stoße. Passiert das kann ich mir dann ja noch einmal Gedanken machen, wie ich vorgehe. Stoße ich auf keine Probleme, wäre die Welt in Ordnung Oder wie seht ihr das?

LG Glocke