[MUD-Dev] Client side prediction

[Koster]

> -----Original Message-----
> From: Ola Fosheim Gr=F8stad [mailto:olag at ifi.uio.no]
> Sent: Monday, February 21, 2000 2:58 PM
> To: mud-dev at kanga.nu
> Subject: Re: [MUD-Dev] Client side prediction
>=20
>=20
> "Koster, Raph" wrote:
> >  Ola wrote:
> > > Are you by "dead reckoning" suggesting implementing all=20
> the physics in
> > > the client? I've spent too much time thinking about this, and =
I've
> > > reached the conclusion that the problems that are=20
> associated with this
> > > approach are too many and the benefits are too few.
> >=20
> > You should look at what games like Air Warrior and Warbirds=20
> do. There's
> > well-known solutions out there for minimizing bandwidth and=20
> using dead
> > reckoning. The issues you describe mostly don't apply...
>=20
> You know, chosing open-space examples are not a very good=20
> idea when you
> try to short-circuit a discussion. Come with some good examples where
> objects bounce, are nearby and you have approx one second lag. Then
> address the issues one by one.

I certainly did not mean to short-circuit the discussion. All the first
person shooters have to deal with this situation. They generally don't
handle real well up to 1 second of lag though--actually, I don't know =
of
anything that does handle that really well, it's always noticeable. :) =
FPSes
use simialr sorts of approaches to what I was describing for the flight =
sim
online games (which handle furballs of several dozen planes in close
proximity btw--and Air Warrior first launched with this sort of =
capability a
dozen years ago, when modems were much punier). Microsoft's Allegiance =
is
another example.

It is not a matter of implementing all the physics in the client. You
selectively implement the aspects that are critical to having seamless
presentation for YOUR client.

> Yes, you can obviously cripple your design so much that you=20
> only have to
> send one message every ten seconds. If that is what you want?

No, not at all. But for example, for something that is far away, you =
may
want to give this level of update and let the client dead reckon in =
between,
until it vectors closer and necessitates faster updates.

> > There's a ton of stuff that you don't need to have be=20
> synched except in
> > terms of shared experience. It doesn't matter if the two=20
> observers are both
> > in exact synch as long as both actually get to see the event.
>=20
> That really depends. Many gameplayers in the 80's were pissed off
> because collision detection wasn't pixel-perfect... Again, I want
> examples where players don't get annoyed.

There's very few games that do collision on a per poly basis. They =
almost
all use bounding boxes, usually fairly inaccurate ones. Players are =
fairly
forgiving about that sort of thing, is my experience.

Let me give you an example. Let's say that I am a bystander watching =
Bubba
slice Buffy in two. I may not have Bubba's correct transform because =
it's
not as high priority an event, so Bubba is facing away when it happens. =
But
I DO have the packet that says that Buffy was chopped in half because =
that
is high priority. So I might as well spin Bubba around and display the =
chop.
It won't look like it did on another bystander's client, who may have =
had
all the info in the case, but it's good enough. We both saw Buffy get
chopped in half. Her corpse may have fallen at different angles on the
ground, too. We're not gonna compare notes most likely, so who cares?

To give a real-world example: EQ does fairly simple dead reckoning on =
the
client for its avatar motions. As a result, when things get laggy, =
other
people "pop" all over the place--guy you thought was running NW turns =
out to
have changed direction during lag and is now running NNW, to he =
teleports
sideways 20 feet--as the client resynchs. Players LIKE it a lot more =
than
having UO's situation where the client's display makes significant more
effort to be accurate and therefore lags when insufficient info is
available--because it means that *their experience* is smooth. They =
care
more about smoothness than accuracy.

-Raph



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev