[Projekt] Devader

[marcgfx]

hey stephan, vielen dank für das feedback, freut mich sehr das zu hören! bisher habe ich kaum infos zum spielspass, ausser von freunden, die ich zum spielen gezwungen habe :)

[marcgfx]

wieder mal am fehler korrigieren, altlasten entfernen und teilweise verschlimmbessern ;)
hab bei den schüssen noch ein problem festgestellt. wenn ein gegner ganz nahe war, konnte es sein dass der schuss durch ging ohne zu treffen. für die kollisionserkennung muss alles in einem grid registriert sein und ich habe festgestellt, das die eigentliche registration erst ende des zweiten frames nach erstellen des objekts gemacht wurde... beim testen kam es zu folgendem gif, dass sich super zum loopen eignet.

desweiteren habe ich viel zeit in die video-funktionalität gesteckt. dabei werden die positionen/animationen etc gespeichert und wieder geladen. funktioniert schon wieder ganz ok, aber ich bin sicher dass wird mich weiterhin zeit kosten. die aufnahmen waren damals für die KI-kämpfe gedacht, damit sie später auch von anderen begutachtet werden können. irgendwann soll das auch wieder aktuell werden.

[marcgfx]

mal wieder ist es viel zu spät geworden... da kann ich auch noch nen beitrag schreiben.

performance ist eines der grössten probleme die ich momentan habe. zum einen braucht die ki ganz schön cpu und die gpu geht auch ganz schön ab bei meinen shadern. gestern habe ich gelesen, das branching in einem shader ganz schlecht ist. natürlich mache ich das exzessiv. da ich alles in zwei shader gepackt habe, sind auch zig verschiedene zustände abgebildet alle schön verschachtelt. ob ich da was machen kann, ich weiss es nicht.

was ich allerdings machen konnte: bislang habe ich für den hintergrund/die strecke eine perlin-noise funktion verwendet um zwei texturen zu vermischen. diese funktion habe ich nicht selbst geschrieben, aber schluckt ganz viel leistung. ich habe zuerst versucht eine einfachere noise-funktion zu schreiben, die sah aber dermassen schlecht aus, dass ich den code schnell wieder gelöscht habe. als alternative habe ich mir überlegt die bestehenden texturen zu nutzen um die textur-vermischung zu machen. mit etwas probieren und zwei textur-lookups habe ich ein ganz ansehnliches ergebnis erzielen können. mir gefällts gar besser als die bisherige variante, ich weiss aber nicht ob es wirklich viel schneller ist. es sind auf alle fälle nur noch ein paar statt hundert zeilen.

an der strecke musste ich erneut hand anlegen, da ich wieder einen optischen fehler entdecken musste. ich glaube aber jetzt eine stabile lösung produziert zu haben.

auf dem screen kann man zwei neue assets sehen: zuckerstangen und ein riesen-kegel (durch skalieren auch mini-kegel). ebenfalls kann man ganz leicht den noise auf der strecke sehen.

[marcgfx]

wie ich im letzten post schon erwähnt habe, kämpfe ich momentan mit der performance. heute habe ich versucht eine allgemeine lösung für die ki zu finden. die idee: ich limitiere alles ki bezogene auf ~5ms pro frame. die umsetzung war nicht sonderlich schwierig und das verhalten der fahrzeuge hat sich nicht massiv verschlimmert, bzw. war nicht spürbar.

da kam mir der gedanke ich könnte doch mal mehr fahrzeuge ausprobieren. limite auf 100 erhöht und los ging der spass. erstaunlicherweise hats auch jetzt noch gut funktioniert, bis ich das rennen gewonnen hatte. danach fingen die autos an wild über den bildschirm zu fahren, die ki war verdummt. was war geschehen? nachdem der spieler die ziellinie überkreuzt wird herausgezoomt, das tempo wird erhöht. nachdem ich zoomen und speedup ausgeschaltet habe, lief es weiterhin nur schleppend. da wurde mir erst das leaderboard bewusst. diese schluckt massiv performance, da in jedem frame der inhalt in html neu aufgebaut wird. dies führte zu einer viel geringeren framerate. durch die geringe framerate hatte die ki weniger kontrolle und die fahrzeuge waren in vielen frames führerlos. ohne leaderboard gings passabel mit 100 fahrzeugen.

dachte ich zumindest, bis ich die nächste strecke probierte. die fahrzeuge sind nur noch umhergeschlittert und haben sich gedreht. was war los? da die ki nicht mehr in jedem frame auf jedem fahrzeug lief hatte die ki massiv probleme auf dem rutschigen belag.

schlussfolgerung: die idee ist gut solange die fahrzeuge genug oft von der ki gesteuert werden können. sind es zu viele fahrzeuge oder ist die framerate zu gering wirds problematisch.

vermutlich muss ich die komplexe ki die ich mit neuronalen netzen + evolution erstellt habe zugunsten der spielbarkeit kicken... vermutlich ginge es sowieso viel einfacher ohne grossartigen qualitätsverlust.

grundsätzlich hatte ich vor KI wettbewerbe zu machen, evtl. wäre sowas schon mal eine gute aufgabe. eine möglichst schnelle KI die mit wenigen ausführungen (z.b. 5 mal pro sekunde) stabile resultate erzielt. was ich noch nicht genau weiss ist wie ich die ausführungsdauer der KI bewerten soll. die dauer kann eigentlich nur relativ mit einer anderen KI verglichen werden. der score könnte vielleicht so berechnet werden: SUM(zieleinlauf)*SUM(ausführungszeit)

evtl kann ich sowas ja dann zum launch machen ;) vermutlich sollte ich aber noch selbst eine schnellere KI erstellen.

[marcgfx]

eigentlich gehört das in den jammer-thread, aber ich jammer jetzt mal hier: wieso ist es so **** schwer ein gutes gui in html zu erstellen, das auch mit pfeiltasten/gamepad zu bedienen ist? mein bisheriges startmenü ist viel zu kompliziert und ich habe ewig lang gebraucht es zu bauen. ich habe jetzt immer wieder versucht was einfacheres hinzubekommen aber produziere ausnahmslos schrott. als erstes habe ich eine version programmiert, bei der man verschieden optionen durch hoch/runter auswählen konnte und mit return/enter selektiert hat. das war dann schon zu einfach und auch nicht wirklich eine gute lösung. heute habe ich versucht die bisherige lösung auseindanderzunehmen und aufzuteilen, aber ich muss alles komplett neu designen und es sieht auch aus wie schrott. argh. desweiteren musste ich an verschiedensten ecken und enden wieder was programmieren, jedes element funktioniert wieder anders, argh... naja. ich habe mir jetzt so halbwegs ein neues konzept überlegt und werde wohl komplett von vorne beginnen. dieses mal will ich alles in html designen und nicht wie bisher alles programmieren. mal sehen wie erfolreich ich damit bin. ach ja, aaaaargh.

[marcgfx]

im jammer thread hab ich mich letzthin doch mal geäussert, allerdings ging es da um den doppler-effect, ein cooles feature in der neuen webaudio-api. leider musste ich plötzlich feststellen, das der doppler-effect deprecated ist und demnächst rausgeschmissen wird. nach etwas gelaber auf dem entsprechenden thread, bekam ich die hilfreiche info, dass es nicht so schwer sei das selbst zu implementieren. trotz zweifel habe ich mich also der aufgabe gewidmet und es war in der tat nicht so schwierig. jetzt mach ich die ganze arbeit selber, dafür läufts auch in ein paar monaten noch :)

viel habe ich ansonsten nicht auf die beine gestellt. zu viel zu tun und nicht so gesund, elende grippe. etwas feedback habe ich aber von nem kollegen bekommen: zu schwierig, bäume nerven (weil man hängen bleibt) und es ist nicht immer klar wo man fahren soll. am schwierigkeitsgrad habe ich jetzt bei den einfachsten zwei stufen noch etwas gedreht, die bäume lass ich aber mal. bei den checkpoints habe ich eine änderung gemacht: es werden die pfeile nur noch dort angezeigt wo man auch hinfahren kann/soll. ich hoffe das macht die geschichte etwas klarer.

[marcgfx]

nicht viel gemacht in letzter zeit :( . mit erschrecken musste ich feststellen, das mein motorengeräusch in chrome nicht läuft. schlussendlich fand ich raus, das chrome in der neusten stabilen version einen webaudio bug eingeführt hat. ich hoffe das wird demnächst gelöst.

hab gestern noch ein bisschen an power-ups rumgebastelt

150426orbiter.gif (359.54 KiB) 3276 mal betrachtet

[marcgfx]

GUI design ist definitiv schwierig für mich. die bisherige lösung hat zwar funktioniert, leider war sie sehr überladen. die neue variante ist viel schlanker, bietet weniger funktionen an und sollte zugänglicher sein. eine der hauptschwierigkeiten war eine lösung zu finden, die für alle eingabegeräte funktioniert (keyboard, mouse, touch, gamepad). habe was eigenes dafür gestrickt und es scheint ganz gut zu funktionieren.

http://data.cyberlympics.com/html/nav.html

einiges geht noch nicht, ich plane die alten features nach und nach auf dieser grundlage aufzubauen.
die meisterschaftsstrecken sind hard-coded (bis auf Random) , ich habe nur wenig zeit in die selektion gesteckt.

diese fahrzeuge stehen nicht alle online zur verfügung, aktuell nur 1-4

[marcgfx]

hab heute so viel gemacht, dass ich bereits wieder vergessen habe was... mal schauen ob ichs wieder hinbekomme.
- gamepad/keyboard steuerung überarbeitet. bislang gabs immer probleme wenn das gamepad aktiviert wurde, das keyboard hat dann nicht mehr korrekt reagiert. dies war hauptsächlich für mich zum testen doof, allerdings hätte es evtl. irgendwann probleme geben können.
- ich hab gemerkt, dass die fahrzeuge wieder ohne doppler-effekt unterwegs waren. ursache: in chrome gibts einen webaudio implementierungsfehler (in der aktuellen version funktioniert loop nicht richtig). ich habe natürlich zuerst gedacht es sei mein fehler und überall änderungen gemacht. eine dieser änderungen habe ich nicht rückgängig gemacht und damit den doppler-effekt verhindert. hab sicher ne halbe stunde gesucht :(
- da ich schon beim sound war, habe ich die fahrgeräusche der fahrzeuge etwas überarbeitet.

dann kam ein grösseres refaktoring:
ich habe vor einiger zeit gelesen, dass branching ganz schön schlecht ist in shadern. da ich für alles nur zwei shader und zwei draw-calls verwende habe ich verdammt viel branching. ganz übel ist der code für den hintergrund, der fraktal-generierung mandelbrot + julia und andere spässe beinhaltet. ich habe einen neuen shader und draw-call nur für den hintergrund erstellt, das abkapseln ging erstaunlich gut. schweren herzens habe ich die fraktal geschichten und andere spässe einfach eliminiert. wirklich schön war das zeug eh nicht.

bei der umstellung auf die 3 layer variante habe ich auch noch einen single-color-shader für jedes layer erstellt, damit ich sehen kann obs richtig funktioniert. links sind die 3 schichten erkennbar (blau hintergrund, grün strecke, rot objekte) und rechts so wie das resultat mit einem anständigen shader ausschaut.

[marcgfx]

heute ist schlimm. bin immer noch am rumbasteln. sollte schon lange schlafen... hatte die tolle idee mal zu schauen ob ich das verkleinern extra von mario kart nicht auch hinbekommen könnte. war mit all dem zeug was ich schon eingebaut habe sogar sehr einfach. musste bloss noch einen parameter hinzufügen, der das skalieren beeinflussen lässt. naja, dann musste ich noch schnell ein icon machen und verschiedene werte testen und und und... also ne sache von 3min!

[Max Gooroo]

Bei mir kommen derzeit ständig irgendwelche Fehler wie "e.replace is not a function" beim Laden und dann bleibt es stehen.
Wenn es doch mal reingeht, ist das Rennen mal wieder nach 10 Sekunden vorbei :D ...

Vielleicht solltest du in der Signatur immer nur eine mehr oder minder stable Version anbieten. Ich vermute mal, daß der ein oder andere sich gedankenlos abwendet, wenn das Spiel immer so schnell nichts mehr tut. Da dürfen dann auch weniger Features drin sein.
Eine unstable höchst aktuelle kannst du ja auch als solches angezeigt noch anbieten. Aber mir ist es jetzt schon öfter mal passiert, daß Ich mich einfach mal informieren wollte und ziemlich schnell feststelle, daß mit der Version wohl nichts anzufangen ist, was schade ist.

[Ragno]

Schaut richtig gut aus! :)

[marcgfx]

danke fürs positive und negative feedback! grundsätzlich versuche ich immer eine stabile version hochzuladen, bzw. ich teste sie auch noch nach dem hochladen. was ich eben festgestellt habe, ist das es mit safari ein problem gibt. leider kann ich safari nicht auf meinem system testen, da 5.1.7 kein webGL auf windows unterstützt. auf meinem macbook started es, aber nach 10 sekunden ist das rennen auch vorbei (weil der spieler nicht aktiviert wird). Ich werde der sache mal nachgehen, vielen dank fürs melden!

[marcgfx]

war doch nicht nur ein safari problem. beim umstellen des menüs ist mir ein fehler unterlaufen. ich habe vergessen den spieler festzulegen (wird lokal gespeichert) -> wer noch nie gespielt hat, hat auch keine aktive spielfigur... argh. 1. kann man gar nix machen. 2. hört das spiel nach 10 sekunden auf. hoffe das problem ist behoben, braucht womöglich ein refresh!

safari hat in der tat noch ein paar probleme mit meinem code, sound läuft aktuell nicht.

[Max Gooroo]

Jo, geht jetzt wieder ...
Sogar relativ performant, dafür daß Ich es hier auf so einer Rotzbude ausprobiere.

[marcgfx]

cool! bei mir läufts seit der umstellung der shader auch schon viel besser auf meinem macbook. davor musste ich mit der schlechtesten einstellung spielen, jetzt gehts sogar auf der höchsten. gibt ganz sicher noch immer verdammt viel was ich da rausholen könnte...

[marcgfx]

bin heute nach um 4 wach geworden, viel zu viele ideen... u.a. wollte ich eine grössere auswahl an spielerfarben. ich verwende für die spieler und bots ein unterschiedliches model, für die farbvariationen wird nur der hue verändert. dies lässt aber nur beschränkt unterscheidungen zu bei vielen spielern. bei den computer-gegnern ist das nicht soo relevant, bei menschlichen finde ich es doch wichtiger. eigentlich müssten ja 6 farben reichen (rgb) + (cmy). ich wollte aber aus unerfindlichen gründen 12 haben (theoretisch gibts sogar 12 player split-screen). deshalb habe ich jetzt noch einen dunkel-wert eingeführt + eine möglichkeit um die fahrzeuge weiss zu machen. wie viel sinn das ganze macht, sei mal dahingestellt.

[Schrompf]

Ich finde, das ist kein Fortschritt. Also jetzt rein nach den Bild geurteilt behaupte ich, dass Du die Farbenmenge ausgereizt hast. Für mehr Spieler, die Du tatsächlich unterscheidbar machen willst, müsstest Du andere Differenzierungsmöglichkeiten finden.

Ich habe das Spiel gestern übrigens mal wieder angespielt. Läuft stressfrei und flüssig. Und die Map sah einfach geil aus. Speziell als der Baum anfing zu wippen, als ich dagegen fuhr, fand ich großartig. Hab aber leider die Taste zum Auslösen des Extras nicht gefunden.

[marcgfx]

danke fürs antesten! das wippen der bäume scheint die meisten glücklich zu machen :) , zerstören macht noch mehr spass :D

du hast recht, es ist kein fortschritt. ich habe mir heute nacht überlegt, wie ich die mehrspieler-geschichte im neuen menu lösen soll. dort würde ich gerne ne farbauswahl haben. 6 farben hätten weitaus gereicht. ich wollte eigentlich nur wissen ob ich es schaffe. es war auch noch ne recht umfangreiche umstellung, von daher eigentlich blöd. spielerei.

immerhin sind mir beim testen diverse andere sachen aufgefallen, z.b. dass die gegner nie mehr als ein extra auslösen können (war eigentlich ganz angenehm). dass bei den explosionen ein kleiner alpha-fehler drin ist. dass ich auf einer strecke bäume habe (was zwar lustig ausschaut, aber falsch ist...).

die keyboard einstellungen muss ich demnächst wieder sichtbar machen, die haben die menü umstellung noch nicht durchgemacht. wäre eindeutig wichtiger gewesen als die farben...
ich benutze aktuell vor allem die numpad tasten.

Code: Alles auswählen

123 789 
qwe uio
asd jkl

numpad:
789
456
123

open links ist immer die extra taste, die anderen zwei oberen tasten haben aktuell keine funktion

bei den pfeiltasten bin ich mir nicht sicher im moment.
ich will die tasten auf alle fälle noch für single-player optimieren.

[marcgfx]

laaange nix mehr gemacht... zu viel arbeit. ich hab mal wieder ein bisschen was angeschaut und habe ein problem.
ich habe vor einiger zeit, harte kurven als option eingeführt. problematisch ist es wenn ich zwei streckenlinien drauf habe, dort kann die innere linie eine schlaufe erzeugen. ich würde gerne diese schlaufe erkennen und abschneiden.
aufgabe: erkennen ob ein n-gon sich selbst überschneidet. am besten ohne alle kombinationen durchgehen zu müssen. gefunden hab ich das: http://math.stackexchange.com/questions ... tersection
hat jemand von euch schon so was gemacht?

anstatt den checkpoint in der kurve, werde ich vermutlich den checkpoint um 90° drehen, weiss aber auch noch nicht wie ich das am besten löse.

[dot]

Ich hab einen besseren Vorschlag: https://en.wikipedia.org/wiki/Centripet ... Rom_spline ;)

Btw: Für so etwas wie Straßen würde man in der realen Welt eigentlich wohl sowas wie Klothoiden verwenden:

http://www.dgp.toronto.edu/~mccrae/proj ... mccrae.pdf
http://www.sciencedirect.com/science/ar ... 969190042A
http://www.lara.prd.fr/_media/users/fra ... spline.pdf
https://de.wikipedia.org/wiki/%C3%9Cbergangsbogen

[marcgfx]

wenn ich das richtig verstehe, würde es einfach weniger spitze kurven geben, was für strassen ja schon sinn macht. ich möchte aber diese spitze übertriebene kurve/ecke :)

[marcgfx]

habe mich hier ziemlich rar gemacht in letzter zeit. gab schon immer wieder kleinere sachen an denen ich gearbeitet habe, aber wenig erwähnenswertes. u.a. habe ich ewig lang ein performance problem gesucht das gar keines war. beim erstellen von etwa 1000 schüssen ging die performance immer in die knie und ich wollte das unbedingt verbessern. fand es komisch, da es nur beim abschiessen problematisch war. sobald die schüsse fliegen, wars kein problem. stellt sich raus, wenn 1000 schüsse auf einen punkt konzentriert sind, gibt es verdammt viele kollisionsprüfungen...

ich habe das bisherige logo vernichtet und mit einem neuen font ersetzt. um dieses zu finden habe 10000 fonts durchsucht und nix passendes gefunden. kein witz, 10000. nichts gefunden stimmt auch nicht ganz. das problem ist, es gibt kaum fonts die monospaced zahlen haben. schlussendlich habe ich einen font mit fontforge selber nach meinen vorstellungen angepasst.

an der minimap habe ich jetzt aber was gemacht dass ich zeigen kann.



zuoberst ist die ursprüngliche version. hier wird alles auf ein canvas gezeichnet, auf die wohl ineffizienteste art und weise. ich kann nur kreise zeichnen, mit einem eigenen algorithmus. auch die strecke ist nur ein überlagern von ganz vielen kreisen. die ineffizients war aber nicht ein problem, sondern die optik gefiel mir nicht richtig.
dann kam version zwei, wo ich die komplette szene in ein canvas rendere und danach runterskaliere. ich finds nicht schlecht, aber evtl. nicht so rennspiel-tauglich.
deshalb kam versuch 3. bei versuch 3 habe ich version 1 etwas angepasst. leider musste ich feststellen, dass dies wohl der beste ansatz ist.
da versuch 3 verdammt verpixelt und unschön war, kam es zu version 4. hierfür musste ich neue shader schreiben und lernen wie ich einen shader in einem webgl program austauschen kann. muss zugeben, ich habe hier mehr gehackt als verstanden. das resultat ist aber so wie ich es mir vorgestellt habe. netterweise bietet canvas eine möglichkeit an einen schatten zu werfen, somit konnte ich das ganze in einer laaangen nachtsession erledigen.

[marcgfx]

netzwerk ideen

da ich das spiel bislang komplett client-seitig gebaut habe, möchte ich nicht auf eine server-authoriy wechseln.
standard für schnelle spiele wäre eine client-server lösung, bei der der server die ganzen kalkulationen macht und auch das letzte wort spricht wenn sich client/server mal uneinig sind.

das möchte ich vermeiden, allerdings wirds wohl seine guten gründe haben wieso das so gemacht wird.
ich möchte nur die inputs aller spieler übermitteln, wie es auch bei rts spielen gang und gäbe ist.

eine lösung für das übermitteln wäre peer-to-peer, weiss bloss nicht wie gut das funktioniert. bei 10spielern würde das 9 verbindungen pro client bedeuten.
die server lösung würde insgesamt deutlich weniger benötigen, hätte aber den nachteil das alle informationen über den server laufen müssten. was passier wenn die spieler alle in den usa sind und der server in deutschland?

ich habe getestet wie sich das spiel verhält, wenn der input leicht verzögert wird. 100ms verzögerung sind nicht zu bemerken, mit 200ms ist noch gut zu fahren, 300ms wird unangenehm. würde heissen, so lange ich unter 100ms bleiben kann, dürfte es mit netzwerk gut klappen. allerdings muss ich auch mit schlechteren verhältnissen klar kommen.
ich habe mir überlegt das spiel über fixe zeitschritte von 50ms zu berechnen, also 20fps (wenn es schnell genug ist, könnte ich auch eine höhere rate nehmen). die positionen der bewegten elemente werden nach jedem fixen schritt berechnet und gespeichert. wenn jetzt ein input von einem spieler 300ms zu spät reinkommt, müsste ich 6 schritte zurück gehen und die 6 schritte neu berechnen mit dem neuen user-input. hat zur konsequenz, dass ich alle berechnungen viel öfters machen muss, worunter die performance wieder leiden wird.

[marcgfx]

habe etwa 2.5 tage ineffizient an diesem problem gearbeitet:



Im frame mit sternschnuppe kann man am rand der strecke einige fehler entdecken. diese entstehen durch polygon-überlagerungen von transparenten stellen. durch die überlagerung wird die entsprechende stelle stärker gefärbt. Ich konnte das problem nur durch hacky-polygon-manipulationen reduzieren. ob ich jeden fall gelöst habe weiss ich nicht, besser ist es trotzdem.

am übungsmodus habe ich ebenfalls gearbeitet. hier hatte ich bislang immer eine fixe framerate, da ich den geist-fahrer ja irgendwie rekonstruieren musste. die fixe framerate hat sich aber nicht sonderlich gut mit dem browser-eigenen rendering vertragen und es kam öfters mal zu rucklern.
neu berechne ich im übungsmodus die zeit dynamisch, mit einem trick. sobald genug zeit akkumuliert wurde berechne ich einen konstanten frame und dieser wird in der history gespeichert. übrige zeit wird danach noch berechnet für die anzeige, wird aber nicht gespeichert. beim nächsten game-loop beginne ich dann wieder von der zuletzt gespeicherten history zu berechnen. die idee ist, dass ich diese technik auch für das networking verwenden kann.

[mrz]

Zum Thema Netzwerk, als Denkanstoss:

Würde auf jeden Fall ein "Master/Slave" Lösung machen.
Welcher Spieler der Master (Server) ist sollte dynamisch gewählt werden und während dem Spiel ändern können
(z.B. wenn dieser Spieler das Rennen verlässt, oder ein anderen Spieler latenzmässig die bessere Wahl ist).
Das wäre die Deluxlösung.

Dass Du so wenig wie nötig an den Server sendest, also nur Userinput, finde ich gut.
Warten bis der Server das validiert und dir bestätigt hat solltest Du aber nicht sonst wirkt die Steuerung träge.
Der Renderer sollte instant die Eingaben berücksichtigen. Durch Interpolation verringerst
Du grössere Differenzen zwischen Client- und Server-State.

Ich bin ehrlich gesagt ein grosser Fan wie das Thema Netzwerk bei Q3 gelöst wurde
(und in Warsow weiter verbessert wurde), zumindest vom Konzept her.

Der Client sollten nicht nur die Positionen (welche vom Server berechnet wurden) der anderen Spieler bekommen,
sondern zusätzlich auch deren Richtung, Speed/Beschleunigung. So kann der Renderer interpolieren/extrapolieren:

Du kannst also die Bewegungen der anderen Spieler flüssiger machen ("rumspringen/stottern" vermeiden)
und vorallem berechnen "wo der Spieler sein wird" (da ja die Position welche Du vom Server bekommst zum Zeitpunkt
beim Empfangen schon wieder veraltet sind).

In Q3 ist das mit der Einstellung "cl_timenudge" steuerbar:
- mit negativen Wert gleicht man Latenz aus, es wird extrapoliert
- mit einem positiven Wert wird eine Latenz simuliert
(z.B. im Offlinemodus gegen Bots damit man das gleiche "träge feeling" wie Online hat)

Interpolieren/extrapolieren sollte aber nur bis zu einer gewissen Latenz gemacht werden (z.B. bei <300ms),
sonst gibts hässliche Effekte bzw sie werden ab dann gut sichtbar. Bei Latenz >300ms ist es einfach abgeschalten,
es laggt dann halt ganz normal.

Warsow hat das btw noch etwas weiter verbessert und schenkt Spielern mit grosser Latenz (>200ms)
unter gewissen Umständen etwas mehr vertrauen um ihren Nachteil (durch die grosse Latenz)
etwas zu reduzieren. Damit der Post nicht zu lang wird lasse ich die Details mal.

>> ich habe mir überlegt das spiel über fixe zeitschritte von 50ms zu berechnen

Q3 macht intern alles so und das heisst dort "Snapshots". Der Server sendet den Clients immer das Delta
zum letzten von diesem Client bestätigten Snapshot. Der Server berechnet in fixen Abständen (Einstellung sv_fps)
die Snapshots und behält sie bis zum ältesten vom einem Client noch nicht bestätigten
(wenn die Queue zu gross wird wird der Client wo das älteste Snapshot nicht bestätigt hat gekickt).

Bei UDP ist das ne super Sache und man kriegt mit so einem Konzept auch gleich eine Aufnahme-Funktion geschenkt:
Die Snapshots einfach auf die Disk dumpen und zum Replayen "an den Client senden".

[marcgfx]

danke für den ausführlichen kommentar mrz, ich sehe da überschneiden sich gerade unsere interessen ;)
ich muss zugeben, gelesen habe ich bislang nur sehr wenig zum thema.

es ist irgendwie noch witzig, die aufnahmefunktion die man bei dieser technik umsonst bekommen würde, habe ich bereits vor ewigkeiten implementiert und kann sie jetzt super für die netzwerk-geschichte einsetzen. die performance scheint auch passabel zu sein, wobei es immer optimierungspotential geben wird.

der aktuelle plan ist wie gesagt nur die user-inputs zu übermitteln, keine positionen oder ausrichtungen/speed. vielleicht bin ich hier zu blauäugig, aber ich hoffe das reicht. eines der probleme ist ja scheinbar, dass verschiedene maschinen bei gleichen berechnungen unterschiedliche resultate erzielen können. evtl werde ich also noch kontroll-daten übermitteln müssen.

master/slave: ich denke ich werde einiges ausprobieren und sehen welcher weg mir den geringsten wiederstand bietet. peer to peer oder server, keine ahnung was ich machen werde. soweit ich gelesen habe, wird heutzutage praktisch nur die serverlösung eingesetzt. allerdings frag ich mich auch wie ich sowas gescheid skalieren kann. peer to peer wäre von daher einfacher, sofern ich stabile verbindungen zwischen den clients überhaupt realisieren kann.

eben habe ich mit einem simulierten lag von 0.5 sekunden versucht zu fahren. das lief nicht mehr so glatt, das fahrzeug hat ziemlich komische bewegungen gemacht. da fiel mir ein dass ich die tasten inputs noch nicht in der history drin habe. dürfte nicht so schwer sein hier nachzurüsten. am besten finde ich an der technik, dass ich das ganze so schön testen kann ohne überhaupt eine netzverbindung aufbauen zu müssen.

bzgl aufnahmefunktion ist mir noch was durch den kopf gegangen. wenn ich das spiel ja nur durch die inputs komplett simulieren kann, müsste ich auch für das speichern der kompletten aufnahme eigentlich nur die inputs haben. allerdings könnte man nicht in der aufnahme rumhüpfen.

[mrz]

>> der aktuelle plan ist wie gesagt nur die user-inputs zu übermitteln, keine positionen oder ausrichtungen/speed.

Vom Client zum Server reicht UserInput. Aber vom Server zu den Clients
rate ich dazu Positionen zu senden mit Ausrichtungen/Speed.

UserInput ist immer relativ. Du nennst selber den Grund: Floatingpoint Ungenauigkeit.
Irgendwann ist die Differenz evtl recht gross. Deine lokale Berechnung/Kollisionerkennung ergibt z.B.
dass der andere Spieler an ner Ecke hängen bleibt, auf dem Server ist der Player aber ein Pixel
verschoben und bleibt nicht an der Kante hängen. Wenn Du ausschliesslich UserInput austauschst
könnt ihr euch gar nicht mehr syncen.

Mit der Position kennst Du die "absolute" und korrekte Position (laut Server) zum Zeitpunkt x.
Zusammen mit Ausrichtungen/Speed erlaubt das eine Interpolation und ist auch Grundlange
für eine möglichst gute Extrapolation.

Btw. war es schon vor 10 Jahren egal ob nun bei einem "Packet/Takt" 8 oder 256 Bytes übers Netz gehen.
Das wird erst "kritisch" wenn sie grösser als MTU sind, oder Du MMO planst.
Solange Du unter 1500 Bytes bleibst und <50 Player pro Session würde ich mir darüber keine Gedanken machen.

Für deinen Anwendungsfalls zwar nicht relevant, aber der Vollständigkeit halber:
Für Anti-Cheat Protection kommt man gar nicht drumrum mit absolute Positionen zu arbeiten.

Der Flaschenhals bei dir ist und wird immer JavaScript sein,
auch wenn die Browserhersteller nochmals 50% rausholen würden.
Auch was dir WebSockets/TCP an Overhead reindrücken ist ein Witz gegen JS.
Aber das ist ja auch die Herausforderung und macht es erst interessant ;)

Auf Kosten der Performance die Daten zu reduzieren (z.B. komprimieren bevor Du sie sendest)
wird mit JS nach hinten losgehen. Lieber etwas mehr Daten senden so dass Du sie
effizient parsen kannst.


>> am besten finde ich an der technik, dass ich das ganze so schön testen kann ohne überhaupt eine netzverbindung aufbauen zu müssen.

Was noch toller ist (aber da killt dich JS) dass man eigentlich immer Client/Server verwendet, auch Offline.
Sauber ist mit einem Event-System zu arbeiten:

Im Onlinemodus werden die Events in ein "Packet" gepackt, versendet, empfangen und wieder in Events aufgeteilt und verarbeitet.
Im Offlinemodus kommen die Events einfach direkt in die Queue vom entsprechendem Gegenpart.

Vorteil ist Online/Offlinemodus funktioniert gleich, die Maintenance wird vereinfacht.
Dazu kommt durch die strikte Trennung dass sie sich unabhängig voneinader testen lassen.
Das vereinfacht massiv die Entwicklung von Integrationtests.


>> allerdings könnte man nicht in der aufnahme rumhüpfen.

Das stimmt, ist aber nix Ungewöhnliches. Sonst muss permanent bei jedem "Aufnahme-Frame"
der komplette State gespeichert werden, und das wird - vergleichsweise - teuer.
Möglichst wenig auf die Disk schreiben ist schon gut. Wenn dir das aber wichtig ist kannst Du
im Nachhinein einmalig immer noch in fixen Abständen (z.B. alle 5 Sekunden oder immer nach x Frames)
quasi ein "Keyframe" generieren wo der ganze State ist. Dann kannst beim Abspielen einfach
ab dem "nahestem" Keyframe abspielen und musst nicht vom Anfang an "durchrechnen".
Videoformate funktionieren genau gleich.

[marcgfx]

danke für deine eräuterungen mrz, sehr informativ!

ich merke, dass ich ein riesen fass voll würmer aufgemacht habe. darunter könnten sich ein paar goldmünzen befinden, aber ich weiss nicht ob ich mich nicht zu sehr ekle um sie rauszuholen :P

- wenn ich nicht ohne server auskomme, wird die geschichte mit dem netzwerk vermutlich zu viel arbeit. die frage ist ob ich es mir erlauben kann, dass die clients leicht daneben sind. schlussendlich muss jeder nur mit dem erspielten ergebnis zufrieden sein, d.h. wenn ein gegner irgendwo hängen bleibt stört mich das nicht. am pc des gegners ist es evtl. umgekehrt. im normalfall gehe ich aber davon aus, dass sehr ähnliche resultate erzielt werden. ist zwar etwas beschiss, aber solange beide spieler glücklich sind, ist es evtl. verschmerzbar
- ich habe schon mühe nur 10 frames zurückzugehen und sauber alles zu rekonstruieren. bzw. aktuell läuft zumindest das fahrzeug auf der strecke gut. probleme bereiten mir die zerstörbaren umgebungselemente (muss auch noch in die history, ist aktuell noch nicht) und die effekte klappen nicht gut.
- bei den effekten (staub/explosionen) kommt hinzu, dass ich zufallszahlen verwende für die platzierungen. bei der rekonstruktion muss ich aber unbedingt die gleichen zahlen bekommen sonst flackert es (tuts aktuell). evtl. kann ich das mit einem seed am anfang des frames lösen. zusätzlich scheints ziemlich an der performance zu nagen, aber da kann ich vielleicht was tun.
- es fehlen in der history vermutlich einige wichtige werte, irgendwie muss ich rausfinden welche dass sind
- 8 spieler würden mir völlig reichen, evtl. bin ich im online modus sogar mit 2 zufrieden ;). letzteres wäre bestimmt viel einfacher zu handhaben, ginge auch am besten mit peer-to-peer.

naja ich habe schon einige barrieren überwunden. evtl. liegt diese auch noch drin.

hab letzthin wieder ein paar bäume gebastelt, die ersten zwei sind für die winterlandschaften:

r0004-0000.png (18.24 KiB) 5591 mal betrachtet

r0029-0000.png (39.81 KiB) 5591 mal betrachtet

r0027-0000.png (27.59 KiB) 5591 mal betrachtet

[Dummie]

Ich hab selber ein paar Spiele mit Netzwerkfunktionalität programmiert und habe es bei mir so gelöst, dass es eine festgelete Sendefrequenz gibt und z.B. alle 100 ms ein neues Paket mit Informationen verschickt wird. Diese Informationen bestehen zum einen aus den Eingaben des Benutzers und zum anderen auch aus aktueller Position, Rotation, Geschwindigkeit, und solche Dinge.

Kommt so ein Paket an, dann übergebe ich die Eingaben an meine Eingabeklasse und die verhält sich so als hätte der Benutzer diese Eingaben getätigt. Das Fahrzeug fährt also erst mal. Damit kriegt man aber sehr schnell ziemlich große Abweichungen und hier kommen die weiteren Werte ins Spiel. Diese werden aber nicht einfach nur überschrieben sondern langsam über die Zeit interpoliert. Dadurch wird das Fahrzeug über die Zeit immer an der richtigen Position landen. Wie schnell oder langsam das gehen kann/muss, das kann man ausprobieren und so das Optimum finden.

Dabei habe ich natürlich die Erfahrung gemacht, dass das Ergebnis umso besser ist umso mehr zusätzliche Informationen ich übergebe. Gebe ich nur Position und Rotation mit, dann ist das zwar schon ganz nett, aber gebe ich z.B. noch die Geschwindigkeit, andere wirkende Kräfte usw. mit, dann wird es noch viel authentischer und flüssiger, da die Kernwerte einfach passen. Ich interpoliere aber auch nicht alle Werte. Auch hier muss man ausprobieren, was besser aussieht und wirkt. Außerdem kann man die Sendefrequenz natürlich noch verändern, aber ich bin mit 100 ms bisher immer ausreichend gut ausgekommen.

Das Prinzip ist also recht einfach und man kann so ein schönes und flüssiges Spielerlebnis aufbauen. Mit weiteren Techniken kann man auch die letzten Pakete speichern und versuchen zu berechnen, wie der Benutzer wohl als nächstes reagieren würde. Denn genau das ist die Kunst dabei: Du kannst die Verzögerung im Netzwerk nicht eliminieren und es wird immer eine Verzögerung geben, aber du kannst die Illusion schaffen, dass es so aussieht als würde alles genau so passieren. Denn letztendlich gibt es immer Abweichungen zwischen der aktuellen Darstellung und der realen Position von Objekten, usw. Hier muss man tricksen.

Es ist wirklich interessant und macht Spaß damit rumzuspielen. Wie sich das mit JS nun verhält ist natürlich eine andere Frage, aber vielleicht lässt sich das ja trotzdem so ähnlich umsetzen. Prinzipiell könnte man auch so eine Replay-Funktion bauen, die auch immer alles korrekt wiedergibt und somit sehr verlässlich ist.