Client prediction

Two ways:
1. Forward predict orientation just like position.
2. Use the last received value without prediction.

Because orientation has greater divergence impact than position (i e, will show overshoot more), option 2 is often the best choice.

I've allready implemented the #2 and it's ok for fast networks, but it becames a problem when the ping gets higher.

Are there more ways for forward prediction ?

Well, way 3 is using some form of spline (such as a cubic Hermite spline) to forward extrapolate the position/orientation. It has the draw-back of being wildly divergent over high pings, though.

The base problem is that you're not getting data quickly enough.

You could send data more often, even if you haven't received acknowledgement for the previous data yet. You can also decide to show remote entities at some "delayed" time -- i e, when you receive an update, you decide to render that object at the updated state some time in the future, and start interpolating between current state and future state over the given time interval. This will give a much more correct trajectory, at the expense of some display delay.

Ok, after what you've said and after I've reed some documents about prediction I think I'll try something like:

- client has the last known good orientation and forward predicts until another orientation is received
- I keep the orientation offset
- I continue forward predicting from my predicted orientation but I add the offset over a time (I'm thinking to use the time between the last two server updates or an average of the last n)

Did anyone tryed something like this before ? or do you think it will work ?

For position I don't have problems, since my velocity changes are not too fast and I think the position received from server will do just good.

I've tried something sort of like that.

One thing I slightly misunderstood initially: client prediction like that works only for the locally-controlled client. Other objects will look terrible under a high ping if you predict ahead using the last-known good orientation.

Quote:

Original post by Ozymandias42 I've tried something sort of like that. One thing I slightly misunderstood initially: client prediction like that works only for the locally-controlled client. Other objects will look terrible under a high ping if you predict ahead using the last-known good orientation.

And how was the mouse movement did you felt any lag ?

Yes, that's just for the local player (because I don't want the player to feel any lag on mouse movement ... it's a space sim and it will induce oscilation).
As for the other entityes, I think some interpolation will do just great.

So, the mouse movement indicates which way the player is facing, if I'm not mistaken? And in true FPS fashion, a quick spin of the mouse and the player turns until the moues stops then stops again?

Why not let the player be authoritative with exactly where he's facing? Just keep sending updates for facing to the server. Smooth out the other guys a little, but don't have the server actually change the way the client's facing unless some outside force affects it.

No, it's not just like a FPS.
A mouse move will inflict a rotation momentum, and if the mouse stops the player will rotate until it's inertia drops (helped by some fancy "inertial dumpers" to help the player a bit). A faster mouse move will just imply a bigger momentum).
And here are all my problems: if I have lag, the player will induce an oscilation trying to turn faster (involuntary).

I will give a thought to your ideea ... since I'm simulating physics on client too (for prediction) I might try to send the final orientation. I'm not sure (yet) what implyes that on server, however, the biggest problem might be with hackers :)

I will give it a try ... :) I've checked the code a bit and I think it will not give me too many troubles.

Thanks

Hrm...mouse motions are hard to predict, but whichever way you do it, the local player can still look pretty smooth with prediction. It's getting those pesky other guys to look good that's the problem.

Would it be a problem to display them with a few hundred ms of latency? You could make them smooth with that.

Actually, EPIC does a reasonable job of smoothing movement, even if it is extrapolated. The big problem is not smoothing, it's entities that are out of place (i e, overshoot a ledge, or run into a nearby star, or whatever).

About latency, I've tryed to simulate it (just forced the server to send updates at low frame rates ... 5-20 fps) and it felt strange, I'd like to get rid of that.

About EPIC, I've reed the document, and downloaded the source code (I'll study it a bit). Also I've found some other very interesting documents :) thanks

No, I mean, would it be a problem to add additional latency on purpose, not update frequency, but time before it displays.

If you know the next two or three updates instead of just the next one, you can smooth the other guy out pretty well.

Quote:

would it be a problem to add additional latency on purpose

You only need to know the next update. This means that the added latency on the client is the same as the update rate, so the total latency will be client send latency plus client->server latency plus server processing latency plus server->client latency plus client added latency. If the server sends 10 times a second, client added latency would be 100 ms in this case. This means that you can display entities following a path that you know they took, and won't see overshoots, at the expense of adding that bit of latency.

Often, that's the best thing to do, if you care about positional quality.

I think I can make a queue of server updates. But I'm thinking more and more at using client orientation and server validity checks.

About the server frame rates, I'm targeting a 20 network updates per second.

You'll need both, actually, for real smoothness. Here's how I see the whole chain.

Client A will send his movement to the server. The server's about 5 gamestate intervals away from him, timewise, so he predicts forwards 8 gamestates into the future. A transmits the exact position and velocity his unit is currently at.

The server maintains a pretty small input buffer, to help correct for the occasional bounciness of Internet transmission times. It holds off sanity checks until the appropriate game state, then checks, then processes. It sends updates for game states as soon as it's done processing them.

If everything's on schedule, client A is showing B's ship at roughly time 95, and he's got updates for times 100 and 105 when he receives an update for 110. He then plots a curve from 95->110 using 100 and 105 as middle points to get a smooth curve.

At least, that's how I'd do it. Of course, you're adding quite a bit of artificial latency. But it'd be pretty smooth.

I'm allready over-concerned about latency and I'll try to reduce it as much as possible.

However, I've just started the work again (after the hollidays) and I got much too tired than I expected so ... I had much less time for my side project.