This question is, I suppose, not limited to Javascript, but it is the language I use to create my game, so I'll use it as an example.

For now, I have structured my HTML5 game like this:

var fps = 60;
var game = new Game();

setInterval(game.update, 1000/fps);

And game.update looks like this:

this.update = function()

This seems a bit inefficient, maybe I don't need to do all of those things at once. An obvious alternative would be to have more intervals performing individual tasks, but is it worth it?

var fps = 60;
var game = new Game();

setInterval(game.draw, 1000/fps);
setInterval(game.physics, 1000/a); //where "a" is some constant, performing the same function as "fps"

With which approach should I go and why? Is there a better alternative? Also, in case the second approach is the best, how frequently should I perform the tasks?

  • \$\begingroup\$ I can not do time trials and such so I can not give an answer, but just logical insight says you might be able to do parseInput() at a higher resolution if player input timing is key but maybe you want to look the draw time down to 20fps or some such and physics to 45 instead of 60fps. Maybe put the logic at 30fps.. You could in theory balance out the time needed to update each different section based on that. \$\endgroup\$ – James Apr 6 '12 at 22:16
  • \$\begingroup\$ Ok, but shouldn't the physics and logic be slower than draw? They are the ones that make actual changes, why make them if they wont be rendered? \$\endgroup\$ – jcora Apr 6 '12 at 22:25
  • \$\begingroup\$ My only point was to consider what needed to be updated that fast and what did not.. Most web animation is 24FPS for example (Flash's default if I recall?). Human reaction speed is .2 seconds. Splitting things up might just give you better utilization of your processing time is all. \$\endgroup\$ – James Apr 6 '12 at 23:40

A single task is definitely better.

You don't want nondeterministic behaviour.

While Javascript normally runs all your code in one thread and won't interrupt it (it will not preempt other JS code), there's no guarantee of how often, or in what order or proportion, several timers will really run. If one timer event is a bit slow, others might get skipped.

In general, you probably want to be using requestAnimationFrame for rendering, and doing your game logic however often suits you.

I use a fixed timestep with interpolation, because that way I get deterministic behaviour. I trigger it all from requestAnimationFrame, and look at the clock to see if enough time has passed to run another game-logic "tick".

  • 1
    \$\begingroup\$ Thanks! Should I really use that timestamp? I mean, what are the benefits? Smoothness? \$\endgroup\$ – jcora Apr 7 '12 at 7:55
  • \$\begingroup\$ I was giving an example of how I'd done it - I've no idea if this is the best way! "You don't have to follow me, you don't have to follow anybody. You're all individuals!" \$\endgroup\$ – MarkR Apr 7 '12 at 12:11

Dunno why but i can't add a comment so i had to use an answer >.>

For my game, I ditched set interval for request animation frame, If the user minimizes the browser the game will not continue running and so frees up your CPU which is why i preferred that particular method.


requestAnimationFrame is not your (logic's) friend recommends:

function render() {
    // Update the DOM, or Canvas, or anything else graphics-related
    requestAnimationFrame( render );

function gameStep() {
    // Update the player's location, health, or anything else logic-related
    // Process the game logic at a target 60 FPS.
    setTimeout( gameStep, 1000 / 60 ); 

Author says his physics plugin got better FPS after switching to this technique.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.