Re: Dealing with latency extrapolation and overshooting

>
> On Tue, Feb 2, 2010 at 9:52 PM, Ben Parry <[email protected]> wrote:

I seem to remember a Half Life whitepaper where they said they establish a
> fixed lag between the internal game state and the world being displayed,
> since lag of all kinds is easier for the player to adapt to once it stops
> fluctuating (and also meaning there's no question of where to animate to).
>
> Apparently I can't remember its name or find it via Google though. They
> also talk about player input being timestamped for the game state being
> displayed when the player entered it, and the host re-simulating from there
> and sending out an updated game state.
>

Did you mean this?
http://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

>
I'm not sure that Half-Life adds a fixed lag; indeed, it seems to go out of
its way to have the client predict the actions of the player, and only
correct them if the server finds something egregiously wrong.

>
Adding a fixed latency to input would help to solve the problem, similar to
adding more momentum to our player movement - but at the cost of making the
player controls less responsive. (A cost we might have to go with anyway, to
some degree.)

- Blair

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com