Hi,

i'm making a game in UE4 only with blueprints currently and i'm really unsure about variable frame rates and time.

So how do games handle variable frame rates?

Let's say i have an endless runner game. It runs on 2 different computers.

On computer A it runs with 100fps (10ms till next frame).

On computer B it runs with 1fps (1s till next frame).

The runner now runs with a speed of 10.

To make it frame rate independent i multiply the speed with the time since the last frame aka delta seconds - cool!

I now have 2 problems:

Problem 1:

0.997 seconds after the game has started the user presses a key that increases the speed of the runner by 5:

On second 1.000 the next frame arrives in both cases:

Comp A (100fps): 0.01*15

Comp B (1fps): 1.00*15

Comp B has now an advantage cause the new speed gets multiplied by 1 no matter when the key was pressed.

Solution: Keys are polled outside of the game loop thus record the time of the key press and then multiply according (0.997*10 + 0.003*15 in 2nd case).

Another problem is that Comp A will be ahead of Comp B most of the time cause of the much faster frame rate (cause A jumps every 10ms and B only every 1000ms), but this is a problem of variable frame rate/delta seconds itself.

Problem 2:

There are turbo fields on the ground, when you run over them your speed is increased by 5 for 3 seconds.

Both run over them at 0.097 seconds after the game started.

Comp A (100fps): Turbo-Effect will be activated 0.100 seconds in

Comp B (1fps): Turbo-Effect will be activated 1 seconds in

How do games handle the time difference here or do they handle it all?

Only solution i can think of is to add a delay so that the effect only happens after total delta time >1 second (ofc. that would still "break" if < 1fps).

To stop the effect after 3 seconds i would add the delta time since start of the effect and if total delta time > 3 i would solve it like in problem one.

Thanks for any answers/suggestions

Fix Your Timestep

You can multiply every ingame movement, velocity etc. with your deltaT, based on a static aimed FPS. Sort of same'ish solution as the link above, but in my opinion (with my knowledge) a bit better to grasp: https://www.scirra.com/tutorials/67/delta-time-and-framerate-independence

The problem is that while it seems to usually work on the small scale, it doesn't work at all in the real world.

Machines with higher speeds can have much faster world processing. There have been games that suffered from this type of bug where higher performance machines could exploit details, like hanging on a wall after finding an errant polygon, or famously standing on a rocket as it flies across a screen, riding it like a skate board or surf board at great speeds.

Machines with lower speeds have more time between updates, and this too can be exploited. A large change in time means a very large multiplier. That makes it easy to hop over objects, to slip inside objects, or to avoid collisions. A simple hack is to stall the game the instant before an object collides with you. On the next update the change in time is large, the new position is calculated on the other side of the object, essentially making the projectile teleport around the player.

Really, fix your time step.

Also let me tell you, using a variable time step causes your physics to behave inconsistently with varying frame rate, which people who play the game at a high level absolutely HATE.

As an example, Super Meat Boy uses a variable time step, and people who speedrun that game constantly complain about it, because things that they do which work when the game is running at a full 60 FPS stop working consistently when the frame rate drops.

Doesn’t Unreal Engine 4 have a fixed time-step built in? I wasn’t aware you could even not have a fixed time-step with Unreal Engine 4.

Is this an actual problem you are having or just a conceptual one you thought you would have?

L. Spiro

Hi.

You don't gain much by allowing fast cpu's from processing the game logic more then 60 fps, So cap fast cpu's. You may want to render more times.

and Comp B is not able for your app.

Doesn’t Unreal Engine 4 have a fixed time-step built in? I wasn’t aware you could even not have a fixed time-step with Unreal Engine 4.

Is this an actual problem you are having or just a conceptual one you thought you would have?

L. Spiro

I'm making an endless runner kind of game. You get an Event tick node that also gives you the Delta seconds so that you can take the last frame time into account. I have the Tick hooked up to an Add Movement Node so that the player runs all the time:

(The Add Movement-Node already uses Delta Seconds so you don't need it here)

If you now look back at the problems i mentioned in the first post than i don't really understand how it couldn't be a problem?

Is there something wrong with my thoughts?