spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wie ich schon sagte: Die Notwendigkeit der Verwendung von Timeframe-basierten Simulationen ist hier bei uns im Hobbybereich zu 95% nicht gegeben. Generell nur bei einer sehr kleinen Spanne von Spielen ist das der Fall.

passed_time in meinem Beispiel ist übrigens *nicht* die Frametime, sondern die Zeit, die seit dem Start der Bewegung vergangen ist. Ich dachte die physikalische Formel für die abgelegte Strecke eines geradlinig beschleunigten Objekts sei so weit bekannt, dass sie jeder gleich erkennt.
Und in welchem Fall gibt es denn veränderliche Beschleunigungen? Bei einer Auto-Simulation vielleicht. Habe ich hier noch keine gesehen, sorry.

Danke übrigens für das "beschissen". Ich find's immer wieder gut, wie man hier dumm angemacht wird, wenn man mal die Wahrheit schreibt. Danke und viel Spaß noch mit dem Thema. Lasst die neuen Jungs im Forum doch weiter "x+=abc" oder "x+=abc*frametime" benutzen, wenn ihr meint, dass das besser sei, obwohl es in 95% der Fälle durch korrekte Zeit-Abhängigkeit ersetzbar wäre. Sorry, aber dieser Bullshit und diese hinterfotzige Art mit der man hier immer wieder beleidigt wird kotzt mich an.


@Nox: Die Schrittlänge ist bei diesem Ansatz irrelevant und das Ergebnis immer deterministisch und sogar numerisch stabil, ganz im Gegensatz zu den numerischen instabilen Varianten, die nur deshalb nicht aus dem Ruder laufen, weil große fixe Schrittlängen gewählt und die Fehler klein gehalten werden. Dennoch sind die Fehler da, im Gegensatz zu dem Ansatz, den ich *immer* verwende.
Das geht sicher nicht überall (Fluide, veränderliche Felder, gegenseitige Abhängigkeiten, etc), aber solch ein Gegenbeispiel ist mir HIER auf Sppro noch nirgendwo begegnet.

Naja, Du gehst die Leute aber auch ganz schön agressiv an. Mäßigung auf beiden Seiten wäre eine feine Sache, das hier ist ja schließlich keine Religion.

Ich würde da zwei grundsätzliche Herangehensweisen unterscheiden:

a) Grafik und Spielmechanik arbeiten synchron.
b) Grafik und Spielmechanik arbeiten unabhängig.

a) ist eine einfache Methode und dürfte der Standardfall für alle Spiele hier sein. Wenn die Grafik-Rate also mit der Spiellogik-Rate gekoppelt ist, hat man meiner Meinung nach keine Wahl, als zeitbasierte Simulationsschritte einzusetzen. Du kannst halt einfach nicht garantieren, dass Dein Spiel auf jeder Hardware genau die selbe Framerate erreicht. Schneller als eine Wunschrate von z.B. 60fps lässt sich durch ein schlichtes VSync erreichen - das ist sogar empfehlenswert. Aber da fängt der Ärger schon an - es gibt viele Monitore, die auch 70 oder 75fps schaffen. Und wenn Deine Zielgruppe zum Beispiel gern Laptops nutzt, die ja notorisch lahm sind, erreicht das Spiel vielleicht gar keine 60fps IN JEDER LEBENSLAGE. Also musst Du spätestens da flexible Zeitschritte einsetzen oder mehrere Zeitschritte pro Grafik-Update simulieren und hoffen, dass die Verlangsamung an der Grafik und nicht an Deiner Spiellogik liegt.

Ich würde in jedem Fall zu flexiblen Zeitschritten raten - es ist für 95% aller Vorgänge stressfrei umzusetzen - siehe BlueCobolds Formel - und kostet praktisch keine Rechenzeit oder Mühe beim Programmierer. Gleichzeitig umgeht man damit die meisten Arten von Ärger, die man durch verschiedene Rechengeschwindigkeiten der Zielhardwares bekommen könnte.

b) ist der Standardfall für Netzwerkspiele. Man kann es aber auch für Singleplayer-Sachen einsetzen, wenn man die optischen Ergebnisse ordentlich interpoliert. Eine feste Simulationsrate für die Spiellogik halte ich für (minimal) numerisch stabiler, aber ich behaupte, dass das für niemanden hier von Relevanz ist. Die Grafik kann dann beliebig schnell laufen, auch wenn es nicht mehr wirklich irgendwas bringt. Man sieht ja nicht mehr Details, egal wie schnell der aktuelle Rechner die Grafik aktualisieren kann. Für Netzwerkspiele würde ich trotzdem zu festen Zeitschritten raten, primär weil die Aktualisierung übers Netzwerk eh sehr viel langsamer und latenzbehafteter ist.

Übrigens ist bei all den Physik-Engines sowie auch bei eigentlich allen mir bekannten Onlinespielen die Spielmechanik-Update Rate einstellbar. Damit ist die unterliegende Logik eben doch zeitflexibel.

Dachte das Thema wäre schon ein relativ alter Hut

Dazu hier ein recht bekannter Artikel den man sicher mal gelesen haben sollte:

http://gafferongames.com/game-physics/fix-your-timestep/

Noch zu erwähnen wäre dass das UDK sowie Unity3D selbst auch noch mit DelteTime arbeiten so wie es hier kritisiert wird.

mfg Mark

Zitat von »Mastermind«

Zitat von »Schrompf«

Übrigens ist bei all den Physik-Engines sowie auch bei eigentlich allen mir bekannten Onlinespielen die Spielmechanik-Update Rate einstellbar. Damit ist die unterliegende Logik eben doch zeitflexibel.

Zwischen "beliebig aber konstant" und variabel ist ein unterschied wie Tag und Nacht.

Ansichtssache. Der Zeitschritt ist im ersten Fall jedes Frame der selbe, weil nur am Anfang einstellbar, im zweiten Fall jedes Frame ein anderer. Trotzdem wird der Zeitschritt jedesmal zur Programmlaufzeit bestimmt, die Formeln und Algorithmen müssen also entsprechend ausgelegt sein.

Die ganze Diskussion wegen numerisch stabil: Solange es Singleplayer ist, interessiert es doch keine sau, ob der Gegner jetzt nach ner Minute n Meter weiter Links und rechts steht. Der Spieler merkt den unterschied überhaupt nicht, also ist es egal.
Und wenn man jetzt ein Objekt hat, dass sich auf eine bestimmte Position bewegen soll, es die aber nie genau erreicht, wegen der krumme Zeitdeltas: Dann guckt man halt, wann es ein bisschen über die Position gerutscht ist und setzt es dann genau auf die Position. Wie sich das Ding dann zwischendurch bewegt, ist ja auch prinzipiell egal.

@Jonathan_Klein im Prinzip hast du recht, aber je nach Situation können sich die Instabilitäten schon bemerkbarmachen, indem z.B. der Sprung immer unterschiedlich lang ist (was ggf. schon nervig sein kann, wenn die Unterschiede sehr deutlich sind).

Zitat von »BlueCobold«

Die Schrittlänge ist bei diesem Ansatz irrelevant und das Ergebnis immer deterministisch und sogar numerisch stabil, ganz im Gegensatz zu den numerischen instabilen Varianten, die nur deshalb nicht aus dem Ruder laufen, weil große fixe Schrittlängen gewählt und die Fehler klein gehalten werden.

Schau dir bitte nochmal in Ruhe das an was "Mastermind" zum Thema "was passiert wenn sich die Startbedingungen (a,v_0,s_0) oft ändern" geschrieben hat. Weil im Prinzip ist es das worauf es hinausläuft. Das sich diese Bedingungen oft ändern ist eigentlich sehr oft gegeben, denn sobald der Spieler Steuerimpulse abgibt ändern sich die Bedingungen (was andere und ich schon mehrfach erwähnt haben). Wie die physikalischen Gegebenheiten aussehen ist durchaus bekannt und auch was du mit passed_time meinst.

Es geht mir nicht darum jemanden direkt anzugreifen. Es geht nur darum aufzuzeigen, wann ein bestimmtes Modell stabiler ist und wann nicht. Um es nochmal zusammenzufassen haben wir aktuell 2 "unterschiedliche" Formelsätze und 3 Vorschläge:

Formelsatz 1:
§v_{akt} = v_{alt} + a_0 \cdot \Delta t§
§s_{akt} = s_{alt} + v_{akt} \cdot \Delta t§
Formelsatz 2:
§v_{akt} = v_{start} + a_0 \cdot (t_{akt} - t_{start})§
§s_{akt} = s_{start} + v_{start} \cdot (t_{akt} - t_{start}) + a_{start} \cdot (t_{akt} - t_{start})^2§


1. Fixe Zeitintervalle "delta t" und Formelsatz 1:
Zeigt natürlich auch Instabilitäten, aber durch die feste Schrittlänge ist das Ergebnis nach n Schritten sehr ähnlich.

2. varibale Zeitintervalle "delta t" und Formelsatz 1:
Durch die variablen Schrittlänge ist das Ergebnis nach n Schritten sehr unterschiedlich (auch wenn insgesamt die gleiche Zeit §=\sum_i^n{\Delta t_i}§ zurückgelegt wurde).

3. varibale Zeitintervalle "delta t" und Formelsatz 2:
Annahme: die Startwerte ändern sich nie => es bleibt wunderbar stabil (Begründung siehe BlueCobolts Post).
Annahme: in jedem Frame kommt ein Steuerimpuls => der Ansatz wird identisch mit Ansatz 2 (Begründung siehe Masterminds Post).

Fakt: Die Wahrheit liegt zwischen den beiden Annahmen. Sprich je nach Steuerimpulsrate des Spielers bzw. Interaktionen mit anderen Objekten (Kollisionen etc.) wird das Ganze instabil.

Zitat von »Jonathan_Klein«

Die ganze Diskussion wegen numerisch stabil: Solange es Singleplayer ist, interessiert es doch keine sau, ob der Gegner jetzt nach ner Minute n Meter weiter Links und rechts steht. Der Spieler merkt den unterschied überhaupt nicht, also ist es egal.

Ist es nicht. Gegenbeispiele gibt es hier alle paar Wochen ("warum bewegt sich nichts, wenn mein Spiel hohe FPS hat?" oder "warum bewegen sich meine Spielfiguren unterschiedlich schnell auf verschiedenen Rechnern?"). Das beste Beispiel war damals noch auf developia, wo jemand eine iterative Steuerung eines Flugzeugs bauen wollte. Die Addition der Winkel, die jeden Frame stattfand war allerdings so stark numerisch instabil, dass das Flugzeug bei jeder Drehung anfing wild zu schlingern. Das wäre nicht passiert, wenn statt iterativer Addition jeden Frame eine vernünftige, zeitabhängige Berechnung der Werte basierend auf Startwert und vergangener Zeit stattgefunden hätte.

@Mastermind:
Na dann nenn mir doch mal ein paar Beispiele von Spielen, die auf SPPRO entwickelt wurden und mit veränderlichen Beschleunigungen arbeiten.

@Nox:
Da kann ich mir das Beispiel von ihm noch so oft angucken, wenn es *nie* vorkommt, dann ist es nicht relevant. Ich sagte aber auch schon, dass *falls* das tatsächlich der Fall sein sollte, man um eine iterative Lösung nicht herum kommt.
Und wenn der User alle 20 Frames (was immerhin nur eine drittel Sekunde ist und eine absolut unübliche Art auf der Tastatur herumzuhacken darstellt) eine entsprechende Eingabe macht, wo ist da das Problem? Das ist für meine Methode dennoch absolut nicht relevant. Es macht keinen Unterschied für meine Methode, ob so oft Änderungen erfolgen oder nicht. Es funktioniert, ist numerisch stabil und zeit-deterministisch.