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!
