Re: Dealing with latency extrapolation and overshooting
Blair Holloway <[email protected]>
| Newsgroups | gmane.games.devel.sweng |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Feb 2, 2010 at 9:05 PM, Joe Hegarty <[email protected]> wrote: > > The easiest thing to do is (as you termed it) give the player more > momentum, when they begin to stop, you synchronize a timer which says > “Player X will stop at Y time in Z Position”. So while they might reach the > position at slightly different times (they will stop faster on the client) > the actual position is always correct. > Adding more momentum is the more elegant way of solving it, and will look more visually correct... but add too much momentum, and it starts to encroach on gameplay. Responsiveness is desired here, so we'll have to experiment with how much momentum can be added before the controls begin to feel sluggish. > As a general rule, you should try and handle at least 200ms of round-trip > latency smoothly. > We're currently able to treat 200ms as our worst-case scenario, coincidentally. I've added code that forces the game to always run with this amount of latency during development > Are you using a client-server networking model or peer-to-peer? What type > of game are you developing? > It's a sports title. We're using a peer-to-peer model; if a user is in control of a player on the field, that user's console will send authoritative information about that player to all other consoles. Cheers, - Blair _______________________________________________ Sweng-Gamedev mailing list [email protected] http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com