spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Jar«

Dazu würde ich mir http://gafferongames.com/networking-for-…ers/udp-vs-tcp/ mal durchlesen.

Aber dann doch auch bitte bis zum Ende. Der Autor rät nämlich direkt davon ab beides zu verwenden

Zitat

My recommendation then is not only that you use UDP, but that you only use UDP for your game protocol. Don’t mix TCP and UDP

Jupp. Weil wechselnde Last den TCP dazu veranlasst die Geschwindigkeit zu stark zu drosseln und UDP wiederum bei hoher Last durch TCP einfach die Pakete droppt.

Ja, man soll für die gleiche Aktion nicht die Pakete mischen. Aber für den Login TCP und für Positionsdaten UDP ist vollkommen in Ordnung.

Was mir gerade noch einfiel zum Thema TCP und langsam. Oft führt der sogenannte Nagle Algorithmus zu unerwünschten Verzögerungen bei Verwendung von TCP. Dieser ist darauf ausgelegt Daten solange zurückzuhalten bis entweder das aktuelle Paket voll oder aber das vorherige Paket bestätigt wurde. Dadurch erreicht man eine bessere Bündlung der Daten auf weniger Pakete, was effizienter ist. Für Spiele ist diese Verzögerung aber oft unerwünscht. Man kann den Nagle Algorithmus aber einfach per Flag abschalten.

Wie ist eigentlich das generelle Vorgehen, wenn man zum Beispiel die Positionsdaten aller Objekte des Servers mit denen der Clienten synchronisieren möchte?

Würde man über alle Objekte iterieren und dann für jedes Objekt ein Paket schicken, oder schickt man ein Paket in dem alle Daten vorhanden sind?
Oder was interessanter ist, macht das überhaupt einen Unterschied?

Und ist es ratsam nur ID's zu schicken und sowohl auf Server und Client Seite eine Art Mapping zu betreiben?

Beste Grüße,
Jar

Schick mal ein Buch als ein und danach das gleiche Buch Seite für Seite. Vergleich mal die Portokosten . Also man versucht die Anzahl der Pakete möglichst gering zu halten üblicherweise. Zur ID Frage: mich würde mal interessieren wie du es sonst machen wollen würdest. Vllt hast du ja eine revolutionäre Idee. Mir würde kein anderer Ansatz als IDs einfallen.

Auf sowas wie IDs kann man wirklich kaum verzichten. In einem experimentellen Projekt habe ich mal versucht trotzdem die IDs nur möglichst selten zu versenden. Pro Gebiet einer gewissen Größe habe ich beim ersten Kontakt mit dem "Sichtradius" eines Spielers, die IDs aller Objekte im Bereich, sortiert übertragen. In der gleichen Reihenfolge habe ich dann Positionsdaten o.Ä. übertragen. Es gab dann noch ein Bitset, das angegeben hat, ob ein Objekt im Vergleich zum vorherigen Zustand überhaupt Änderungen vorzuweisen hat (und ob ein Objekt das Gebiet wieder verlassen hat usw.). Diese Art der Übertragung wurde natürlich nur gewählt, wenn sie kleiner war als die herkömmliche Übertragung. Da ich mit vielen sich bewegenden Objekten gearbeitet habe, hat diese naive Implementierung einiges an Platz gespart.

@Nox guter Punkt

Derzeit versuche ich Entities vom Server mit den Clienten zu synchronisieren, da eine Entity aber ein komplexes Konstrukt aus Components ist frage ich mich was der beste Weg ist diese zu verschicken.

Meine Idee war jeder Entity eine ID zu verpassen und die Klassennamen der Component zu verschicken und diese dann vom Clienten zusammenbauen zu lassen.
So jetzt wirds tricky (benutzte Java) ich könnte jetzt über Reflection anhand der Klassennamen die Componenten erstellen... was noch fehlt sind jetzt die Parameter der Componenten (TransformC., VelocityC., usw.). Ich glaube das wird alles sehr komplex.
Deswegen ein anderer Ansatz, die Componets komplett verschicken und nicht nur primitive Datentypen.

Beispiel :


Wenn ich jetzt natürlich ein "Buch" voller Entities verschicken möchte müssen diese natürlich noch in eine Liste verpackt werden und in festen Zeitintervallen verschickt werden.

Welchen Ansatz würdet ihr verfolgen, oder habt ihr vielleicht schon gute Erfahrung mit anderen Vorgehen gemacht?
Ich würde mich über nützliche Hinweise freuen

Beste Grüße,
Jar

Im Zweifelsfall kann man jederzeit mal spicken gehen, wie es andere so machen. Denn nicht jeder Ansatz ist in jeder Sprache gleich geschickt. Recht beliebt ist z.B. die Verwendung von protocol buffers.
Bezüglich Aktualisierunglogik gilt wie sooft: Es gibt keinen Königsweg, aber soviel wie nötig und so wenig wie möglich ist meist nicht schlecht. Wenn man aber ein kleinen Sidescroller hat, kann man ruhig verschwenderisch sein. Wenn es um gigantische MMOs geht, wird typischerweise eine Sichtbarkeitsprüfung durchgeführt und auf Serverseite geprüft welche Elemente einem Client noch fehlen oder aktualisiert werden müssen. Diese Aktualisierungen werden dann zusammengepackt (z.B. protocol buffers) und übermittelt.
Aber je mehr implizites Wissen man verwendet, umso anfälliger wird das System (z.B. gegen Fehler in der Sichtbarkeitsprüfung des Servers).
Ich hoffe das waren so grob die erhofften Antworten auf deine Fragen.

Hast du schonmal darüber nachgedacht, nicht einfach "beliebige Entities mit irgendwelchen Komponenten" zu synchronisieren, sondern genau die, die bei dir vorkommen und relevant sind? (Oder eher: Willst du eine Engine oder ein Spiel schreiben?)
Bedenke, dass manche Werte (bspw. die aktuelle Geschwindigkeit) sich, je nach Spiel, aus anderen Werten (Anfang der Bewegung, Startposition, Zielposition) berechnen lassen könnten. Die berechneten Werte sind zwar den entsprechenden Komponenten zugewiesen, können bei der Synchronisation aber außen vor gelassen werden.

Was das Beste ist, kommt auch auf das Spiel an.
Rein rundenbasierte Spiele (bspw. Kartenspiele, rundenbasierte Stretegie- oder Rollenspiele, ...) sollten kein Problem darstellen.
Bei Spielen, die relativ wenig Spielerinput auszuwerten haben (bspw. Echtzeit-Aufbauspiele, wie die Anno Reihe) und eine Verzögerung durch im Spiel vorhandene Verzögerungen (Bauanimationen) kaschieren können (oder diese für die Gegenspieler nicht weiter relevant sind), sollte ein Verschicken von Nachrichten bei Eintreffen der Ereignisse (Gebäudebau beauftragt, Gebäude abgerissen, Fahrzeug auf (Handels-)Route geschickt, ...) ausreichen.

Bspw. bei einem FPS wird das nur bei wenigen Teilen des Spiels in der Form möglich sein, allerdings hast du auch nicht geschrieben, was dein Spiel sein soll.