I've seen some varying tick rates used for RTS engines. Supreme Commander ran at a super-low 10 ticks per second. Is this normal for RTS engines, or do they normally have a higher tick rate?

  • \$\begingroup\$ What is tick rate? \$\endgroup\$ Commented May 2, 2012 at 22:20
  • \$\begingroup\$ @iamcreasy: The tick rate is the speed at which the game updates the physics and simulation state. \$\endgroup\$
    – DeadMG
    Commented May 3, 2012 at 3:09
  • \$\begingroup\$ What happens when hardware can't match up with it? Which one they prioritize, the simulation or the catch-up? \$\endgroup\$ Commented May 3, 2012 at 3:57
  • \$\begingroup\$ @iamcreasy the game will lag - at least as far as SupCom and Generals goes. \$\endgroup\$ Commented May 3, 2012 at 8:04
  • 3
    \$\begingroup\$ @iamcreasy The more detailed answer is that you should program and optimize your game so that a simulation tick always runs within a certain time budget. A game is a realtime system in this way; code that runs past its deadline is basically a bug. Of course it's impossible to be perfect and thus if a frame runs over the game will lag. But lagging and hitching are bad, and can be prevented by just writing code to a budget. (My job the past few weeks has been exactly this -- optimizing an RTS game to fit in framerate.) \$\endgroup\$
    – Crashworks
    Commented May 3, 2012 at 11:00

3 Answers 3


Most RTSes I've worked on (or seen the source code to) simulate at 25-60hz. Slower than that, and characters start to feel unresponsive to commands and the controls feel generally laggy.

It's fairly common to run some game components only once per N ticks, however — ie, to undersample them. For example, run AI at only 5hz while the rest of the game is at 30hz, so that AI only runs one out of six frames. Or you can "think" only ¼ of the entities per frame to balance load, stuff like that.

  • \$\begingroup\$ cpu heavy things like pathfinding could also benefit of being recalculated at very low rates \$\endgroup\$
    – tigrou
    Commented May 3, 2012 at 11:55
  • \$\begingroup\$ I don't think this is the right answer. He's asking about tickrate for physics simulations, not the framerate of rendering. \$\endgroup\$
    – ashes999
    Commented May 3, 2012 at 16:22
  • \$\begingroup\$ @ashes999 So am I. Simulation controls character movement. Character movement is triggered by user input. The interval between character movement timesteps -- in particular, the interval between when a "move" order is received from client and the character changes direction -- correlates to perceived input latency. We have found this in user testing with our MOBA-style RTS. \$\endgroup\$
    – Crashworks
    Commented May 3, 2012 at 21:19

If we're stritcly talking about physics and logic, a super-low tick rate is probably OK.

But I would recommend to run animations and movement at a smooth 30 fps, especially if the game is 3d, zoomable, etc.

  • \$\begingroup\$ Physics, notably collision related tics running at a slower rate than display gives quite strange results for displayed objects when position and movement are inferred. \$\endgroup\$
    – Coyote
    Commented May 2, 2012 at 22:24
  • \$\begingroup\$ Provided there are enough ticks, artifacts should be able to be minimised. \$\endgroup\$
    – MarkR
    Commented May 3, 2012 at 12:48

I assume that you're using a fixed-timestamp and variable rendering framerate, which is the sensible way of doing it on all systems nowadays.

I can't see a big motivation for running > 20 ticks per second, because graphics rendering will interpolate anyway, doing more logic ticks just increases CPU usage without making the game better.

If you are going to be "clever" about collision detection, etc, you might manage with fewer ticks per second. Maybe 5?

There just need to be enough ticks per second that objects can't visibly move through each other (or other artifacts) due to the granularity of the simulation.

It's unlikely that a player's action will be responded to instantly anyway, the player expects some degree of lag when ordering objects to do things.

Construction, or even a simple "move this to there", is likely to take at least 5 seconds of real-time anyway.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .