spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Willkommen im Forum!

Das ist tatsächlich ein sehr komplexes Thema. Ich gebe dir einfach mal einen Link zu einer Seite, wo du sehr viele Artikel zu diesen Themen findest:

http://gafferongames.com/networking-for-game-programmers/
und http://gafferongames.com/game-physics/networked-physics/

Nachtrag: Insbesondere dieser Artikel sollte interessant sein, da er einen Überblick gibt.

Witzigerweise beschäftige ich mich gerade mit genau dem gleichem Thema:

Hier noch ein sehr wichtiger Link:
http://gafferongames.com/networking-for-…ame-networking/
http://gamedevelopment.tutsplus.com/arti…n--gamedev-3849

Wenn hier eine Antwort gefunden wird würde ich mich sehr freuen.

Mein Ansatz ist bisher eine Server Client Architektur, wobei der Server und der Client beide Bewegungsbeschreibungen anstoßen und diese von Zeit zu Zeit synchronisieren.
Die Berechnung von anderen Objekten die nicht dein Spieler sind finden dabei nur Serverseitig statt. Und immer wenn dein Spieler in Kontakt mit genau solchen Objekten kommt (Sichtfeld oder Collision) sollten Informationen übertragen werden. Denn dein Sichtfeld ist begrenzt und dementsprechend brauchst du keine Informationen über Objekte die am anderen Ende der Welt sind. Genauso brauchst du keine Informationen senden von Objekten die Ihren Zustand nicht geändert haben, oder ändern können.

Zitat von »Sneyke«

Gibt es da große Unterschiede zwischen sehr Zeitkritischen Spielen wie ein FPS und einem Halbrunden-basiertem RPG? Ist es ausschlaggebend ober ob Peer-tp-Peer übertragen wird oder eine Client-Server-Architektur verwendet wird?

Ja, aber das ist besser in den gelinkten Artikeln beschrieben. Man kann auch alles über den FPS Ansatz regeln, könnte aber mehr Aufwand bedeuten.

Meine Ansätze sind alle noch recht theoretisch, beschäftige mich erst seid ein paar Tagen mit der Umsetzung einer Server Client Lösung für mein Game.

Edit: David hat einen der Links bereits nachgetragen

Ansonsten gibt es in diesem Forum auch schon ein paar Diskussionen zu dem Thema (P2P vs. Server Client und Ereignisse- vs. Zuständeübertragung). Netzwerkprogrammierung ist an sich ein sehr spannendes, aber auch sehr zeitinvensives Thema. Wenn euer Interesse eher in Richtung funktionierende Implementierung geht, dann würde ich eher zur Verwendung einer etablierten Bibliothek raten.

Wo ich gerade Java lese, ich benutzte KryoNet und diese ist relativ schlank und bietet TCP und UDP support: https://github.com/EsotericSoftware/kryonet.
Zusätzlich gibt es dazu ein sehr gutes Einsteiger Tutorial: https://www.youtube.com/watch?v=nS8WfLS1…bekLlncne3BiESN

Ich glaube in einem der Artikel auf der verlinkten Seite wird auch zu TCP und MMOs bzw WoW eingegangen, also warum es dort funktionieren kann. Aber dort auch wieder das Stichwort: Client Side Prediction

@Sneyke es kommt darauf an was dein Netzwerkmodell voraussetzt. Es gibt z.b. das Quake(?) Konzept in dem immer die Veränderung zum letzten von Client bestätigten Zustand verschickt wird. Sprich das Konzept ist nicht darauf angewiesen, dass jedes Paket ankommt. Nun sind aber viele Konzepte implizit darauf angewiesen, dass die Pakete ankommen und oft wird auch angenommen, dass sie in der richtigen Reihenfolge ankommen (z.b. Gegner 1 stirbt, Gegner 1 schießt ist was ganz anderes als Gegner 1 schießt, Gegner 1 stirbt).
Was also viele machen ist zunächst auf UDP bauen weil es ja "schneller" ist. Dann stellen sie fest, dass sie "in order" und "reliable" benötigen und enden darin, dass sie übers UDP noch Logik stülpen um TCP Verhalten zu bekommen. Wer nun glaubt es selbst besser zu machen als der seit Jahren entwickelte TCP stack, kann das natürlich gerne tun. Zumindest haben alle UDP basierten Libs, die ich mal vor Jahren getestet habe, TCP nicht das Wasser reichen können, wenn es um seine Kernkompetenz ging (reliable & in order).
Mein Fazit: Unter idealen Voraussetzungen sind UDP und TCP gleich schnell. Sobald packet loses ins Spiel kommen und man damit leben kann, ist UDP eindeutig zu bevorzugen. Wenn man auf Reihenfolge und Komplettheit angewiesen ist, ist TCP im Vorteil. Und mal ganz ehrlich: beide basieren auf den gleichen OSI-Layern. Warum sollte es beides noch geben, wenn eines von beidem immer klar im Vorteil wäre?

Zitat von »Nox«

Mein Fazit: Unter idealen Voraussetzungen sind UDP und TCP gleich schnell. Sobald packet loses ins Spiel kommen und man damit leben kann, ist UDP eindeutig zu bevorzugen. Wenn man auf Reihenfolge und Komplettheit angewiesen ist, ist TCP im Vorteil. Und mal ganz ehrlich: beide basieren auf den gleichen OSI-Layern. Warum sollte es beides noch geben, wenn eines von beidem immer klar im Vorteil wäre?

Dazu würde ich mir http://gafferongames.com/networking-for-…ers/udp-vs-tcp/ mal durchlesen. Man sollte nie nur eines von beiden benutzten, eine Harmonie aus beiden ist der Weg zu Erfolg. Und wenn du das von mir angesprochene Verfahren (Client Side Prediction) anwendest kannst du auch mit UDP eine FPS programmieren.

Zitat

The temptation then is to use UDP for player input and state, and TCP for the reliable ordered data.