# How do games implement client/server frame rate?

Do games have a frame rate at X fps that updates logic and also renders?

Or do games update logic at a much slower frame rate than rendering? Let's say 20-25 fps for logic, and 60+ fps for rendering.

I am writing a game engine and I am a bit confused on how frame rate is handled.

If I were to run logic slower than rendering, then wouldn't I just be wasting the rendering frames because it is rendering the same thing over and over...? Unless I also interpolate the rendering with a delta.

I have read some game servers run at a much slower frame rate (let's say 20 FPS), so shouldn't the client also run logic at 20 FPS?

• Different games do different things, this depends mostly on the kind of game you're writing. – tkausl May 20 '18 at 16:15
• I believe This post will help answer your question. – ThePumkinMelon Aug 7 '18 at 15:19

I have also read the same (that game servers run their logic at a slower frame rate). And Ubisoft was also telling people that if you use 30 fps and add some motion blur we can call our gameplay cinematic.

As you can see from the example below, the 60 fps ball (blue) looks much smoother than the 20 fps ball (red). Even though both balls are rendering at 60 fps, the red ball looks very jerky because it stays in the same position for three frames, then changes position by three times the amount. This results in a jerky, blurred appearance compared to the blue ball.

Here's the simple example talked about earlier:

var canvas = document.getElementById('game');
var ctx = canvas.getContext('2d');

var width = canvas.width;
var height = canvas.height;

function gameObject(color, startY) {
this.x = 0;
this.y = startY;
this.color = color;
this.update = function() {
// Reset the ball back to the left if it's over the right edge.
if (this.x > width) {
this.x -= width;
// The blue ball gets a 4-pixel head start each time it crosses, so cheat for red to keep them aligned.
if (this.color == 'red') {
this.x += 4;
}
// Just increment the position appropriately if the ball is still in the frame.
} else {
if (this.color == 'red') {
this.x += 6;
} else {
this.x += 2;
}
}
};
this.render = function() {
ctx.fillStyle = this.color;
ctx.clearRect(this.x - 14, this.y - 14, 28, 28);
ctx.fillRect(this.x, this.y, 14, 14);
};
}

// Objects will run at 20 and 60 fps respectively
var ball20 = new gameObject('red', 170);
var ball60 = new gameObject('blue', height - 170);

var counter = 0;
// Runs at 60 fps
function frame60() {
// Reset the counter every three frames.
if (counter == 3) {
counter = 0;
}

// Update the 60fps ball every frame.
ball60.update();

// Only update the 20fps ball every 3rd frame.
if (counter == 2) {
ball20.update();
}

// Render both balls each frame.
// The 20fps ball will render in the same place 3 frames in a row.
ball20.render();
ball60.render();
requestAnimationFrame(frame60);

// Update the counter at the end so the blue ball doesn't get a 2-frame head start.
counter++;
}

//physicsFrame();
frame60();
canvas {
border: 1px solid black;
border-width: 0 1px 0 1px;
}
<canvas id="game" width="340" height="250"></canvas>

• I don't know who edited my answer, but thanks a lot. At the time, when I first wrote this, I had the idea of proving that, visually, 60 fps and 20 fps weren't on par (unless you add some motion blur to hide the jitter). My example ended up being off with both of the sprites moving at the "same" speed. Anywho thanks for fixing and correcting my answer. – Kitanga Nday Aug 8 '18 at 1:15