spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

es ist nicht selbstverständlich.

wenn ein spiel so langsam läuft, dass die begrenzung der frametime greift, macht es auch keinen spass es zu spielen.(ich rede von einer begrenzung auf 0,1sekunden, also 10fps)
damit schließt man den fall von riesen zeitsprüngen aus und sorgt dafür, dass es in der regel immer gleich schnell läuft. bei onlinegames und -highscores ist es natürlich was ganz anderes.

Also 10 FPS ist immerhin nur 1/6 so schnell wie 60FPS. Das macht für Highscores massiv viel aus. Ich sehe jetzt auch kein wirkliches Problem, wieso man ein Spiel abhängig von der Framerate machen sollte. Es ist absolut kein Problem es anders zu konzipieren.
Das einzige Argument, was meiner Meinung nach *dafür* angeführt werden kann, das ist genauso das selbe Argument, was *für* die Verwendung von Singletons und globale Variablen spricht: Faulheit.

Selbst ohne Absicht zu cheaten ist z.B. ein Spiel mit 30 statt 60 FPS bei Abhängigkeit von der Framerate schon unzumutbar lahmarschig. Klar, das gilt nicht für jedes Genre, aber für Action/Jump'n'Run/Arcade gilt das absolut. Sowas will ich meinen Kunden jedenfalls nicht antun.

da hast du was falsch verstanden.
mein vorschlag ist das spiel im regelfall von der zeit abhängig zu machen. im extremfall(bei einer frametime über 100millisekunden) sollte die zeit mit der man rechnet, also die frametime auf 100millisekunden begrenzt sein. hab nie behauptet es wäre gut das spiel abhängig von der framerate zu machen. es ist einfach schlecht wenn ein spiel sich mehrere sekunden aufhängt(aus welchen gründen auch immer) und es einfach weiter läuft ohne, dass der spieler reagieren kann. das verhindere ich eben indem ich die frametime nach oben hin begrenze.

Dann hast du offensichtlich das Thema total verpasst oder wetterst gegen mich, obwohl ich genau das gleiche vorschlage (Game von der Zeit abhängig machen).
Aber was meinst du mit "Frametime nach oben hin begrenzen"? Wenn ein Game 10 Sekunden laggt, dann pausierst du es effektiv?

Zitat von »BlueCobold«

Ich sehe das absolut gegensätzlich. Iterative Systeme sind numerisch instabil und vom System abhängig, auf dem sie laufen. Fest codierte Werte sind noch viel schlimmer.
Nein, ich baue alles immer komplett Zeit-unabhängig auf. Bei 5 oder 10 FPS laufen meine Sachen noch immer mit den gleichen physikalischen Geschwindigkeiten, wie bei 200 FPS auch. Ich sehe auch kein Problem darin ein System von Anfang an passend zu entwerfen.

Du hast hier wunderschön schon die Antwort gegeben, warum rewb0rn und David recht haben.
Das Problem ist, dass bei unterschiedlichen Updatezeiten die Simulation unterschiedlich viele Schritte mit unterschiedlichen Schrittlängen macht, was das Problem der nummerischen Instabilität noch schneller zum Vorschein bringt. Daher wird bei großen Simulationen (Plasmen etc.) auch versucht die naiven Ansätze durch stabiliere Modelle zu ersetzen, aber das weißt du sicher.

Ich persönlich nutze ein beschränktes Updatesystem was per Sleep einfach die übrige Zeit verbrät, wenn er zu schnell war. Wenn er deutlich zulangsam ist, kommt es natürlich zu deutlich unterschiedlichen Schrittweiten, aber solange die Updates weniger lange als die festgelegte Zeit brauchen, bleibt die Schrittweite fix.

Zitat von »BlueCobold«

Wenn ein Game 10 Sekunden laggt, dann pausierst du es effektiv?

jup, genau das meinte ich, mehr nicht. du hast mich nur falsch verstanden. ich hab da nichts verfehlt.

Zitat von »Mastermind«

Blue Cobold redet diesbezüglich leider von einer Idealwelt ohne numerische Probleme.

Nein, ganz und gar nicht. Ich habe von Anfang an gesagt, dass iterative System numerisch instabil sind. Ich verwende daher keine iterativen Systeme, sofern das möglich ist.

Das üblichste Problem, welches ich bei Spiele-Entwicklung im Hobby-Bereich immer wieder sehe z.B. für lineare oder beschleunigte Bewegungen:
1) x += CONST_HARDCODED_VALUE;
2) x += variable * frametime;

Beide sind instabil (und #1 ist auch noch FPS-abhängig). Ich rate daher immer zu einer Formel der Art:
x = start_x + passed_time * ( velocity + 0.5 * passed_time * acceleration )

Das lässt sich oft gut auf andere Bereiche übertragen, sofern diese wirklich keine so komplexen Zusammenhänge bilden, dass Simulationen mit festen Time-Frames notwendig werden. Das ist aber in 95% aller Bewegungen und Simulationen bei Hobby-Spielen nicht der Fall, da es sich meist nur um bewegte Objekte handelt, welche sich nicht durch Kollisionen gegenseitig beeinflussen. Generell vermutlich bei fast jedem Arcade/Puzzle/Knobel/Jump'n'Run/Adventure/Casual.


@Nox:
Dir ist schon klar, dass Frametime-unabhängige Bewegung bei 60 FPS z.B. 100 Pixel pro Sekunde bedeuten kann und bei 30 FPS nur 50 Pixel? Das macht jedes Pong oder Jump'n'Run für'n Eimer. Sorry, aber wo haben da David und rewb0rn Recht? Da ist auch wohl kaum Numerik ein Problem, sondern die unterschiedlich schnelle Bewegung auf verschiedenen Rechnern. Numerische Probleme durch Multiplikation mit der Frametime klage ich IMMER und IMMER wieder an, weil dies eben NICHT die richtige Lösung gegen Framerate-abhängige Bewegungen ist.

@Nachoman:
Gut, aber so eine Limitierung lässt sich bei jeder Art der Implementierung verwenden, egal ob abhängig von der Frametime oder nicht. Spiel-Lags über einer Sekunde sollte man sicherlich irgendwie behandeln, falls das wirklich so kritisch sein sollte und sich umsetzen lässt. Bei einem Karten-Spiel oder SimCity müssen wir über sowas sicher nicht reden

Von Box2D bis Bullet nutzen alle fixed Timestep. Siehe z.B. http://www.bulletphysics.org/mediawiki-1…pping_The_World
Kontinuierliche Kollisionserkennung ist ziemlich unangenehm und bei langsamen Rechnern würde man die irgendwann benötigen. Sonst hauen dir alle Objekte durch die Wände ab, wenn dein alter Computer mal wieder vom Virenscanner übermannt wird.

@BlueCobold Dein Ansatz ist im Endeffekt auch iterativ, sobald sich die "Anfangsbedingungen" ändert. Für ein Spiel wo man Wegpunkte setzt, dauert es natürlich durchaus, aber für ein FPS,schnelles RPG oder Jump&Run endet es auch in vielen kleinen Iterationen. Dass der Ansatz durchaus eine Verbesserung gegenüber "variable * frametime" mit ständig ändernden frametime darstellt, stelle ich damit natürlich nicht in Frage.
Nebenbei ging es mir erstmal nur um das Thema "Determinismus" und das da die beiden recht haben. Denn nach n-Schritten mit gleicher Schrittlänge verhält sich das Ergebnis weniger chaotisch als bei einer Simulation mit variabler Schrittlänge.