Well you certainly have much more experience with this than I do, but
please humor me and let me explain my thinking anyway. As long as
velocities are constant, we can predict everything with 100% accuracy
using extrapolation. We can predict position, we can predict collisions
with other vehicles, and we can predict collisions with stationary
objects. This is true no matter what speed the objects are going, as
long as the velocities are constant. So the only error that can
accumulate is due to unpredicted accelerations. And the only
unpredicted accelerations are due to player input, because, again, we
can predict collisions. So the error is a function of the maximum
acceleration the vehicle is capable of, which I gather from another
thread in this newsgroup is about 4G. If the distance error is only due
to acceleration, then we can calculate it using the familiar (x = 1/2 *
a * t^2) formula. The distance error caused by a 4G acceleration in 100
msec would be (sorry I can only think in english units)
x = 0.5 * (4 * 32.2) * (0.1)^2
= 0.644 feet.
So I am going to accumulate at most about 8 inches of positional error
over a 100 msec interval. And also this is not true positional error,
it is positional error between where the client thinks he is and where
the server thinks he is. The actual positional error at the server
would be a function of the update rate, not the latency. If a client is
sending 30 updates per second, which is not unreasonable for a modem,
the maximum error is
x = 0.5 * (4 * 32.2) * (0.033)^2
= 0.072 feet, or about 0.85 inches.
That doesn't seem all that bad to me. But admittedly the real issue is
client side error, because that's what makes it difficult to drive. And
the client side error could be doubled from what I have shown above if
both the client and the server are doing prediction, which is usually
the case. Also the client side error in position relative to another
player would be due to the sum of their one-way latencies, or IOW the
average of their pings. So I guess what I am saying is that even though
it is not an ideal solution, I think it would still be just as
applicable to a racing or even a flying sim as it is to shooters.
Regards,
Hal
> The classic problem is that unlike Quake people, racecars travelling
at 200
> MPH go about 90 m/s / 1000 = 9 cm per millisecond...
> so at 100 ms latency, the car will have travelled 9 meters (about 30
feet)
> since the last position update, even though they may be racing with a
1 foot
> gap between them...
> So you of course have to do extrapolation/prediction, but the
higher-order
> your extrapolation, the more wildly off your prediction will be if a
car
> makes a little twitch or correction (and hitting a wall or something
can
> effect a huge acceleration on the car)... it also depends on whether
you
> extrapolate in generic 3D space or in racing-line-space--these will
have
> different strengths and weaknesses...
> It still is a lot easier than writing AI, though, especially if you
drop
> modem support. Plus, LAN play is a good place to start, as you can
get away
> with pretty brain-dead approaches in this environment...
> Good luck--your Racer program looks pretty impressive already!
> -Dave Pollatsek
> MGI
> > > On Tue, 21 Aug 2001 21:00:25 GMT, "Haqsau"
> > > >Don't know how Ruud is doing it, but normally the host or server
is
> > the
> > > >one who tells the clients whether they have a collision or not,
for
> > > >precisely that reason.
> > > Right.
> > > And for latency, well, as the stuff is bounding box anyway,
there's a
> > > margin of error ofcourse. Don't know how incredibly bad it will be
> > > with modem connections. Perhaps I'd reduce the bounding boxes a
little
> > > bit so you collide relatively late.
> > Depends on how complicated you want to get. I'm not familiar with
> > coding for racing sims, but typically in shooters like the Quake
series
> > the server and all of the clients are each running in their own
frames,
> > asynchronously to all the others, and the engine interpolates or
> > extrapolates position and velocity as necessary to resolve them to
the
> > same time base. Because it is doing this, you can warp the time
base as
> > necessary to correct for latency.
