Jump to content
  • Advertisement
Sign in to follow this  
Legendre

Client side prediction/simulation Question

This topic is 2270 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

1. Client A sends input to move at T0.
2. Server receives input at T1.
3. All clients receive the change at T2.

Question:

With client-side prediction, Client A would start moving at T0, client-side. All other clients receive the change at T2, so to them, client A only started moving at T2.

If I understand correctly, Client B will always see Client A's past position and not his current position?

How is this in sync? Edited by Legendre

Share this post


Link to post
Share on other sites
Advertisement
You understand correctly. There are three basic options for dealing with this:

1) Client A won't start moving on client A's machine (or anyone else's machine) until the command comes back from the server. This leads to input lag, but if you can hide this lag, this is the most robust option. All lock-step games, including RTS-es like Starcraft and Age of Empires, do this. They hide the latency behind the "Yes, Sir!" acknowledgement animation.

2) Client A will move ahead on client A's machine, and move behind on everyone else's machine. This leads to different views of the world, which may lead to "I shot you first!" arguments, but it's a reasonable option. Orginal Quake 2 did this -- you had to actually shoot ahead of the player you could see. An alternative to that is to resolve shots based on what the shooting player saw, by checking for past positions on the server -- original Counter-Strike did this.

3) Once client A starts moving on client B's machine, it is forward extrapolated in time, to show an "approximation" of where the player will be. This gives a reasonable view of the world for players that are already moving, but still has lag for commands. Additionally, it may display client A running off a cliff for a while on client B's machine, before the extrapolation notices that the player had turned. Tribes did this.

Share this post


Link to post
Share on other sites
I've always imagined that sending some sort of synced 'world time' value with each action would solve these issues. But never got around trying such a thing.

Would it fix all lag issues, you think?

As I'm thinking about it it's probably prone to hacking.

If that's not an issue, then there's probably also the issue that a lagging player will appear to 'teleport' to another spot. Edited by ProgrammerDX

Share this post


Link to post
Share on other sites
Thanks for the lengthy explanation! Much much clearer and detailed than what I got elsewhere.



1) Client A won't start moving on client A's machine (or anyone else's machine) until the command comes back from the server. This leads to input lag, but if you can hide this lag, this is the most robust option. All lock-step games, including RTS-es like Starcraft and Age of Empires, do this. They hide the latency behind the "Yes, Sir!" acknowledgement animation.



I am doing 1) for my 2D adventure/puzzle game right now. Input ---> Server ---> All Clients. So if the latency is 350 ms, players would press the "move right" key and wait 350 ms before he moves.

Was toying around with client-side prediction, but looks like it might be too much work to implement.

Share this post


Link to post
Share on other sites

I've always imagined that sending some sort of synced 'world time' value with each action would solve these issues. But never got around trying such a thing.

Would it fix all lag issues, you think?


The cause of lag is that information takes time to transmit between different places on the Internet. Adding an additional piece of information is not going to make the information take shorter time to transmit.
In fact, for two of the three options I outlined above, you need a concept of a globally advancing time frame to implement it. Only the "fire and forget, and everyone else is in the past" option *can* work without a global time refefence, but even that will run smoother with that reference.
Thus, a global time reference is a good idea for most networked games, but it doesn't solve anything by itself -- it just enables other ways of masking the latency.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!