Jump to content

  • Log In with Google      Sign In   
  • Create Account


Lockstep RTS: in between updates for higher visual framerate?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 suliman   Members   -  Reputation: 521

Like
0Likes
Like

Posted 14 February 2014 - 04:24 PM

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



Sponsor:

#2 hplus0603   Moderators   -  Reputation: 4965

Like
2Likes
Like

Posted 14 February 2014 - 07:36 PM

You can make a difference between "displayed position" and "simulated position."

Specifically, you can update the "displayed position" each time you render (at whatever the render frame rate is,) but update the "simulated position" only during your lockstep update tick.

You can interpolate the display position between the previous and current simulated positions. This will add some display latency, but won't display anything un-truthful. This is great for RTS-es.
Or you can use a forward extrapolator, like the Entity Position Interpolation Code, to predict what the position/orientation will be for an object, and display to that, which will perhaps somewhat overshoot positions etc, but give the illusion of less display latency.
enum Bool { True, False, FileNotFound };

#3 suliman   Members   -  Reputation: 521

Like
0Likes
Like

Posted 15 February 2014 - 02:03 AM

Yes i understand the two variations but in general this is what needs to be done? (and the typical way to do it?)


Edited by suliman, 15 February 2014 - 02:05 AM.


#4 C0lumbo   Crossbones+   -  Reputation: 2119

Like
0Likes
Like

Posted 15 February 2014 - 05:58 AM

I believe that the most typical way to do it is to interpolate smoothly between 2 lockstep frames for rendering.

 

In the original post, you suggest having some special "in-between" sim steps that run at a higher, but still fixed, update rate. I think this isn't as good as the interpolation approach, as the interpolation approach allows you to smoothly render at any framerate.



#5 suliman   Members   -  Reputation: 521

Like
0Likes
Like

Posted 15 February 2014 - 06:34 AM

cool.

stuff like particles systems, would they not mess up the random seed (that i set at gamestart so each client gets the same random numbers) since they are framerate depandant (and may therefore use different amounts of random numbers) ending up in desyncing the clients? Havent investigated this yet.

 

Thanks!



#6 C0lumbo   Crossbones+   -  Reputation: 2119

Like
0Likes
Like

Posted 15 February 2014 - 08:49 AM

Usually you would have a separate random number generator for the lock-step part of your title than you use for anything that can be frame-rate dependent.



#7 Pink Horror   Members   -  Reputation: 1085

Like
0Likes
Like

Posted 15 February 2014 - 01:24 PM

(double post trying to edit my post)

Edited by Pink Horror, 15 February 2014 - 01:27 PM.


#8 Pink Horror   Members   -  Reputation: 1085

Like
0Likes
Like

Posted 15 February 2014 - 01:25 PM

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?

 
Your deterministic update can work however you want. If the way you execute one "lockstep" update is to step your game exactly 2 or 4 or whatever simulation steps forward, that doesn't mean you'll go out of sync. If you decide to calculate/present those 4 steps over time to the user as a form of interpolation, that's possible too. It sounds like, for your RTS, you would want to be to configure your lockstep and a multiple of your simulation's frame rate.
 
 
 

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)?

 
Yes.

#9 hplus0603   Moderators   -  Reputation: 4965

Like
0Likes
Like

Posted 15 February 2014 - 06:07 PM

In a typical RTS, the player commands are available for steps ahead of time -- you cannot proceed to step X until the commands are available for that step.
You can bundle multiple different step commands into a single packet. Thus, even if your network rate is 10 Hz, you may use a 60 Hz simulation AND INPUT rate, and simply pack commands for 6 different ticks into a single packet, and then queue them on the receiving side for the right tick.
enum Bool { True, False, FileNotFound };

#10 suliman   Members   -  Reputation: 521

Like
0Likes
Like

Posted 16 February 2014 - 02:20 AM

Would that be useful? If i receive 6 commands each 100ms (how fast will the player click?) how does it make sense to spread them out to each 20ms on the client side? You mean i log when they were actually clicked by the player in the first place? I dont think you need that kind of resolution on the commands in an rts.



#11 hplus0603   Moderators   -  Reputation: 4965

Like
0Likes
Like

Posted 16 February 2014 - 01: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 };

#12 suliman   Members   -  Reputation: 521

Like
0Likes
Like

Posted 16 February 2014 - 02:50 PM

Ah ok now i get it.

Yeah i think 10Hz commands are fine for the game im planning:) But i will keep your comment in mind






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS