Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 2 down vote favorite

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?

share|improve this question
What is tick rate? – iamcreasy May 2 '12 at 22:20
@iamcreasy: The tick rate is the speed at which the game updates the physics and simulation state. – DeadMG May 3 '12 at 3:09
What happens when hardware can't match up with it? Which one they prioritize, the simulation or the catch-up? – iamcreasy May 3 '12 at 3:57
@iamcreasy the game will lag - at least as far as SupCom and Generals goes. – Jonathan Dickinson May 3 '12 at 8:04
3  
@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.) – Crashworks May 3 '12 at 11:00

3 Answers

up vote 1 down vote accepted

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.

share|improve this answer
cpu heavy things like pathfinding could also benefit of being recalculated at very low rates – tigrou May 3 '12 at 11:55
I don't think this is the right answer. He's asking about tickrate for physics simulations, not the framerate of rendering. – ashes999 May 3 '12 at 16:22
@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. – Crashworks May 3 '12 at 21:19
up vote 0 down vote

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.

share|improve this answer
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. – Coyote May 2 '12 at 22:24
Provided there are enough ticks, artifacts should be able to be minimised. – MarkR May 3 '12 at 12:48
up vote 0 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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