Another Zombie Shooter(Neu)

[Artus]

Naja leider läuft es nicht so, wie wir uns das vorgestellt haben deswegen wird es ein Singleplayer Game bleiben! STARGATE und ich, versuchen trotzdem das UDP Netzwerk auszubauen und es in einem Minigame unterzubringen.

Anbei das Symbol/Logo/Titel meines neuen Games^^ einfach und schlicht, aber wie ich finde wirksam


(c)2009 Arthur Studio ^^

MfG Arthur

[Milchshake]

@Artus
wenn ich fragen darf, was genau läuft nicht richtig?
Es interessiert mich einfach^^

[Artus]

Es ist so:
Entweder läufts flüssig und hat ne verzögerung von 2-3 Sekunden, ODER es Ruckelt und dafür gibt es so gut wie keine verzögerung -.-

MfG

[STARGÅTE]

naja Arthus übertreibt n bisschen ^^

aber wir befinden uns in einer Zwickmühle wie er schon beschrieb.

Würden wir im dauerfeuer Positionsdaten übermitteln, so ist der verzögerung praktisch Null, bis auf die verbindungsquallität (PING)
Jedoch hat UDP es nun mal ansich (weil es halt einfach drauf los sendet, ohne weitere prüfungen wie bei TCP) das es durchaus mal eine 1 2 3 als 1 3 2 ankommt, und es dadurch zu rucklern kommt.

Also müssen wir dem entgegen wirken indem wir einen kleinen eigenen Sammelbuffer einrichten, der die Positionsdaten ca 150ms lang sammelt um dann noch mögliche verschiebungen zu ordnen.
Damit wäre dann die Bewegung an sich nahezu flüssig, jedoch um 150ms verzögert.
Bei einem solchen Spiel sind dann jedoch +PING die insgesamt ca 300ms verzögerung zu viel, weil dann die Mitspieler kaum noch den Gegner treffen ...

Wenn man einfach nur n Multiplayergame haben will, ist die derzeitige Lösung wahrscheinlich ausreichend ... aber es ist eben nicht "gut genug"

Artus und ich wollen nun also mein Test-Multiplayer wo zur Zeit ein Kreis durch die gegend läuft zu einem mini Panzer-Spiel bauen... wo wie dann bis aufs Limit testen können ...

[cxAlex]

Würden wir im dauerfeuer Positionsdaten übermitteln, so ist der verzögerung praktisch Null, bis auf die verbindungsquallität (PING)
Jedoch hat UDP es nun mal ansich (weil es halt einfach drauf los sendet, ohne weitere prüfungen wie bei TCP) das es durchaus mal eine 1 2 3 als 1 3 2 ankommt, und es dadurch zu rucklern kommt.

Also müssen wir dem entgegen wirken indem wir einen kleinen eigenen Sammelbuffer einrichten, der die Positionsdaten ca 150ms lang sammelt um dann noch mögliche verschiebungen zu ordnen.
Damit wäre dann die Bewegung an sich nahezu flüssig, jedoch um 150ms verzögert.

Probierts mal so: Jedes UPD Packet hat eine vortlaufende Nummer (1,2,3,....4567,.....,4574,....,34666,......) Der Empfänger speichert immer die Nummer des letzen Packtes zwischen.Kommt nun eine Nummer mit einen geringeren Wert als der letzte gespeicherte wird das Packet einfach ignoriert.

Also wenn 1,3,2,4,5,6,9,8,7,10 kommt werden eben nur 1,2,4,5,6,9,10 gewertet. Da du sowiso dauerfeuerst sollten diese fehlenden Packete keinen Ruckler/Sprünge verursachen. Einfach mal probieren, sollte ganz gut klappen.Wenn ihr als Zähler nen Quad nehmt solltet ihr theoretisch 106751991167 Packete / ms senden können um 24 Stunden durchzuspielen ohne den Zähler zu überschlagen .

[STARGÅTE]

@cxAlex

Hatten wir schon gemacht, aber genau dieses 1,2,4,5,6,9,10 hatte dann zwar keine "rückspünge mehr" aber diese Fehlenden "Stichpunkte" sah man schon deutlich ...

Im übrigen verwende ich zur Zeit nicht reine Nummern, sondern die Zeit in ms. Somit bin ich volkommen davon unabhängig wie schnell oder langsam und in welche Reihenfolge die daten ankommen, da 1ms ja überall 1ms ist.

Die Sendefrequenz ist zur Zeit 20Hz (alle 50ms) damit buffer ich jedoch alle Positionsänderungen (bei 80FPS also 4) zwischen und sende dnan also n Viererpaket (das entlasten das Netz). Auf der andere Seite wird dann die Position dann "angewand" wenn der Zeitpunkt stimmt.

[PMV]

Ihr dürft nicht nur Positionsdaten verwenden sondern zusätzlich die
Bewegungsrichtgung und Geschwindigkeiten. Und was hat es für einen
Sinn, 4 Pakete zu puffern und zu senden? Interessant ist nur das
aktuellste Paket, also das letzte und genau das muss gesendet werden.
Richtig flüssig kann es im übrigen nur laufen, wenn ihr einen vernünftigen
Ping habt, darauf solltet ihr achten. Wenn einer von euch grundsetzlich
Probleme macht kann das Ergebnis nicht stimmen

MFG PMV

[STARGÅTE]

@PMV

Auch das haben wir schon probiert, aber das sah noch grauenhafter aus, denn:

Wenn ich meine Bewegungsdaten sende (zB Position und Geschwindigkeitsvektor) und der andere Client dann meine Position "versucht" vortzuführen, dann geht das in 90% der Fälle in die Hose, weil dkurz nach der Übertragung ich meine bewegung verändert habe und der andere Client nun falsch vorrausdenkt, bzw der andere Client vllt kurz mal schneller rechnet und ich dann schon in der Wand bin ...

... Aber mir fällt gerade noch eine Möglichkeit ein die ich noch nicht probiert habe:
Eine Approximierung meiner Positionsdaten auf der anderen Seite, Idee:
Ich seine (1,0) und nach 20ms (2,0) auf der Andere Seite bekomme ich dann zuerst (1,0) mache aber "noch nix" sondern erst wenn ich den nächsten Punkt bekomme (mit genauer Zeitdifferenz) dann lasse ich den Spieler "hinlaufen", mit anderen Worten nutze ich meinen "BOT verfolgt Maus"-Algo und setzte den Spieler dann nicht zu jeden Punkt, sonder lasse ich immer hinlaufen ...

(vllt meintest du das ja auch PMV)

Was verstehst du unter vernünftigen PING ? wir hatten 100-150 ...
klar das es im LAN immer besser aussieht als im Netz aber man muss ja auch mit schlechten verbindungen eine gute quallität haben.

EDIT:

Die ersten Test mit der neuen "Engine" sind soeben abgeschlossen, und die ergebnisse sind gut, sowohl im LAN als auch INet...

[php-freak]

Wirds jetzt auch Online oder nur Singleplayer?

[PMV]

Das mit der Approximierung hatte ich zwar auch im Kopf als ich das
schrieb, aber ich habs direkt wieder verworfen ... da das nur eine
Möglichkeit darstellt, wenn die menschlichen Gegner sich nicht gegenseitig
abschießen können und das ganze also lediglich zur visualisierung dient.

Wenn das bei 20Hz zu ruckartig statt findet, dann sollteste das mal mit
25Hz oder sogar mit 30Hz versuchen. 100-150 ist glaub ich schon die
obere Grenze, aber nicht unüblich. Du musst zwar dabei bedenken, dass
das Gesendete bereits in der Vergangenzeit liegt, aber jedes mal die
100ms auf die aktuelle Position hoch rechnen wird vermutlich schwirig um
zu setzten sein ... ich würds glaub erst mal verschen, das mit der
Zeitversetzung vernünftig um zu setzen. Wenn es hierbei nämlich schon
zittrig ausschaut dann ist der Ping dafür einfach zu hoch. Aber man
wüsste schon mal, was das Problem ist und hier drauf könnte man
aufbauen ... z.B. das bei neuen Positionsdaten eben nicht sofort
gesprungen wird sondern ein "weicher" übergang berechnet wird.

Viel Glück

MFG PMV