[MUD-Dev] Client side prediction

Koster Koster
Mon Feb 21 17:51:03 CET 2000

> -----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
> "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 =
> > > 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...
> 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 =
anything that does handle that really well, it's always noticeable. :) =
use simialr sorts of approaches to what I was describing for the flight =
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 =
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 =
want to give this level of update and let the client dead reckon in =
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.
> 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 =
all use bounding boxes, usually fairly inaccurate ones. Players are =
forgiving about that sort of thing, is my experience.

Let me give you an example. Let's say that I am a bystander watching =
slice Buffy in two. I may not have Bubba's correct transform because =
not as high priority an event, so Bubba is facing away when it happens. =
I DO have the packet that says that Buffy was chopped in half because =
is high priority. So I might as well spin Bubba around and display the =
It won't look like it did on another bystander's client, who may have =
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 =
client for its avatar motions. As a result, when things get laggy, =
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 =
sideways 20 feet--as the client resynchs. Players LIKE it a lot more =
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 =
more about smoothness than accuracy.


MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the mud-dev-archive mailing list