Returns the number of game updates per second your game is designed for.
This isn't necessarily the number of frames drawn per second, which may be more
or less due to frame skipping and interpolation, but it is the number of times
your screen's update methods will be called each second.
You actually want to make this as small as possible without breaking your game's
physics and feeling of responsiveness to the controls. Remember, the display FPS
is different - you can interpolate frames for smooth animation. What you want to
ensure here is that the design fps is big enough that you don't have problems like
clipping through walls or sluggishness in player control, but not so big that the
computer is busy doing collision detection, etc., all the time and has no time
left over to actually draw the game.
I personally find 20 actually works pretty well, though the default set here is 60
due to how common that number is. You are encouraged to override this and use what
works for you.
The D Programming Language's Unofficial Docs
beta
Returns the number of game updates per second your game is designed for.
This isn't necessarily the number of frames drawn per second, which may be more or less due to frame skipping and interpolation, but it is the number of times your screen's update methods will be called each second.
You actually want to make this as small as possible without breaking your game's physics and feeling of responsiveness to the controls. Remember, the display FPS is different - you can interpolate frames for smooth animation. What you want to ensure here is that the design fps is big enough that you don't have problems like clipping through walls or sluggishness in player control, but not so big that the computer is busy doing collision detection, etc., all the time and has no time left over to actually draw the game.
I personally find 20 actually works pretty well, though the default set here is 60 due to how common that number is. You are encouraged to override this and use what works for you.