[ENet-discuss] fps networking (Jacky J)

[Jacky J]

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.

Ruud van Gaal wrote:
> What's so odd about not sending input? Once you get into the current methods
> used (prediction/interpolation and such) it becomes clear. There's quite
> some info on multiplayer methods available on the net, I found.
>
> For my racing game for example, no input is sent. Every client simulates as
> if it's a local game. Then, position/velocity updates are sent to the
> server. The server interpolates/extrapolates position data to come up with
> the car's current postion. It also replicates the updates through to other
> clients, who then also do a timescale of the position to get the current car
> state.
>
> Ofcourse sending input, having the server do the maths and send back the
> position results are better against cheating, but lead to lag, and for a
> racing game, hm.
>
> For slow framerates, well, internally for the 'physics' running, there is a
> fixed rate you should use, so framerate doesn't really matter that much. The
> server & clients (actually all clients) keep on interpolation their latest
> position data until the next update comes in.
> To prevent jumps when updates come in, I draw a spline for example that
> pulls the car gently to its new predicted position (that did take a lot of
> days and lots of thinking to get right; it's actually a spline that's
> entered halfway, something like that).
>
> The speed at which some drivers shift down before a corner (esp professional
> drivers) is so fast that a server roundtrip is unaccceptable for internet
> play.
>
> Hope that helps; you're not alone btw, a lot of people go through this it
> seems. Searching for prediction/extrapolation in combination with
> multiplayer on Google should get you far.
>
> Cheers,
> Ruud
>
>   
>> Date: Thu, 20 Mar 2008 00:33:00 -0600
>> From: Jacky J <flamuss at gmail.com>
>> Subject: Re: [ENet-discuss] fps networking
>> To: Discussion of the ENet library <enet-discuss at cubik.org>
>> Message-ID: <47E2051C.30507 at gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> What are you babbling about? Games like Unreal don't send input?... 
>> weird... so how does the server know how the client moves? Yeah...
>>
>> Can anyone answer the question? What happens when the clients 
>> drops to a low frame and tries to send input? Lee? I mean come on...
>>
>> Don't mean to sound like an ass but come on i asked a simple question.
>>
>> Looks like i'm on my own again..... like always
>>
>>
>> Steve Williams wrote:
>>     
>>> Games like Unreal and many other FPS games do not generally 
>>>       
>> send inputs over the network.  They send a requested position 
>> update, which the server processes, then the server sends 
>> back the actual position (after taking into account the 
>> requested position updates of all clients and AI characters). 
>>  The client takes the actual position, moves its player to 
>> that position, and continues.
>>     
>>> Client prediction involves the client assuming that the 
>>>       
>> server will agree with what the client thinks might happen, 
>> so while the server is processing the requested position 
>> update, the client is moving its player to where it thinks it 
>> will end up.  When the actual position is received from the 
>> server, the client adjusts its players position to match the 
>> position the server said it was supposed to be.
>>     
>>> This also allows dropped network packets to be handled 
>>>       
>> correctly.  You may see the player jump or snap to the actual 
>> position as given by the server after a dropped packet or 
>> two, but the positional updates take care of missed packets.
>>     
>>> --
>>> Sly
>>>       
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>