Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Zeitbasierte Frame-Updates Pro und Contra

Werbeanzeige

rewb0rn

Supermoderator

  • »rewb0rn« ist der Autor dieses Themas

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

1

15.02.2011, 10:44

Zeitbasierte Frame-Updates Pro und Contra

Hi zusammen,

in der Spieleentwicklung begegnet einem eigentlich ständig das Credo, man solle zeitbasierte Frame-Updates verwenden, statt statischen Updates. Das sei professioneller und angenehmer für den User. (Zeitbasierte Frame-Updates sind solche, bei denen man Objekte nicht um einen festen Wert bewegt, sondern diesen mit der Zeit, die für den letzten Frame gebraucht wurde, multipliziert, so dass sich das Objekt bei schnellen Frames genauso schnell bewegt wie bei langsamen)

Ich habe in den letzten Jahren viele Spiele entwickelt, beruflich und in meiner Freizeit, und ich habe immer wieder die Erfahrung gemacht, dass statische Updates mehr Vor- als Nachteile haben:

- Als Nutzer sehe ich keinen Usability-Unterschied ob das Spiel nun für einen Moment etwas langsamer läuft, oder ob ich durch Ruckler Reaktionszeit verpasse
- Als Entwickler wird der Code einfacher: Mir ist oft begegnet, dass meine Kollegen behauptet haben, sie hätten eine zeit-basierte Anwendung geschrieben, und bei näherem Betrachten stelle ich fest, dass das nur für einzelne, triviale Updates stimmt
- Dämpfungen (z.B. von Geschwindigkeiten) und andere physikalische Effekte lassen sich gar nicht so programmieren, dass sie für alle Frame-Intervalle gleich funktionieren, heißt also bei unterschiedlichen Frame-Raten fühlen sie die Applikationen unterschiedlich an

Ich überlege deshalb, in Zukunft vollständig auf zeit-basierte Updates zu verzichten, es sei denn, ich stelle vorher fest, dass im speziellen Fall zeitbasierte Updates mehr Sinn machen. Ich muss dazu sagen, dass es in meinem Fall vor allem um Flash-Games geht, die haben nämlich eine fest eingestellte Frame-Rate, die nicht überschritten wird, auch wenn der Rechner mehr leisten könnte. FPS Bremsen kann man aber natürlich auch in anderen Sprachen einbauen..

Wie seht ihr das?

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

2

15.02.2011, 12:50

Zitat von »rewb0rn«

- Als Nutzer sehe ich keinen Usability-Unterschied ob das Spiel nun für einen Moment etwas langsamer läuft, oder ob ich durch Ruckler Reaktionszeit verpasse

Bei Bildschirmen mit 200 Bilder pro Sekunde wird es auffallen. Aber schon 60 vs. 85 Bilder machen einen massiven Unterschied. Ähnliche Probleme gab es schon damals mit DOS-Spielen, den gleichen Fehler müssen wir 20 Jahre später nicht noch immer machen. Bei entsprechenden Animationen werden sich auch Ruckler auf die Geschwindigkeit des Spiels negativ auswirken, man braucht nur die "richtige" Animation und plötzlich wird sowas ziemlich unschön.

Zitat von »rewb0rn«

- Als Entwickler wird der Code einfacher: Mir ist oft begegnet, dass meine Kollegen behauptet haben, sie hätten eine zeit-basierte Anwendung geschrieben, und bei näherem Betrachten stelle ich fest, dass das nur für einzelne, triviale Updates stimmt

Dann waren deine Kollegen schlampig. Leider wahr.

Zitat von »rewb0rn«

- Dämpfungen (z.B. von Geschwindigkeiten) und andere physikalische Effekte lassen sich gar nicht so programmieren, dass sie für alle Frame-Intervalle gleich funktionieren, heißt also bei unterschiedlichen Frame-Raten fühlen sie die Applikationen unterschiedlich an

Seit wann das denn? Auch Dämpfungen lassen sich prima inAbhängigkeit der Zeit berechnen. Fluide hingegen bedürfen definitiv eine Zeit-Korrektur durch kurze Intervalle, das stimmt wohl. Generell gesprochen kann es durchaus sein, dass auch eine zeit-abhängige Berechnung eine zusätzliche Unterteilung der Zeit in Intervalle bedarf (ein hüpfender, nicht voll elastischer Gummiball z.B.).

Zitat von »rewb0rn«

Wie seht ihr das?

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.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Jonathan_Klein

Community-Fossil

Beiträge: 3 820

  • Private Nachricht senden

3

15.02.2011, 14:16

Ich weiß nur, dass Prince of Persia auf meinem Laptop ständig in ner anderen Geschwindigkeit lief (mal sehr schnell, dann in Zeitlupe), weil die Programmeirer das Timing versaut haben. Als Supportantwort kam dann "nicht für Laptopprozessoren ausgelegt". Super, dabei gehen alle anderen Spiele.

Solange es keine wichtigen Physikalischen Situationen sind, mach ich auch alles Frametime abhängig. Klar, man kann sagen, meine Spiellogik läuft konstant mit 30fps und mein Renderthread mit 150, aber wenn das Verhältnis mal ungünstig ist, wird es ganz schnell ruckelig. Und gerade bei sowas wie Mauscursorbewegungen merkt man schon, dass mehr FPS einfach direkter sind, als z.B. nur 30. Man sieht bei 30 nicht, dass es ruckelt, aber es fühlt sich schwammig an.
Allerdings würde ich wohl sowas einbauen, wie eine Begrenzung auf 10-120 fps. Damit die Berechnungen nicht all zu ungenau werden. (Man stelle sich vor, das Spiel hängt mal ne Sekunde, und die Kollisionsabfrage soll riesige Sprünge korrekt berechnen...)
Lieber dumm fragen, als dumm bleiben!

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

4

15.02.2011, 14:46

Wenn man es deterministisch haben will, dann funktionieren eigentlich nur fixe Updates. Allein schon wegen Floating-Point-"Phänomenen"!
Ich neige dazu, wichtige Dinge mit fixer Framerate zu simulieren und "unwichtige" wie z.B. Partikelsysteme zeitbasiert.
David Scherfgens Website | Konzentrationstest Polizei

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

5

15.02.2011, 15:26

Ich sehe das genau andersrum: Determinismus ist nur mit Zeit-Abhängigkeit gewährleistet. Dass da eventuell Unterteilung der verstrichenen Zeit in kleinere Frames durchgeführt werden muss, ist nur eine Konsequenz daraus, die mich bisher nie abgeschreckt hat. Mein Game kann 30 Sekunden hängen und ist danach genau da, wo es sein sollte. Mag für den User frustrierend sein, erlaubt ihm aber nicht, dass er mit Tricks das Spiel künstlich ausbremsen kann, was bei Scroll-Shootern oder Zeit-beschränkten Knobel/Geschicklichkeits-Games mit Highscore eine mMn wichtige Sache ist.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

NachoMan

Community-Fossil

Beiträge: 3 885

Wohnort: Berlin

Beruf: (Nachhilfe)Lehrer (Mathematik, C++, Java, C#)

  • Private Nachricht senden

6

15.02.2011, 18:04

Zitat von »BlueCobold«

Mag für den User frustrierend sein, erlaubt ihm aber nicht, dass er mit Tricks das Spiel künstlich ausbremsen kann, was bei Scroll-Shootern oder Zeit-beschränkten Knobel/Geschicklichkeits-Games mit Highscore eine mMn wichtige Sache ist.

das ist doch blödsinn. solang man keine multiplayergames entwickelt hat der spieler nur die möglichkeit sich damit selbst zu betrügen. da ists mir als entwickler scheiss egal. er ist selbst schuld wenns dann kein spass mehr macht. aber du verdirbst dem ehrlichen spieler damit vielleicht das ganze spiel.
"Der erste Trunk aus dem Becher der Erkenntnis macht einem zum Atheist, doch auf dem Grund des Bechers wartet Gott." - Werner Heisenberg
Biete Privatunterricht in Berlin und Online.
Kommt jemand mit Nach oMan?

rewb0rn

Supermoderator

  • »rewb0rn« ist der Autor dieses Themas

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

7

15.02.2011, 18:08

Das ist dann aber recht Genre-spezifisch BlueCobold. Bei einem Kartenspiel bspw. ist es viel vorteilhafter für den User, wenn er trotz 30 Sek. Hänger genau sehen kann, was in der Zeit alles passiert (mal ganz davon abgesehen, dass das viel einfacher umzusetzen ist, und das ist ja im professionellen Gewerbe, wo jeder Aufwand Geld kostet, nicht zu vernachlässigen). Dass meine Kollegen u.U. schlampig arbeiten habe ich übrigens nicht per se ausgeschlossen ;) Ist aber auch eine Frage der Zeit, und die ist eben meistens knapp.

Was bei Flash-Spielen übrigens noch dazu kommt, ist, dass die MovieClips, also die im Editor angelegten Sequenzen von Bildern, automatisch 1 Bild pro Frame abspielen. In meinem Fall ändert sich also mit zunehmender Frame-Rate auch die Geschwindigkeit von Animationen, was ziemlich hässlich ist. Da könnte man Workarounds bauen, aber Flash ist ja gerade deshalb so schön, weil vieles automatisch geht... Ich gebe aber zu, dass das für die allgemeine Diskussion eher nebensächlich ist :P

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

8

15.02.2011, 18:48

Zitat von »NachoMan«

Zitat von »BlueCobold«

Mag für den User frustrierend sein, erlaubt ihm aber nicht, dass er mit Tricks das Spiel künstlich ausbremsen kann, was bei Scroll-Shootern oder Zeit-beschränkten Knobel/Geschicklichkeits-Games mit Highscore eine mMn wichtige Sache ist.

das ist doch blödsinn. solang man keine multiplayergames entwickelt hat der spieler nur die möglichkeit sich damit selbst zu betrügen.

Ich habe für dich nochmal die wichtigen Wörter markiert.
Mal ganz davon abgesehen, dass du die Teile ignorierst, die darüber reden, dass das Spiel *nicht* von der Framerate abhängen sollte, weil das manchen Usern zu Recht den Spielspaß total versaut oder sogar unmöglich macht.

Zitat von »rewb0rn«

Das ist dann aber recht Genre-spezifisch BlueCobold. Bei einem Kartenspiel bspw. ist es viel vorteilhafter für den User, wenn er trotz 30 Sek. Hänger genau sehen kann, was in der Zeit alles passiert (mal ganz davon abgesehen, dass das viel einfacher umzusetzen ist, und das ist ja im professionellen Gewerbe, wo jeder Aufwand Geld kostet, nicht zu vernachlässigen). Dass meine Kollegen u.U. schlampig arbeiten habe ich übrigens nicht per se ausgeschlossen ;) Ist aber auch eine Frage der Zeit, und die ist eben meistens knapp.

Richtig, nicht jedes Genre braucht soetwas. Gebe ich gerne zu. Ich fände es aber gerade bei Geschicklichkeitsspielen schon blöd, wenn die Unterschiede zwischen 60, 80, 120 oder 200 Hz Monitoren das Spiel unspielbar machen, was letztendlich der absolut schlimmste Fall wäre meine Meinung nach.
Dass es eine Frage der Zeit ist, das ist klar. Software-Entwicklung ist ein Dreieck:
- Das Projekt bleibt im Zeitrahmen
- ... bleibt im Kostenrahmen
- ... ist fehlerfrei
Such Dir zwei raus, denn alle drei wirst Du leider selten bekommen.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

NachoMan

Community-Fossil

Beiträge: 3 885

Wohnort: Berlin

Beruf: (Nachhilfe)Lehrer (Mathematik, C++, Java, C#)

  • Private Nachricht senden

9

15.02.2011, 19:04

Zitat von »BlueCobold«

Zitat von »NachoMan«

Zitat von »BlueCobold«

Mag für den User frustrierend sein, erlaubt ihm aber nicht, dass er mit Tricks das Spiel künstlich ausbremsen kann, was bei Scroll-Shootern oder Zeit-beschränkten Knobel/Geschicklichkeits-Games mit Highscore eine mMn wichtige Sache ist.

das ist doch blödsinn. solang man keine multiplayergames entwickelt hat der spieler nur die möglichkeit sich damit selbst zu betrügen.

Ich habe für dich nochmal die wichtigen Wörter markiert.
Mal ganz davon abgesehen, dass du die Teile ignorierst, die darüber reden, dass das Spiel *nicht* von der Framerate abhängen sollte, weil das manchen Usern zu Recht den Spielspaß total versaut oder sogar unmöglich macht.


ist es heute schon selbstverständlich, dass man einen onlinehighscore und keinen lokalen einbaut?

ich mach meine spiele immer zeitabhängig, begrenze aber die frametime und framerate nach oben hin. so gibt es keine riesen sprünge, aber die spiele laufen in der regel auf jedem system gleich schnell.
"Der erste Trunk aus dem Becher der Erkenntnis macht einem zum Atheist, doch auf dem Grund des Bechers wartet Gott." - Werner Heisenberg
Biete Privatunterricht in Berlin und Online.
Kommt jemand mit Nach oMan?

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

10

15.02.2011, 19:15

Zitat von »NachoMan«

ist es heute schon selbstverständlich, dass man einen onlinehighscore und keinen lokalen einbaut?

Äh, ja!? Und was passiert mit einer Online-Highscore, wenn jemand lokal sein Spiel künstlich runterdrosselt? Richtig, er schafft viel mehr Punkte, als eventuell üblich sind.
Und dennoch bleibe ich bei meiner Meinung, ein Game sollte gleich schnell laufen, egal ob 20, 40, 60, 120 oder 200 FPS. Und alles davon kann vorkommen. Klar, nach oben kann man drosseln, aber nach unten?
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Werbeanzeige

Ähnliche Themen