Hi Leute!
In den letzen Tage habe ich ein wenig über neue Projekte / Ideen, usw. nachgedacht und ppane momentan so quasie ein neues Projekt, welches ich nach dem Abi gerne beginnen würde. Nun bin ich aber leider auf einen recht großen Stolperstein getroffen, den ich als einziges noch nicht beheben konnte: Wie gestallte ich die Interaktion einzelner Spieler untereinander. Zum Spielprinzip sei an sich nur vorweg zu sagen, dass der Code im groben den Ansprüchen eines 3D-Shooters genügen muss.
Das elend fängt bereits bei der Auswahl des Netzwerkmoduses an:
Soll ich TCP/IP, UDP oder IPX verwenden? IPX habe ich recht schnell ausgeschlossen, weil auf vielen Rechnern dieses Standartgemäß nicht installiert ist und mein Spiel als Zielgruppe eher die Gruppe der Hobbyzocker hat. UDP hat meines erachtens nach einen ziemlichen Vorteil: Es ist sehr schnell. Gleichzeitig aber auch einen Nachteil: Niemand garantiert mir, dass die Packete bei hohen Lasten auch ankommen. Deshalb konnte ich mich noch nicht wirklich zwischen UDP und TCP entscheiden, denn je mehr Packete mit "unwichtigen" Informationen übertragen werden, umso weniger wild ist es, wenn eines verlohren geht. Auf der anderen Seite will man aber ja den Code möglichst Bandbreitenschonen gestalten, so dass die Gewichtung eines einzelnen Packetes zunimmt, was wieder eher für TCP sprechen würde, wennn es denn nicht so langsam wäre.

Weiter geht es denn auch schon mit der Physik: Wer rechnet was?
Lasse ich die Physik komplett auf dem Server berechnen, dann übertragen die Clienten nur ihre aktuellen Kommandos an den Server (z.b. "Drehe Links, Laufe Vorwärts, Schieße in dem und dem Winkel irgendwa sab" .... das alles natürlicha nders Kodiert, also nicht als String ^^) und der Server sendet denn alle Ereignisse zurück bzw. denn auch die Positionen der Spieler. Das hat dne Vorteil, dass alle diegleichen Daten haben, denn nur einer rechnet. Problematisch nur, dass denn wenn ein Spieler eine hohe Ping (so um 100 von mir aus ... ich bin ISDN-Nutzer ^^) hat, den wird er den Lag schon deutlich merken, denn seine ganzen Befehle würden bei sich selber ja auch erst 200 ms später umgesetzt!
Um das zu reduzieren, könnte man einbauen, dass dabei diese Kommandos auch an jeden Clienten übertragen werden, um optische Lags zu reduzieren, meint: die müssen auch mitrechnen #, die entgültigen Positionen hingegen hat der Server nur. Nachteil wäre dann, dass bei hohen Pinks und schnellen Bewegungen beim Client so kleinere Ruckler auftreten könnten, wenn der Server etwas anderes errechnet hat als deder Client. Das könnte auftreten, z.b. wenn der Lag sich ändert. Beispielsweise bei einem Lag von 100 wird das Komando "laufe vorwärts" gesendet. Denn kurz darauf sendet der Spieler "bleibe stehen"... nur hat sich der Lag zwischendurch aus irgendwlechen Gründne auf 150 erhöht, denn läuft auf dme Server der Spieler wohlmöglich 50 ms länger als auf dem Clienten.
Ähnliches Problem ergibt sich auch beim Schießen: wer grantiertt dem Spieler, dass der Gegner echt da steht wo er auftaucht bei ihm und nicht, dass Aufgrung von Lags die Position falsch Extrapoliert wurde?

Ähnliche Probleme treten auch auf, wenn die Clienten alles berechnen ... besonders was das Schießen angeht wird das sehr interissant, wenn der Spieler auf wen schießt, der sich Schnell bewegt: in seiner Optik trifft er ihn, aber ob aufgrung des Lags beia nderen das derselbe fall sein wird ist fraglich.

Naja, ich denke ich versteht meine Problemtaik ud warum ich einfach nicht zu einem Ergebniss komme ... Ich könnte hier noch viel mehr fragen aufstellen, wie z.b. wieviel Bandbreite minimal zur Positionsübermittlung sinnvoll wäre, usw, aber das Problem ist momentan eher Sekundär bzw. das hier würde einfach zu lang werden.
Nun wollte ich die "Cracks" unter uns einfach mal fragen, wie ihr in euren bislangigen Projekten die Netzwerk & Internetproblemtaik gelößt habt, bzw. wie ihr die lösen würdet.

_________________
Es sind immer die guten,
welche zu früh von uns gehen müssen...
Meine bislang 13 Open Gl - Tuts findet ihr auf www.dcw-group.net
Neu! Ein großer Teil der Demos nach Kylix übersetzt!

Die Frage des Protokolls lässt sich nicht sehr einfach beantworten. TCP besitzt den Vorteil, dass garantiert ist, dass alle Pakete ankommen.
UDP hingegen garantiert weder ob das Paket ankommt, noch ob die Pakete in der richtigen Reihenfolge ankommen. Der Vorteil von UDP liegt in der Geschwindigkeit. TCP besitzt gegenüber UDP zusätzlich noch den wesentlichen Nachteil, dass ein Paket immer und immer wieder gesendet wird, bis der andere Socket es empfangen hat. Jeder wird sich fragen wo hier das Problem liegt. Während das eine Paket immer wieder gesendet werden muss stehen die anderen Pakete in der Warteschlange. Wichtige Informationen, die mitunter gar nichts mit dem anderen Paket zu tun haben müssen so warten und das führt zu Lags.
UDP besitzt hingen noch den Nachteil, dass du beispielsweise nie weißt, wann die Verbindung getrennt wurde. Hier müsstest du ein eigenes Protokoll auf das UDP-Protokoll aufsetzen.

Im Internet liest man häufig, dass nach vielen Tests mit TCP zwangsweise auf UDP umgestiegen wurde, da die von mir oben beschriebenen Lags zu häufig aufgetreten sind. Oftmals liest man aber auch, dass TCP im LAN gut verwendbar ist, da der Paketverlust hier in der Regel verschwindend gering ist.
Die Entwicklung mit TCP ist jedoch wesentlich leichter. Schließlich ist es nicht ganz leicht herauszufinden, welches Paket von welchem abhängig ist und ob ein Paket vielleicht schon verarbeitet werden kann, obgleich das vorherige Paket verloren gegangen ist.
Welches Protokoll du jedoch am Ende wählst ist dir überlassen.

Was die Bestimmung der Position und anderer wesentlichen Eigenschaften der Akteure angeht so empfehle ich dir das Abbild der Szene des Clients und des Servers zu speichern und die benötigten Werte zu interpolieren und anzupassen. So kannst du Physik auf Client und Server berechnen und wenn es Unterschiede in den Ergebnissen gibt so kannst du die Informationen des Clients allmählich an die Informationen des Servers anpassen ohne dass diese Änderungen dem User all zu sehr auffallen (etwa durch ein Springen bei der Korrektur der Position). Definitiv muss der Server aber alle Änderungen abnicken, wenn dein Spiel synchron laufen soll (ich versichere dir: das ist die größte Schwierigkeit).

_________________
Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jederman ist überzeugt, dass er genug davon habe.
Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650

Hmm .. du meinst also, dass man das quasie so machen sollte, dass jeder Client sollte selbver rechnen, aber vom Server sollten halt permanent "absolute" Daten kommen, anhand welcher die Clienten sychronisiert werden? An sich keine üble Idee ... so in etwa habe ich mir das auch gedacht. Die frage ist was für Pings diese Methode maximal abfangen kann ... aber ich denke mit nem ISDN-Ping von 100 sollte es gehen hoffe ich ^^

Die Frage nach dem Protokol ist so eine Sache: Wenn ich was eignes mit Kontroll-Mechnismen auf UDP-Basis aufbaue, dann wird das kaum besser als TCP/Ip, denn dann müsste diese Kontroll-Mechnaismuss ja auchpermanent Packete wiederholen solange, bis ein Bestätigungs-Signal kommt, dass es angekommen ist... das wäre nicht nur Langsam, sondern frisst doch auch Bandbreite ohne Ende... Wegen den Abhägigkeiten will ich versuchen möglichst kaum welche Auftreten zu lassen ... bei Positionsangaben oder solch Dingen wie "Schuss in die und die Richtung" geht das auch sicherlich ... bei allen anderen Dingen wie "laufe vorwärts" muss natürlich irgendwie auch denn irgendwann ein "laufe nicht mehr vorwärts" kommen ... das wird per UDP denn schon etwas unglücklich, denn was, wenn der Befehl nicht kommt?
Das einzige, was mir dazu einfällt wäre evtl. dass man irgendwie den Ping misst und denn der Client guckt, ob innerhlab der Ping-Time plus ein wenig Sicherheitsvarianz der eigene Befehl zurückkommt, denn der muss ja an alle Clienten wieder gesendet werden. Wenn nicht, denn muss man sehen, ob man denn erneut den Befehl sendet (sehr langsam) oder ob man die neue Abselute Position an den Serve rüberträgt --> Springen bei allen anderen...

Och menno .... am liuebsten wäre es mir gar keine Packete gingen verlohren ^^
Hat sonst noch wer eine Lösung für ein solches Problem?

_________________
Es sind immer die guten,
welche zu früh von uns gehen müssen...
Meine bislang 13 Open Gl - Tuts findet ihr auf www.dcw-group.net
Neu! Ein großer Teil der Demos nach Kylix übersetzt!

Du musst ein eigenes Protokoll auf das UDP-Protokoll aufsetzen. Damit musst du garantieren, dass alle Pakete tatsächlich ankommen. Zusätzlich kannst Ereignisse wie OnDisconnect mit Hilfe eines eigenen Pingsystems basteln. Damit bekommst du auch gleich noch ziemlich effektiv deinen Ping. Sicher musst du Pakete mehrfach senden aber bei TCP ist das doch nicht anders. Damit kannst du jedoch sicherstellen, dass du auch die Pakete verarbeiten kannst, die nach einem verlorenen Paket abgeschickt wurden. Damit veralten die Pakete nicht so wie bei TCP während du auf das verlorene Paket wartest.

Wichtig bei UDP ist noch, dass die gesendeten Pakete nicht zu klein sein sollten. Ich glaube einmal gelesen zu haben, dass der UDP-Header nicht so gut komprimiert werden kann wie der TCP-Header.

_________________
Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jederman ist überzeugt, dass er genug davon habe.
Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650

Hmm... also ich würde das mit dem Senden von Befehlen mal lassen und stattdessen immer nur die aktuelle Position, Richtung und Geschwindigkeit senden. So kannst du z.B. in der Zeit bis ein neues Paket eintrifft den Spieler in die letzte bekannte Richtung weiterlaufen lassen. Außerdem würde ich noch eine Art "Gamestate" mitschicken.
Was ich meine ist Folgendes:
Der Server ist so lange in einem "State" (ein einfacher Integer reicht dafür), bis er von allen Clients die Informationen des gleichen States empfangen und weitergesendet hat. Dan wird dieser Zähler inkrementiert und der Server wartet wieder bis er die Informationen der Clients empfangen hat und weitersenden kann. Für den Fall das ein Paket verlorengeht musst du eine maximale Zeit bestimmen die der Server wartet bis er diesen Verlust ignoriert und die Daten abschickt. Letzteres kann man sicher über den durchschnittlichen Ping dynamisch berechnen, aber ich denke das 250 - 500 ms mal ein ganz guter Anfang für einen Shooter wären.
Achja: das ganze müsste natürlich über UDP laufen.

Ich hab zwar nicht die meiste Ahnung davon, aber das hier könnte für dich interessant werden:

http://www.bookofhook.com/Article/GameD ... Model.html

Die Physik würde ich so weit wie möglich auf den Clients lassen. Die haben eh nichts zu tun. Der Server soll nur checken, ob 2 Spieler ineinander gelaufen/gefahren/geflogen/geschwommen/... sind oder ob der eine den anderen erwischt hat. Denn dann kann man auch mit nem Ping von 10 Minuten noch flüssig durch die gegen laufen.


Deshalb benutze ich in Battlefield auch (fast) nur Granaten. Alles andere geht mit nem Ping von über 300 nicht mehr...
Aber es ist mir lieber, ich ziele bei den Flugzeugen ne halbe Sekunde vor den Gegner, als dass ich ne halbe Sekunde zu spät hochziehe und gegen ein Gebäude knalle, weil die Physik auf dem Server schon weiter ist.


Ansonsten empfehle ich dir einfach mal 2 PCs zu vernetzen (falls das noch nicht der Fall ist) und mit Winsocks oder Indy ein wenig rumzuspielen (Für Winsocks, vor allem mit nichtblockenden Sockets, würde ich vieeel Zeit einplanen). 2 Autos die durch die Gegend Fahren reichen zum Testen eigentlich aus. Dann sieht man sehr schnell was geht, und was überhaupt nicht läuft.