Should frame rate affect the speed in a game engine?

I am writing a 2D game engine for fun. I am able to perform animation using the engine. However, if I change the frame rate (frames per second) the speed of the animation changes.

I have never used any game engine. I want to know whether other game engines handle this issue or not. If not, what is the ideal frame rate for a 2D game?

No, frame rate should not affect the speed - the gameplay will hinge entirely on their video performance, which is disastrous (even if you limit the speed, you can't control people whose systems will run the game at half speed).

You're experiencing this problem because you did something wrong: Your update/render routines run one after the other as fast as possible, with objects updating on a per-call basis (thus when the call speed deviates, so does theirs).

A time-based approach

The correct way to do this is to update objects on a per-second basis.

Consider a bullet for instance: Right now it probably knows how much it needs to move per frame. You need to turn this into how much it moves per second. How you do that is actually not too complicated.

First, your bullet's going to be updated more than once per second, so we need to actually update it every few milliseconds. Each time you update your physics engine, a certain number of milliseconds have passed since the last update: this is called the delta time, normally dt for short. The dt is determined before updating all objects, then all objects update using the same dt in order to keep in synch. The dt is generally passed as an argument to each object in its update call.

In fixed-step physics, the dt is a fixed number, whereas in variable-step physics, the dt varies depending on the actual amount of time since the last update (hence their names).

That brings us back to your bullet. It's been told to update with a dt of 16 milliseconds, for a physics engine updated 60 times per second: if the bullet moves 12 metres per second, you move it (16.0/1000.0) * 12.0 metres in this update.

• This approach is not ideal for numerous reasons. Gameplay will be non-deterministic, making multiplayer syncing much harder than it should be. If the update rate slows down enough, objects could tunnel through barriers, or collisions that should happen could be skipped over. – AttackingHobo Jun 15 '11 at 20:10
• That is why the time passed (dt) can be clamped, meaning from frames per second 5 - 1000, your engine works correctly. Below 5fps, you will get a slowing of time (ie the dt is clamped). – deceleratedcaviar Jun 15 '11 at 21:00
• @Daniel, It is still non-deterministic, making synced network simulations, or a replay system much more difficult to implement. And if you were to create a Rube Goldberg type puzzle game, after a few seconds the simulation will not replay the same way each time. – AttackingHobo Jun 16 '11 at 16:00
• Ah, for some reason I thought he was using a fixed time step with dt stepping... So yoir right, this is bad. – deceleratedcaviar Jun 16 '11 at 21:58
• To be fair, this approach is more than good enough for anything not performing complex physics, and has worked in many shipped games. So it's best not to get too worried about needing the fixed time step and interpolated rendering, etc. – Kylotan Jun 17 '11 at 11:19

The best way to make your game run the same speed on all systems is to use a Fixed Timestep.

With a fixed timestep, the game will always update at the same rate, no matter what the render rate is, and when using interpolation, it will look smooth even when the render rate is much higher than the update rate.

Here is an answer with resources on how to implement a fixed timestep.
Semi-fixed or Fully-fixed timestep?

Here is an answer that explains how to implement interpolation for movement and transformations.
How to Interpolate between two game states?

No it should not. One type of timing you can do in your game is frame-based timing. The idea is to let the game loop run as fast as your computer can run it thereby having the bast overall experience and you control the rate at which your simulation runs. Now you've decoupled your updating from rendering and have precise control over it.

In this scenario, your game loop can be running at say 60 fps on one machine and maybe 45 or something different on another, but your simulation will always run at the precise specified rate between them.