[MUD-Dev] Client side prediction

Ola Fosheim Grøstad <olag@ifi.uio.no> Ola Fosheim Grøstad <olag@ifi.uio.no>
Tue Feb 22 12:28:24 New Zealand Daylight Time 2000


If it matters: my general position for all mud-dev discussions is that a
mud should gracefully handle 1 second of lag, and still hang on when you
get bursts of 3-5 seconds of lag. That's because I only care about
international interaction. I also care about average people, not
hardcore gamers...

"Koster, Raph" wrote:
> I certainly did not mean to short-circuit the discussion. All the first
> person shooters have to deal with this situation.

Oh yeah, that's intelligent interaction... :P Granted, not my primary
interest, but from what I know there isn't all that much interaction
between objects beyond bullets, and aiming tends to be sloppy.

> 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.

Don't know what "FPSes" are, but I disqualify regular flightsims for
this discussion because:
1. It isn't critical if they go on the left or right side of something.
2. Most objects are distant, thus changes are not critical.
3. They typically move smoothly.
4. They seldom bounce into each other, and if they do you have a
critical situation which you need to get confirmed anyway.

> 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.

Well, that suggests a world with little interaction between objects and
players. I don't mind some non-critical extrapolation in order to make
things more seamless. It is however my opinion that interesting
environments provide many situations which are potentially critical.
(because this is directly related to your ability to affect the world)

When I played with ideas for (explicit) subjective solutions it was in
order to maintain reasonable levels of interactivity in a lagged
environment. I got into a nasty mess, including a need to reevaluate
chains of events when packets arrive delayed and out-of-order. It turned
out to complicate things to a level that wasn't really suitable for a
single person project, and it didn't really achieve what I wanted to do.
In general I think hobbyist/independants are better off by focusing on
higher level representations of intentions such as discrete events used
in text muds (I attack you, I flee etc).

For close objects subjectivity is rather unfortunate because it reduces
the visual communication potential. Communication, interactivity,
co-operation and and the ability to affect the environment are for me
primary concerns. Entertainment and game play are just means to achieve
user-user communication and co-operation.

> 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.

Yes, I haven't said that you cannot use extrapolation in some cases. I
certainly wouldn't regularly update objects that are distant and in the
middle of the air in an outdoor environment. I just don't think it is
worth the trouble as a general solution. (At least not for the kind of
environments and experiences I am interested in). The simple reason is
that I view the modem/user-ISP as the bottleneck and lag as the real
enemy.  Optimization is only worthwhile in this real time environment if
it solves the typical "worst-case" scenario. The "worst-case" scenario
for a flightsim with a fairly static landscape isn't bad. 

> 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.

If they get in a hit when they shouldn't have, sure, but what about
missing when they should have had a sure hit.  Are you saying that
players are getting used to it, or are you saying that I am demented?
Because, the most angry outbursts I can remember is due to such things.
It can be measured in broken joysticks and smashed keyboards. (btw, it
was just an example of how small discrepancies between visuals and
outcome affects satisfaction).

> 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?

I don't really play games or muds much right now so maybe my memory is
blurred, but I've experienced and seen some terribly confusing
situations. If players don't communicate intensively or work in teams,
well ok, but that's not really what I want in the first place.  The most
confusing situations arise when you loose track of other people, or get
accused of doing something you didn't do, or get the wrong idea about
the situation. For example you pick up something because you don't see
the person that owns something, then you get accused of theft. Heck,
even linear interpolation as done in M59 is confusing.

I generally think that users are better off by either not dealing with
things explicitly or by understanding that the situation is fuzzy.

Of course, your example isn't really an example of the issue discussed.
I don't mind the implictness of higher-level events (such as you died)
with fill-in/in-betweening, that's actually what I want!! I mind the
misguided explicitness of dead reckoning (and lag, if I could assume 2K
bandwidth, 200ms ping, no packetdrops, then I sure as hell would make
bouncy environments with about 50 objects per scene).

> available--because it means that *their experience* is smooth. They care
> more about smoothness than accuracy.

What happens when you chase a player and there is a tunnel to the NW and
to the NNW?

Ola.





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



More information about the MUD-Dev mailing list