Client side prediction

Hi,

I have a naive server implementation for my game and was looking to implement client side prediction. My main problem is that I have a ball object that all players interact with. The way it works at the moment is simply that the client sends input to the server, the server runs Bullet physics to determine the position, then the server sends the node positions back to the clients when it changes which then moves the models. I like this since it’s nice and clean, but it has latency issues.

I’m tempted to run Bullet on the client also and then send corrections from the server when the client gets out of sync. If I don’t have physics on the client I’m a bit stumped how to predict the movement of the ball (the character controller is simpler and I think I could do this). It’s important to keep the ball position in sync because a player should be able to bump into it and kick it etc.

The other question I would have is, without physics on the client how do you sync the movement between the physics on the server and the client, for example you can’t sync Bullet substeps if there’s no bullet on the client. I was trying to figure out the movement per input on the server by trial and error (logging the positions of the node on the server and working out an average) so I could implement that on the client, but that seems quite a slack way of doing it.

Any suggestions on the best way to do this?

Thanks,

I don’t see a way to do client side prediction without the client running the exact same physics code that the server is.

If you have not yet I recommend reading how Valve does it: developer.valvesoftware.com/wik … Networking

Yeah that’s what I thought originally, but grepping some old posts it seems enn0x is against that idea, but I was stumped how to sync it otherwise. Thanks for that link I haven’t seen that. I’ve read http://gafferongames.com/game-physics/networked-physics/ and http://www.gabrielgambetta.com/fpm2.html, the second I think is better at explaining the specifics of client side prediction than gaffer on games which is pretty vague on how to actually sync both sides, but is good otherwise (I’ve used it for naive server implementation so far).

That Valve article is interesting I’ll go read it now. Thanks for that.

Cheers,

Looking at this again I’m wondering how the tick is actually implemented. I was thinking of using ClockObject::getFrameCount on each machine, with the server framecount being authoritative. It would be nice to get the tick from bullet physics but I can’t see how to do that, looking at the docs.

Cheers,