How many game updates per second?

Question

What update speed should I run my fixed-speed game logic?

I have used 60 updates per second in the past, but this is difficult because it is not an even number of updates per second (16.666666). My current games use 100, but for most things this seems redundant.

Answer 1

None of the above. For the maximum possible gameplay, your game should be based on time, not on a frame. Frame lock works for simple games where you can configure the logic and block the frame rate. This does not work well with modern 3D headers, where the frame rate skips across the board and the screen may not be VSynced.

All you have to do is figure out how fast the object should go (i.e. virtual blocks per second), calculate the amount of time since the last frame, scale the number of virtual blocks to match the amount of time that then add these values ​​to the position of your object. Voila! The movement of time.

Answer 2

I used Quake3 to maintain the mod, and it was a constant source of custom questions.

Q3 uses 20 'ticks per second' by default - the graphics subsystem interpolates so you get smooth movement on the screen. Initially, I thought it was very low, but everything turned out to be in order, and in fact there are not many games with faster action than q3

I would personally go with "good enough for John Carmack, good enough for me"

Answer 3

I like 50 for fixed speed games. I can't tell the difference between 50 and 60 (and if you are making a game that can / cares, you probably should be 100).

you’ll notice that the question is “fixed speed game logic” rather than “draw a loop”. For clarity, the code will look something like this:

while(1) { while(CurrentTime() < lastUpdate + TICK_LENGTH) { UpdateGame(); lastUpdate += TICK_LENGTH; } Draw(); } 

The question is, what should be TICK_LENGTH?

Answer 4

Keep in mind that if your code is not measured before the cycle, not every game cycle will take the same number of milliseconds to complete - so 16.6666, which is irrational, is not a problem, since you will need time and compensate anyway . In addition, this is not 16.6666 updates per second, but the average number of milliseconds that the game loop should be aimed at.

Answer 5

Such variables are usually best detected using a guessing and validation strategy.

Implement your game logic in such a way as to update the agnostic (say, for example, exposing ms / update as a variable and using it in any calculations), then play with the update until it works, and then save it there.

As a short-term solution, if you need an even update rate, but without worrying about even updates per second, 15 ms is close to 60 updates / sec. Although, if you get along with both, your closest options are 20 ms or 50 updates / second, probably the closest you are going to get.

In any case, I would simply treat the time as double (or long with high resolution), and ensure the speed of your game as a variable, and not its hard encoding.

Answer 6

Ideal is to run at the same refresh rate as the monitor. Thus, your visual effects and game updates do not enter and do not coincide with each other. The fact that each frame does not last an integer number of milliseconds does not matter to you; why is this a problem?

Answer 7

I usually use 30 or 33. This is often enough to make the user feel the flow and rare enough not to overheat the processor too much.

Answer 8

Usually I do not limit the FPS of the game, instead I change all my logic to take the time elapsed from the last frame as input.

As for the fixed rate, if you do not need a high rate for any reason, you should use something like 25/30. This should be enough, and your game will become a little easier when using the processor.

Answer 9

Your engine should “tick off” (update) and draw at 60 frames per second with vertical synchronization (vsync). This refresh rate is sufficient to provide:

• low entry lag for responsiveness,
• and smooth movement, even when the player and the scene are moving fast.

Both game physics and rendering should be able to drop frames if necessary, but optimize the game so that it works as close to this 60 Hz standard as possible. In addition, some subsystems, such as AI, can approach 10-20fps and make sure that your physics is interpolated in time mode from frame to frame, for example: http://gafferongames.com/game-physics/fix- your-timestep /