Lockstep RTS: in between updates for higher visual framerate?

Erik · 2014-02-16T20:50:08

Hi Im doing a lockstep-based RTS which steps every 50ms (20Hz). I might have to go up to 100ms steps (10Hz). In my lockstep-update i do everything including moving/rotating units and projectiles. As you may suspect this looks rather choppy. So i plan to add a in-between (between locksteps) update and run it every 20 ms (or whatever) and update positions etc to make it look more fluid. Is this a good idea? Should this update only change variables that are strictly for drawing purposes such as: pos // unit real pos used for collision and all simulation important stuff, updated in lockstep pos2 // used only for drawing, is updated in-between locksteps Example unit speed is 4 pixels/lockstep but i run the in-between update which moves it 1 pixels per update, and pos2 resets each "real lockstep" to ensure no desync between players. Or do i dare run a complete update some set number of times between each "lockstep update" (the only update where player commands are processed)? Thanks! Erik

Networking and Multiplayer Programming

Started by suliman February 14, 2014 10:24 PM

10 comments, last by suliman 10 years, 9 months ago

hplus0603

11,938

February 16, 2014 07:16 PM

The point I'm making is that, if you run the simulation at 60 Hz, you may also run the input at 60 Hz if you want, without having to send packets 60 times a second. The point of enqueuing them across time is that the latency from "giving command" to "command executed" would be less jittery -- jitter would be 17 ms instead of 100 ms.

It's probably fine to quantize command timesteps to 10 Hz, although I think the best players in the world may occasionally get close to that command rate.

enum Bool { True, False, FileNotFound };