Simples Netzwerkspiel / Technik

Ich will mal ein kleines Netzwerkspiel coden, welches so ne Art Multiplayer-Snake werden soll. Ich bin mir jedoch nicht im Klaren wie ich das am besten anstelle.

Für die Netzwerkverbindungen dachte ich, dass ich nen TcpListener und NetworkStream verwende. Vom Ablauf her will ich es so machen, dass der Client die Richtungsänderungen zum Server schickt, dieser schickt diese an alle anderen Clients. Die Clients zeichnen also immer die Linien bis sie eine Richtungsänderung (+ dessen Position) vom Server bekommen. Ist dieser Ansatz überhaupt richtig, oder hau ich so voll daneben?

Zum Zeichnen der Linien wollte ich einfach ne Picturebox nehmen, in der ich im Paint Event einfach mit dem Graphics-Kontext (DrawLine etc.) zeichne. Blöde Idee?

Hallo Savage,

nee, die Richtungsänderungen schicken reicht nicht, weil es ja Zeitverzögerungen geben kann. Alle Clients brauchen denselben Stand. Wenn ein Client eine Richtungsänderung später empfängt, könnten aber unterschiedliche Stände entstehen.

Der Server muss also die zentrale Steuerung/Berechnung übernehmen und für jede Schlange immer die jeweils aktuelle Position an alle Clients durchgeben. Dann zeichnen alle Clients alle Schlangen an die richtige Position.

PictureBox dürfte für Snake voll ok sein. Das ist ja nicht performance-kritisch.

herbivore

ok gut, aber in welchen abständen soll ich die positionen schicken? alle 20ms? aber was passiert wenn ein lag inzwischen ist? außerdem würde es dann zu einem paketstau kommen wenn jemand zb mit isdn fahrt und nen ping von 70ms hat.

Bewegen sich die Schlangen nicht Sprungweise? (ist bei jeder Snake implementation so die ich kenne -> (verstecktes) Gitter)

Denn dann reicht es eigentlich für jeden Sprung den jeweiligen Sprung zu übertragen. Sprünge wirst du wohl kaum schneller als 10 Hz takten (-> alle 100 ms), sicher nicht schneller als 20 Hz (-> alle 50 ms). Falls du mit einem 'Server' arbeitest kannst du allenfalls auch gleich so synchronisieren (alle Clients senden ihren Sprünge an den Server, der sie dann regelmässig nach den 60-100 ms an alle zurücksendet. Was passiert wenn ein Client keinen Sprung geliefert hat kannst du selber entscheiden, z.b. einfach "geradeaus" annehmen, oder auch die Übertragung verzögern bis alle Daten da sind - dann "ruckelt" es einfach bei allen Teilnehmern ...

Der Echo Delay (Ping) hat übrigens i.a. wenig mit einem potentiellen Packetstau zu tun - so kannst du problemlos eine sehr hohe Datenrate z.b. über eine Satellitenverbindung mit einem grossen Delay fahren - bei UDP überhaupt kein Problem, bei TCP auch nicht sofern die ARQ-Fenster gross genug sind (ok, da brauchst dann natürlich etwas Cache..) ... aber der Delay wirkt sich natürlich direkt auf die höchstmögliche Taktfrequenz aus, ja ... (70 ms Delay -> 14 Hz maximum (je nach fairness bis 28 Hz) ... wobei sich aber natürlich die Übertragung eines ICMP Echo Datagramms von einem TCP Packet durchaus unterschieden kann)

danke für eure infos/hilfe...

ich habe es nun so gelöst: die clients schicken nur die richtungsänderungen (tastenanschläge) zum server, dieser schickt alle 10ms die positionen an alle clients. ... und des klappt wunderbar.
wenn ich beim client die zeit messe, dann bekommt dieser ca. alle 16ms neue positionen ... obwohl ich alle 10ms was schicke kommt es zu keinem packetstau, warum auch immer?
ich kann mich noch erinnern das ich sowas mal unter java versucht habe, jedoch damit nur probleme hatte weil logischerweise einfach zuviele pakete kamen.

Clientseitige (Treffer- und Bewegungs-) Berechnung ist bei Massive-Multi-User-Games durchaus verbreitet, hat aber auch einige Nachteile, die Herbi schon aufzählte. Die versucht man in diesen Games durch "Vorhersage" zu lösen. Klappt meist ganz gut, teilweise "warpen" die Figuren aber auch öfters (klappt gut bei Fahrzeugen, schlecht bei Fussvolk).

In kleinen Multi-User-Szenarios würd ich aber auch eine serverseitige Berechnung wählen. Entscheidend sind die Antwortzeiten, die der Server bietet. Irgendwann werden die zu groß und das Spiel wegen der Lags unspielbar. Gegen die Grenze rennt man bei Multi-User-Games irgendwann immer. Dann bleibt als letzte Rettung clientseitige Berechnung. Nicht umsonst sind die meisten Multi-User-Shooter auf 128 Spieler pro Arena begrenzt. Die arbeiten alle serverseitig. Echte Massive-Shooter (bis zu 10.000 Spieler oder mehr) sind ja recht selten.