ZFX + Developia

die replay funktion wird die krux sein. wenn ich diese so hinbekomme, dass alle relevanten informationen abrufbar sind, sollte es zumindest korrekt sein. ob ich es auch noch mit guter performance hinbekomme ist das zweite problem.

ich habe bereits einiges von Math.random() auf eine seeded random funktion umgestellt. braucht erstaunlich viel mehr performance. ich muss mir da wohl noch ne schnellere und einfachere variante suchen/selber machen. evtl. einfach ne liste mit zufällig verteilten werten von 0-0.999 die ich schrittweise durchgehe. die zufallswerte sind nur für die optik wichtig (z.b. das der staub nicht präzise hinter dem fahrzeug auftaucht).

eholfen hats noch nicht, aber das liegt sehr warscheinlich an fehlenden history informationen. wie gesagt, das fahrzeug fährt schon mal gut, auch mit 0.5 sekunden verzögerung. ich merk als user nichts, ausser ich fahre in einen baum der zerstört wird. in diesem fall gibts nen satten hüpfer, da bei der nachkalkulation der baum nicht mehr existiert...

das ich korrekturwerte mitsenden muss leuchtet mir aktuell noch gar nicht ein. ich hoffe dass wenn die berechnungen immer von einem korreken zustand aus geschehen, dass die abweichungen minimal sind. naja, vom senden bin ich eh noch meilenweit entfernt, zuerst muss mal das zeug in meinem test laufen.

probleme für die akurate replay funktion:
- audio: verhindern das ein sound für ein event mehrfach ausgelöst wird. was mache ich wenn ich erst 0.2 sekunden zu spät weiss, dass ich einen sound hätte abspielen sollen? sound ab position 0.2 abspielen, oder weglassen?
- influencer: diese haben einfluss auf ein object, z.b. abstossen, verlangsamen, beschädigen... bislang wurden diese influencer angewendet und nach einer fixen zeit wieder entfernt/oder nicht entfernt. jetzt muss ich wissen ab wann angewendet wurde
- explosionen/staub: bislang musste ich nur wissen wann/wo erstellt wurde. beinhaltet einige zufallswerte die bislang irrelevant waren, da nur optisch. explosionen die noch nicht erstellt wurden müssen entfernt und gegebenenfalls genau gleich wieder erstellt werden um flackern zu verhindern.
- alle arten von status variablen müssen in der history gespeichert werden. z.b. wie lange ein user inaktiv war (nach 1 sekunde inaktivität wird der wagen auf den letzten checkpoint gesetzt)
- aufgesammelte/ausgelöste extras und ihre status verändernden eigenschaften. was mache ich wenn ich ein extra auslöse, dass ich aufgrund veränderter gegebenheiten gar nicht mehr besitze, oder schlimmer noch es ist ein anderes extra... evtl. muss ich hier eine verzögerung einbauen zwischen aufsammeln und ausführen

habe schon von einem komplexen srand() auf mein eigenes billiges qrand() /*quick random*/ umgestellt. hier erstelle beim spielstart eine tabelle mit den 1000 werten von 0.00-0.999 randomisiere und hole mir schrittweise einen wert. ich merke optisch zumindest keinen unterschied. im profiler hat die srand funktion 14% meiner gesamtperformance verbraucht, die neue funktion wird nicht mal angezeigt.

wenn es jemanden interessiert, hier kann man sehen was ich momentan mache (berechnung mit 10 frames verzögerung)
http://data.cyberlympics.com/html/net.h ... _1_TRACK_a

da schreibt man sich ne schöne liste, was man alles tun muss. wie so oft hab ich aber ganz andere probleme gelöst, als die die ich vermutet/aufgelistet habe. nicht das diese nicht bestehen.

je mehr ich an meinem test gearbeitet habe, desto mehr fiel mir auf, dass die performance ein problem sein wird. mit einem fahrzeug und jeweils 10 zeit-schritte nachrechnen pro frame die rechenzeit bei etwa 14ms. für 60fps darf maximal 16ms für alle berechnungen verwendet werden. es war ziemlich offensichtlich das mehrere fahrzeuge den rahmen sprengen. es ging mal wieder ans optimieren, was sagt der profiler? durch das 10 fache berechnen des game-loops stachen jetzt neue funktionen wie dornen aus dem profiler-resultat hervor. einige funktionen hatten schon kult-status und alterspension. u.a. hatte ich ne tolle funktion geschrieben, die mir diverse sachen wie geschwindigkeit/ausrichtung/hitpoints/shild/ einzeln berechnen kann. damit sie dies kann muss ich ihr immer den entspechenden prefix mitgegeben (im code ist es der parameter v). dieser prefix wurde verwendet um properties zu identifizieren. diese properties werden dann in einem objekt gesucht... beim näheren betrachten wars eine katastrophe und offensichtlich schwer für die javascript engine zu verarbeiten.
mit wenig überlegen kam die lösung, die viel sinnvoller ist. alle variablen die benötigt werden, habe ich in ein struct gepackt, dass ich dann übergeben kann.
statt data[vim] heisst es jetzt halt data.v.im und übergeben muss ich nur noch das v -> also nur noch v.im.
wenn ich nicht javascript benutzen würde, hätte ich es sicher von anfang an so gemacht...

manchmal könnte ich mich treten. ich muss jetzt überall diese verdammten vorkommnisse debuggen, da javascript mir natürlich keine fehler beim compilieren liefern kann. das meiste läuft jetzt wenigstens wieder und die performance dieser funktion ist massiv besser, der profiler nimmt sie kaum noch wahr. was weiterhin nicht läuft sind history und jetzt auch noch die ki (da sie noch auf die alten strukturen zugreifen möchte).

es gibts vieles was ich optimieren sollte. auf ne art ist es traurig, andererseits ist noch vieles möglich ;)
ganz schlimm ist die minimap. für das neu zeichnen der objekte die sich auf der map befinden (nicht die strecke, nur die punkte) braucht es momentan fast gleich viel zeit wie für das zeichnen der ganzen szene...

edit: der text war noch schlimmer zu lesen als jetzt. hoffe man verstehts...

heute den ganzen tag bei schönstem wetter refactoring betrieben. immerhin läuft das spiel jetzt wieder und die KI kann fahren. als kleinen abstecher habe ich mich an quietschenden reifen in den kurven versucht, ging erstaunlich leicht. ich weiss aber noch nicht wie ich mit unterschiedlichen untergründen umgehen soll, z.b. wie soll sich das rutschen auf sand/eis anhören.

die history/network sachen sind noch alle kaputt von meinen umstellungen.

immer noch am bugfixing. nebenher gabs wieder ein paar spielereien. wählt man eine zufallsgenerierte meisterschaft aus, werden jetzt streckennamen generiert. zuvor war es einfach der zeitstempfel. grund für die umstellung: ich habe text-to-speech eingebaut. d.h. der level name wird jetzt vorgelesen. der zeitstempfel wurde dann natürlich als ewig lange zahl vorgelesen, was ich nicht so top fand. weiss nicht ob ich das vorlesen drin lassen soll, manchmal ist es arg verzögert, darauf schein ich keinen einfluss zu haben.

es gibt jedenfalls eine neue version. das rutschgeräusch sollte man zumindest als neuerung bemerken können.

da öfters mal angesprochen wurde, das rennspiele sprünge enthalten müssen, habe ich mich mal daran versuchts. weiss nicht obs wirklich sinnvoll ist. ich musste leider noch einiges am code anpassen, damit es überhaupt möglich war. dies hat das fahrverhalten beeinflusst, ist aktuell nicht optimal. die darstellung ist noch wip.

Sieht so ein bissel nach Sprüngen im Micro-Machines Style aus. Das bedeutet somehow cool, aber könnte beim Fahren nerven :D ... Hier ist dann Streckendesign gefragt, welches einen nicht zu sehr aufregt :D

du sprichst das problem an. durch den verlust vom bodenkontakt ist man der situation ausgeliefert, fährt man aus dem falschen winkel drüber landet man schnell mal in der wand oder einem baum. bei generierten strecken ist es ganz schön schwierig das sinnvoll hinzubekommen.

damit sprünge optisch möglich sind, muss ich die fahrzeuge noch in chassis/schatten unterteilen, bedeutet zusatzaufwand.

ich habe ein verständisproblem mit der physik vom fallen.

s = s0+v0*t+0.5*a*t^2

pro zeitschritt berechne ich das neue s0/v0

s += v*t + 0.5*a*t^2
v += a*t

aktuell verwende ich eine erd-beschleunigung von 300px/s^2. ein meter im spiel ist ~15px. müsste da die fallbeschleunigung nicht ~15m/s^2 sein? ich vermute das ist ein überlegungsfehler. bzw. ich weiss es, aber ich versteh nicht wie ich auf den korrekten wert kommen soll (9.81m/s^2 sind in fuss 32.17ft/s²)

also Ich habe ja schon lange nicht mehr so einen Kram gemacht und berechne gelegentlich auch schonmal die Wurzel aus 1, aber wenn

1m=15px

dann komme ich bei 300px/s² auf 20m/s² ... was ziemlich hoch ist und auch nicht 15 :D

ah sorry falsch geschrieben, ich meinte nicht 15m/s² sondern 15px/s².

was natürlich auch blödsinn ist, danke max. 9.81m/s² sollten also (9.81*15)px/s² im quadrat sein. also etwa 150px/s²...
aktuell habe ichs auf 600px/s² hochgeschraubt, weil es sonst zu lahm ist.

ich mach wohl noch immer was falsch, aber ausschauen tuts eigentlich gut...

Also Ich kenne zumindest den Effekt, welcher bei mir zumeist daran liegt, dass man sich ja in einer Einheitenlosen Welt befindet.
Woher kommt denn die Erkenntnis, dass 1 Meter 15px sind? ... also vor allem wo ist die Referenz zu dem einen Meter. Nur weil man sich denkt, dass es jetzt ein Meter sein könnte und nachmisst und auf 15px kommt, ist es ja noch lange nicht ein Meter.
Aber am Ende ist es ja auch Wurscht. Wenn es sich mit 600px gut anfühlt, dann ist dein Meter halt 61px. Wir befinden uns hier in einem Spiel. Es muss sich gut anfühlen. Ob es jetzt eine Parallele zur Wirklichkeit darstellt, ist eigentlich komplett egal, solange du keinen Simulator erstellst.

die 15px sind eine schätzung, wird z.b. für die kmh anzeige verwendet. evtl. irritiert mich auch die perspektive, ich habe mal auf 400px/s² reduziert.
naja, es gibt noch viel grössere probleme als die physikalische korrektheit, zumindest habe ich verstanden wie es sein müsste :)

hatte lust was zu probieren. jetzt gibt es reifenspuren auf der strecke. sie sind momentan persistent, was evtl. zu problemen führen könnte wenn das rennen zu lange geht. hab das aber noch nicht ausprobiert/abgesichert.

Die Reifenspuren sehen sehr geil aus!

danke schrompf!

mit der optik bin ich sehr zufrieden, performance ist ok, aber wie immer nagen zweifel. wenn man ewig lang rumfährt gibts immer mehr polygone. ich habs mal auf 20k schleifstückchen beschränkt.
bei nem rennen mit 10 autos und 5 runden bin ich auf etwa 2k gekommen. muss reichen. ansonsten bleibt mir nur eine lösung bei der ich nach und nach wieder elemente ausblenden muss.

ich wurde darauf aufmerksam gemacht, dass meine farben ziemlich grell sind. ich habe jetzt die shader mit einer art desaturation/colorizierung ausgestattet. das erlaubt mir die farben abzuschwächen und zu verändern.

seit ich das menü neu gemacht habe, gab es keine möglichkeit mehr die tasten einzustellen. wurde jetzt wieder ergänzt im neuen look. ein problem wurde mir bewusst, als jemand mal das spiel versucht hat: die meisten werden die pfeiltasten verwenden und im bereich space/x nach weiteren funktionen suchen.

die tastatur habe ich von anfang an auf 4 spieler ausgerichtet. der einzelspieler konnte nach belieben alle einsetzen (also z.b. wasd, ijkl, oder pfeiltasten für die richtungen). jetzt habe ich noch ein fünftes layout eingeführt, das auf einzelspieler ausgerichtet ist. dies hat zu einem weiteren problem geführt: die keyboard layout überschneiden sich bei den pfeiltasten. die funktion bleibt allerdings gleich. aber es ist schnell mal möglich, dass die gleiche taste für verschiedene aktionen verwendet werden könnte. diese zwei fälle musste ich irgendwie lösen:


grün: die tasten werden auf gleiche art für zwei verschiedene layouts verwendet
rot: die tasten werden mit wiedersprüchlichen funktionen belegt

so wird dem user immerhin ein problem angezeigt, die lösung ist es noch nicht

immer noch vorwiegend am zeug aufräumen. aber hab noch was zum spass getestet. die spinnen wurden als umgebungsobjekte mit simpel-ki um die strecke positioniert und watscheln in der gegend rum. leider war ein animiertes gif 20mb gross, das wollte ich keinem antun.
vielleicht sollte ich doch kein rennspiel machen, sondern eins wo man spinnen abballern kann?

… oder überfahren! Allein diesen Schnappschuss war das Experiment ja schon wert …

Ich finde, Deine Landschaft sieht echt geil aus. Du solltest wirklich einen Shooter bauen :-)

Der Asphalt stinkt dagegen leider ein wenig ab.

marcgfx hat geschrieben:vielleicht sollte ich doch kein rennspiel machen, sondern eins wo man spinnen abballern kann?

Oder beides :D

@krishty: überfahren finde ich jetzt noch ne geile idee! danke für die netten worte, manchmal zweifle ich wieder am ganzen.

@schrompf: hast du ne idee wie ich den asphalt ansprechender machen kann? Im beispiel mit den spinnen ist eine der strecken ohne texturen.

mein problem ist, dass ich nicht weiss, wie ich die textur sinnvoll dem streckenverlauf anpassen kann, ohne dass ich wieder verdammt viele überlappungsprobleme bekomme. aktuell wird einfach die textur planar draufgeklatscht und via noise mit einer zweiten vermischt (auf höchster qualitätsstufe). dazu kommt noch, dass alles zufällig generiert wurde, ich habe kaum künstlerischen einfluss.

@joggel: darauf wirds wohl rauslaufen :) aber erst muss ich mal eine sache zuende bringen. danach habe ich theoretisch eine gute basis um weitere spiele zu erstellen.

Du könntest mit der gleichen Methode mit der du den Mittelstreifen ziehst ein paar dezente Fahrrillen auf die Fahrbahn fabrizieren. Schau dir ein paar Bilder von einer Autobahn an, dann siehst du schnell was gemeint ist.

hab mir mal ein paar bilder angeschaut, ich weiss was du meinst. wenn ich es so wie die mittelstreifen mache, brauchts nochmal massig mehr polygone. das überlappungsproblem bleibt ebenfalls. meine fahrbahn hat leider einige sich selbst überlappende stellen, das kann ich nur vermeiden, wenn ich noch viel mehr einschränkungen mache. damit werden die strecken langweiliger.

am geilsten wäre es ja, wenn ich einfach mit nem shader anhand von der position auf der strecke ein bisschen eindunkeln könnte. habs mal so umgesetzt, dass einfach der rand der fahrbahn nach schwarz fadet. dann sieht man das überlappungsproblem von dem ich spreche.

hat mir jetzt keine ruhe gelassen... :P
hab mal was versucht, benutzt halt viel zufall. das ergebnis ist solala, aber es gibt vielleicht mehr ein gefühl für die streckenführung? die streifen kann ich evtl. mit noch mehr parametern an gewissen stellen verstärken.
was denkt ihr?

open links ist das original

Ich finde, das ist bereits ein gewaltiger Fortschritt zu dem (subjektiv empfundenen) einheitsfarbigen Asphalt vorher. Besonders rechts unten gefällt mir sehr - zwar unrealistisch, aber eine deutliche Strukturierung entlang der Fahrtrichtung, was klare optische Signale für den Spieler gibt. Und sieht cool aus :-)

gut zu hören, dann kann ich in der richtung mal weiterentwickeln. für asphalt habe ich ja dann ne lösung :)

bei den strecken mit "dreck" und verlauf nach aussen geht diese technik aber leider noch in die hose, sieht zu strukturiert aus. ich hatte früher grad für die dreckstrecken noch eine andere lösung (war eigentlich ein bug), die ich aber wieder rausgeschmissen habe um andere probleme zu verschleiern... wenn ich nur noch wüsste wie ich das damals falsch gemacht habe :D

Japp. Baschd :)

Mit etwas Struktur in Fahrtrichtung sieht das tatsächlich viel besser aus. Überhaupt, was sich da inzwischen mit Landschaft etc. grafisch entwickelt hat, gefällt mir sehr gut, hat einen tollen Stil.
Die weißen Streifen in Fahrbahnmitte könntest du noch etwas verblassen und maskieren, werden ja auch oft überfahren. Die wirken noch zu dominant finde ich.
Bei überlappenden Fahrbahnen und engen Wenden könntest du auch noch hier und da Wendeposten und Betonabgrenzungen zwischen den gegenläufigen Strecken berechnen - das hilft dann auch noch bei der Streckenführung. Natürlich kann ich nicht beurteilen, ob solche Hindernisse spieltechnisch passend sind.

danke tiles/joeydee :)

bzgl streifen in der mitte, macht sinn. kann da noch nen alpha-wert einfügen :)

die streckenabgrenzungen habe ich mir immer wieder überlegt, es gibt aber ein punkt der mich immer wieder davon abgehalten hat: mein komplettes physik system beherscht momentan nur kreise :P ... nicht rotierte rechtecke waren auch mal dabei, aber der code ist ausgeklammert. runde banden-elemente sind irgendwie komisch.
wenn ich rechtecke hinzufüge, müsste ich eigentlich die fahrzeuge darauf umstellen. ausserdem muss ich dann neue berechnungen für rechteck-rechteck und kreis-rechteck kollisionen machen. sagen wirs mal so, gibt viel aufwand. damit wärs aber nicht getan. um sinnvolle positionen für die banden zu berechnen müsste ich die streckenführung analysieren und herausfinden wo ich sie platzieren soll. am sinnvollsten wäre warscheinlich auf der aussenseite von kurven. dann gibts noch bereiche wo ich definitiv keine platzieren darf, bei überlappungen. ich könnte einfach die bereiche die doppelt von der strecke bedeckt werden markieren und ausschliessen.

für den moment lasse ich das glaube ich einfach mal weg und versuche das was ich habe möglichst schön zu machen. ich verliere mich eh schon voll in den details...