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.
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.