[ENet-discuss] fps networking (Jacky J)

[Lee Salzman]

Frame rate of the client doesn't matter really, since physics is 
simulated at the same rate no matter what. Packets may get sent less 
often, but this just means the server has to often play catch-up on the 
client simulating new stuff immediately since the client has banked up a 
lot of simulation credit.

Inconsistencies are always possible with any sort of client-side 
simulation against an authoritative server. The best you can do is find 
ways to make the snap tolerable, as the alternative is an intolerable 
amount of latency on actions. And there is always the deus ex machina of 
making particular actions that are problematic require a server round-trip.

Lee

Jacky J wrote:
> It just seems like so many things could go wrong.  The fact that the 
> client never has exactly the same state as the server means you could be 
> sending a completely different position.   Now i could see extracting a 
> direction based on two positions: the client's and the server's. That 
> way you could say "here is where i want to go", then the server could 
> try to move you there. But what if there's more than just position? 
> Rotational velocity, orientation, etc.. It doesn't quite work in those 
> scenarios. Then again i haven't tried it but for a fullblown physics 
> simulation where your input to your character is torque, seems like it 
> wouldn't work.
>
> Sending input results in lag? There's always gonna be lag to other 
> clients but if you do client side prediction you won't notice your own lag.
>
> The one benefit i see is the framerate issue.  If the server has the 
> correct "desired position" that the client sent, then it already has the 
> direction the client wants to go.  If the client sends packets at a 
> slower rate because of fps, then the server can just use the last packet 
> and interpolate.
>
> Yeah, it just gets frustrating when you ask a specific question but 
> don't get answered or get the run around.
>
>