[ENet-discuss] fps networking (Jacky J)

Ruud van Gaal ruud at racer.nl
Thu Mar 20 04:21:08 PDT 2008


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



More information about the ENet-discuss mailing list