Client side movement prediction

[foobarto]

Hi @ArenMook - this is a feature request

Right now it is up to the game dev to implement such feature but it would be nice if TNet would offer a basic version of such feature like that out of the box. Especially for anyone starting out with TNet or network programming in games in general. Right now everyone is left reinventing this wheel over again


A basic implementation of such prediction feature would involve knowing last position, direction and speed of an object and current position, direction and speed - keep updating position of the object based on "predicted" direction and speed.
When next update comes in interpolate to prevent jittering and keep predicting...

A very simple implementation of this would be a very valuable feature of TNet if built in. It would reduce the perceived lag of moving objects.

[djray2k]

The thing is it is very dependant on what's happening for each game. But I think a very simple example could be beneficial.

[Manmax75]

Client Side Interpolation and Prediction is something I covered extensively in my thread over here:

http://www.tasharen.com/forum/index.php?topic=5788.msg30798#msg30798

Of which you can find my interpolation and network time synchronization scripts.
I also developed client input prediction as well to handle player movements, but I never released it publicly as I felt it were too much of a pain and didn't work as nicely as I wanted it to. Mainly due to the fact that Unity is not capable of rolling back physics states and checking collision without time passing or progressing to the next frame.

But if you want interpolation my example work fairly well. Aren and a few others suggest different methods by only sending update packets when something important happens like a collision and maybe an update packet twice every second or so. Then "lagging" the renderer behind the physics object. Now this will work for a lot of games, but if you have a very physics precise game then my solution will work better. Just remember though that it has it's own pro's and con's and that anything in networking can always be a mighty challenge to overcome.

[ArenMook]

The "lagging" of the renderer behind the rigidbody is indeed the easiest way to do this. It's not prediction in this case, but gives the same smoothing results. It's also what the cube-creating example does.