Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Client-Side Prediction with Inertia-based Movement?


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
3 replies to this topic

#1 sufficientreason   Members   -  Reputation: 123

Like
0Likes
Like

Posted 03 August 2013 - 12:30 PM

Hi everyone. I'm revisiting an old project to write a networked top-down 2D space shooter. I'm using an authoritative server in a standalone C# application built on top of Farseer Physics and Lidgren, with a Unity client. Unfortunately, because of how big Unity is, and how much of a black box Farseer is, I can't really maintain determinism between the two (floating-point errors and drift, etc.), so I'm trying to simulate as little as possible on the client. The server has the whole physics world with all of the objects, but the client just has a physics world with just the ship being controlled.

 

I've been reading a lot of articles on client-side prediction, but I'm still having trouble with what seems like a basic question, and that's how to deal with C2S latency when movement has inertia. In theory, client prediction alleviates S2C latency because the server is just telling the client what the client already knows -- that you're moving. However, since my game deals with inertia and thrust, the actual time that the message to accelerate arrives matters a lot. If you have 200ms C2S latency, then when your message to accelerate arrives at the server, you're 200ms farther ahead along your current course than you were on your screen when you pressed the key to accelerate.

 

This is different from a normal shooter where you stop moving when you lift up the key. I'm somewhere between a racing game and a shooter in terms of user control. I've tried the the Unreal model and the great Gaffer on Games articles on prediction, but they don't actually seem to cover this situation. I can't really rollback the server for movement input because that means everyone will be snapping everywhere on every else's screen every time they change course. I've also reviewed EPIC, but since I'm using the Valve snapshot approach (100ms "artificial" lag to perform buffered interpolation), forward extrapolation doesn't seem to apply here -- the server is authoritative, so I don't want the server to be doing any extrapolating, and the client shouldn't need to extrapolate if it knows the input in the first place.

 

Is there anything I can do about C2S latency in this case? The normal "warm up time" it takes for the engine to overcome inertia does hide some of the lag, but at 500ms the ship just doesn't feel responsive enough compared to 0ms, and that doesn't strike me as being fair. Should I even bother with client prediction? Note that ship rotation is already client-side with server reality checks to make it as fast as possible, so this is just for thrust. Any help would be greatly appreciated. Thanks!


Edited by sufficientreason, 03 August 2013 - 01:10 PM.


Sponsor:

#2 ddn3   Members   -  Reputation: 1309

Like
1Likes
Like

Posted 03 August 2013 - 04:11 PM

If you want the server to be authoritative then you can't initiate the actual thrust until 1/2 ping time has passed locally (assuming symmetrical latency both ways), at which time you can assume that the packet has arrived on the server and it then will initiate the thrust command as well and prorogate that command + state snapshot to the other clients.

 

If it's just a simple 2D physics game you should be able to project the current state of the object to timeCurrent using the state snapshot + action command for the other clients. This is the same for any action you do, such as releasing the thrust etc..

 

good luck!



#3 sufficientreason   Members   -  Reputation: 123

Like
0Likes
Like

Posted 03 August 2013 - 06:07 PM

If it's just a simple 2D physics game you should be able to project the current state of the object to timeCurrent using the state snapshot + action command for the other clients. This is the same for any action you do, such as releasing the thrust etc..

 

Do you mean on the server side or the client side?



#4 ddn3   Members   -  Reputation: 1309

Like
0Likes
Like

Posted 03 August 2013 - 08:08 PM

The server is fully authoritative and doesn't do any projection, the clients which didn't initiate the action will receive a packet from the server on other players motions and they will have to forward project to get the "real" state, which is what they think the server is running. That way all clients will see approximately what it thinks is the "real" state of the server. 

 

So something like this on a timeline

 

T0 - ( Original Player presses thrust, sends off packet to server but does not execute thrust command locally yet )

T0 + 1/2 Ping - ( Packet arrives on server, server executes thrust command for OP, also OP executes thrust command locally, server sends out state update for OP )

T0 + 1/2 Ping OP + 1/2 Ping Receiving Player - ( Packet arrives to another client, that client forward projects to get the approximate realtime state of OP )

 

Hope that helps.


Edited by ddn3, 03 August 2013 - 08:10 PM.





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