spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Entkoppeln fände ich für diesen Fall sogar sinnvoll, da ich nämlich der von Dir dargestellten Meinung von Nox bin und nicht viel Potential für andere Protokolle sehe, so lange ich an richtige Reihenfolge und garantiertes Eintreffen der Daten gebunden bin. Ist klar, dass UDP sinnvoll ist, wenn diese Anforderung nicht besteht. Gerade bei einem Brettspiel wäre es aber schon wichtig, ob Weiß zweimal zieht und dann schwarz dreimal oder doch jeder abwechselnd. Wahlweise wären ausgelassene Züge eher uncool. Es mag bei so einem Spiel sicher auch nicht zeitkritisch sein, aber den reinen Zeit-Faktor als Zeichen dafür zu nehmen, dass man da ruhig TCP verwenden kann (und ansonsten scheinbar was anderes braucht!?), scheint mir nicht ganz schlüssig. Wohl auch deswegen, weil selbst zeitkritische Spiele noch immer davon abhängen, dass der Determinismus von der Reihenfolge und Vollständigkeit der Netzwerkdaten abhängt.

Aber ich würde dazu auch gern erstmal von David genauer wissen, wie er diese Aussage genau gemeint hat.

Auch wenn es ein wenig OT ist:
wenn gefordert ist, dass alle Pakete ankommen und die Droprate für die Pakete nicht all zu hoch ist (kann z.B. bei schlechten WLan Empfang nicht erfüllt sein), dann sind die von mir getesteten UDP libs meistens sowohl von der Latenz als auf von der Effektivität der Bandbreitenausnutzung sogar eher schlechter als TCP (Krasses Beispiel war raknet, welches in den von mir getestete Versionen die Senderate bei zu hohen Verlusten auf fast null setze, was bei einer "schlechten" Leitung zu einem ständigen Spiken der Übertragungsrate führte). Wenn nat die Reliability kein Kriterium ist haben UDP-Lösungen schnell mal die Nase vorne. Allerdings ist das ein Thema was viele Wechselwirkungen aufweist, so dass meiner Meinung nach das praktische Vergleichen per Tests der Theorie vorgezogen werden sollte.
Fazit für diesen Anwendungsfall: ich bin Davids Meinung; Nimm TCP, wenn du keine fertige, gescheite Lib findest.

Noch ein Tipp: Prinzipiell gibt es zwei Arten ein Netzwerkspiel umzusetzen. Bei der ersten werden nur Befehle wie "setze Figur X an Pos Y", "Figur X führt Aktion Z aus" ausgetauscht. Dies kann dann sogar ohne eindeutigen Server also per P2P Ansatz durchgeführt werden. Allerdings ist es garnicht so ohne die Synchronität zu bewahren. Für deinen Fall würde ich dir eher dazu raten, einfach Spielstände zu übermitteln. Sprich die Clients schicken Nachrichten ans den Server, was sie gerne tun möchten, dieser überprüft sie und setzt sie um. Danach wird der Spielstand vom Server auf die Clients verteilt (das ist das was auch Syncsys für C++/python stark automatisiert). Sprich im Endeffekt musst du nur einen Weg finden, alle Objekte zu serialisieren und auf der anderen Seite wieder zu deserialisieren. Da es sich um ein Brettspiel mit einer festen Anzahl von Spielern handeln würde, sollte dies recht einfach gehen. Kompliziert wird es wenn Objekte/Instanzen im Spielverlauf erstellt und zerstört werden müssen, daher solltest du das möglichst vermeiden. Allgemein ist es üblich jedem Objekt, welches übers Netzwerk synchronisiert werden soll eine ID (Serveraufgabe) zu zu weisen.

Zitat von »BlueCobold«

David, sollte er sonst für ein Zeit-kritisches Spiel etwa UDP verwenden? Wenn ja, wie wird das Problem der fehlenden Pakete und der richtigen Reihenfolge dann gelöst und wie bekommt man trotz dieses Nachbaus dann noch immer mehr Performance als direkt TCP zu nutzen? Oder hab' ich Dich einfach nur falsch verstanden?

Wenn man TCP verwendet und ein Packet mal wirklich nicht ankommt, kommen für eine ganze Zeit garkeine Packete an. Das kann bis zu ein paar Sekunden dauern und das ist die größte Schwachstelle von TCP. Wenn man sich das nicht leisten kann und es nicht so schlimm ist, wenn ein Packet mal nicht ankommt muss man UDP verwenden. Ausserdem kann man Packete, mehrfach schicken. Das ist bei TCP nicht sinnvoll.
Es gibt auch noch die Möglichkeit beides zu verwenden(was ich im moment in meiner Netzwerkanwendung auch mach), aber ich habe gelesen, dass das TCP Protokoll das UDP Protokoll behindern kann. Das klingt für mich zwar unlogisch, aber ich werd das mal überprüfen.

Für ein Brettspiel würd ich allerdings auch nur TCP verwenden. Wenn ein Packet mal nicht ankommt wartet man halt kurz. Das würden die Spieler vermutlich garnicht bemerken. Höchstens wenn man in dem Spiel möglichst schnell seine Züge machen muss.

Ist nicht unlogisch, da TCP-Pakete nicht selten eine höhere Priorität bei entsprechenden Knotenpunkten haben und daher seltener rausfliegen (soweit ich weiß). Außerdem ist das erneute versenden eher eine Einstellungssache. Viel problematischer für Spiele ist das Nagle-Ack Problem, aber auch das ist nur eine kleine Einstellung.

Zitat von »Nox«

Noch ein Tipp: Prinzipiell gibt es zwei Arten ein Netzwerkspiel umzusetzen. Bei der ersten werden nur Befehle wie "setze Figur X an Pos Y", "Figur X führt Aktion Z aus" ausgetauscht. Dies kann dann sogar ohne eindeutigen Server also per P2P Ansatz durchgeführt werden. Allerdings ist es garnicht so ohne die Synchronität zu bewahren. Für deinen Fall würde ich dir eher dazu raten, einfach Spielstände zu übermitteln. Sprich die Clients schicken Nachrichten ans den Server, was sie gerne tun möchten, dieser überprüft sie und setzt sie um. Danach wird der Spielstand vom Server auf die Clients verteilt (das ist das was auch Syncsys für C++/python stark automatisiert). Sprich im Endeffekt musst du nur einen Weg finden, alle Objekte zu serialisieren und auf der anderen Seite wieder zu deserialisieren. Da es sich um ein Brettspiel mit einer festen Anzahl von Spielern handeln würde, sollte dies recht einfach gehen. Kompliziert wird es wenn Objekte/Instanzen im Spielverlauf erstellt und zerstört werden müssen, daher solltest du das möglichst vermeiden. Allgemein ist es üblich jedem Objekt, welches übers Netzwerk synchronisiert werden soll eine ID (Serveraufgabe) zu zu weisen.

das sollte durchaus Beachtung finden, allerdings sollte man ebenfalls schauen, ob man dafür nicht vorgefertigte Mittel verwenden kann
unter Java gibt es beispielsweise RMI (Remote Method Invocation), welches sich sehr einfach verwenden lässt und dadurch gut für diesen Anwendungsfall geeignet ist
während dabei auf der einen Seite mit den richtigen Objekten gearbeitet wird, wird auf der anderen Seite mit Proxys gearbeitet, die Methodenaufrufe in Netzwerknachrichten umwandeln

Das reicht bei nachrichten basierten Ansätzen, da es da auf sehr präzise Gleichzeitigkeit ankommt. Dass ist bei einem Runden/Zugbasierten System einfacher zu erreichen, aber dennoch kritisch. Das Problem ist bei einem Synchronisiation unkritischer und eig nur noch ein Kosmetikproblem (Sprünge etc falls falsche Vorhersage).

Wenn das ganze mit Server laufen kann/soll, wäre wohl Flash die zugänglichste Lösung. P2P mit Flash ist leider nur relativ umständlich mit Vermittlungsserver möglich. Da gibt es zwar auch eine Open Source Variante, aber die steht unter GPL und inwieweit der einsetzbar ist, weiß ich nicht.
An deiner Stelle würde ich Java nutzen. Für 2D Grafik ist zum Beispiel Slick gut geeignet. Für das Netzwerkzeug würde sich in deinem Fall wahrscheinlich http://code.google.com/p/kryonet sehr gut eignen. Das verfügt über ein einfaches schnelles Objekt-Serialisierungs-Framework (Kryo) und bietet sowohl UDP als auch TCP als zugrunde liegendes Protokoll an. Außerdem ist da auch noch ein recht praktisches RMI System dabei. Man muss bei Kryo einfach nur Klassen "registrieren" und schon kann man Objekte dieser Klassen effizient über Netzwerk verschicken. Ebenso ist es möglich Objekte unter einer ID zu registrieren und schon kann man Funktionen dieses Objektes von anderen Systemen aufrufen.

Zitat von »Jorik«

Eignet sich Flash nicht sogar recht gut für diese Art Spiel? Habe da auch schon einige Multiplayer spiele gesehen in der Richtung.

Die Zeit, die mir zur Verfügung steht ist relativ Knapp bemessen, etwa 2 Monate.

An sich ist Flash gut für kleine Spieleprojekte geeignet, das stimmt. Wenn aber Multiplayer dazu kommt, kommst du um eine 2. Sprache kaum herum, da du irgendwie einen Server brauchst, über den alles läuft.
(ein Flashspiel selber kann nicht als Server fungieren, außer du machst ein Adobe-AIR-Projekt, dann brauchst du aber noch Erfahrung in MXML) Zum Beispiel mit BlazeDS / Java.
Wenn du dich mit Java auch gut auskennst, ist das dann die bessere Wahl das Spiel komplett damit zu machen, dann sollteste du dir nur eine einfach zu benutzende Bibliothek für das Grafische raussuchen und fürs Netzwerk.

Edit:@Chromanoid: Mist, du warst schneller

Zitat von »Chromanoid«

Man muss bei Kryo einfach nur Klassen "registrieren" und schon kann man Objekte dieser Klassen effizient über Netzwerk verschicken. Ebenso ist es möglich Objekte unter einer ID zu registrieren und schon kann man Funktionen dieses Objektes von anderen Systemen aufrufen.

bei der Variante, die jede JavaSE Laufzeitumgebung mitliefert muss man Objekte registrieren
werden dabei tatsächlich ganze Objekte verschickt? wie werden deren (redundanten) Daten vor Inkonsistenzen bewahrt?
welche Vorteile bietet es im Gegensatz zu anderen Lösungen? (wie beispielsweise der bereits vorhandenen)

Naja Kryo ist einfach wesentlich leichtgewichtiger. Java RMI benutzt außerdem die Java Serialisierung für Rückgabewerte/Parameter. Das "Problem" bei dieser Serialisierung ist, dass für Objekte auch immer die Klasse als String übermittelt wird und auch sonst nicht besonders platzsparend gearbeitet wird. Java RMI sollte mit dem ganzen Architekturkram der sich darum rankt insgesamt einfach etwas komplizierter sein. Schließlich muss man bei jedem Objekt auch Remote als Schnittstelle einbinden usw... Kryo ist leichtgewichtig und auf Spiele ausgelegt.

Bei Java RMI werden lokale Objekte serialisiert verschickt und Remote-Objekte als Referenz übergeben. Ich bin mir nichts sicher ob Kryo auch Remote-Objekt Referenzen zurückgibt, aber bei Spielen sollte sowas eigentlich auch nicht nötig sein. Die Sicherstellung der Konsistenz bleibt zumindest bei Kryo dem Entwickler überlassen. Aber wenn die konsistent zu haltenden Objekte nur einmal existieren und von entfernten Komponenten nur über die RMI-Schnittstelle angesprochen werden, dann sollte es eigentlich zu keinen Konsistenzproblemen kommen. Kryo bastelt aus angegebenen Interfaces ein Proxy-Objekt, das dann Aufrufe an das entfernte Objekt weiterleitet. So in der Art macht das sicher auch Java RMI nur eben mit etwas mehr drumherum.

Hier ein interessanter Benchmark für unterschiedliche Serialisierungs-Frameworks: http://code.google.com/p/thrift-protobuf…ki/Benchmarking
Das Ding an der Spitze "Java (externalizable)" ist dabei das in Java eingebaute erweiterte Serialisierungsframework, das aber ein manuell programmiertes schreiben und lesen der Daten erfordert.