Re[2]: [GD-General] physics and networking

[Cruise <cr...@ca...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

> -- I wonder what most of you decide to do in your code regarding physics
> chain reactions of moving objects.

> -- Does server arbitrate all large to small physics, which rock or which
> object gets pushed or bounced or rag-dolled to which positions?
If it could potentially affect another client, then yes. "Effects",
anything that is mere eye-candy, can be generated entirely on the client.
Explosions, bullet effects, decals, etc.

> -- Player positions rotation, even player opening doors, isn't such a
> big deal. Player motion that causes motion and position changes on a
> chain of other objects is a big deal.

> -- In a perfect world, every position of every object that moves must be
> arbitrated by server. Any object that has the potential of blocking or
> bouncing or twirling or pushing another object which eventually blocks a
> player must be centrally arbitrated.

Correct.

> -- In the non-perfect world, the number of arbitrating entities becomes
> really large the more an application displays physics-ness in the world.
> Do all of you really arbitrate and (continually) broadcast all these
> moving dynamic objects big and small 's absolute positions and not
> client predict them at all?

Fortunately, scale works for as well as against. You only
need to tell each client about the things within the PVS. Naturally,
if you're game world is a huge flat savannah, then the PVS will be
quite large. But, hopefully, the game world will be correspondingly
larger, and the physics "density" (the number of things that need to
be tracked) less.

Also, many things are deterministic (or have known random seeds), and
don't need to be broadcast continually. Once the intial angle and
velocity of a grenade is known, for example, the clients can /usually/
work out the path themselves.

That doesn't always hold true, obviously, especially if you have a
highly interactive enviroment. However, you can get away with a lower
broadcast frequency. Player states are the most important. You can
predict most everything else "good enough" as long as you know what
the players are doing.

> -- Or do you client predict some and "backtrack" when the server
> disagrees with the prediction? What are your backtrack methods if you do
> client predict.

Yes. That way the player can play quite happily until the next
broadcast. The client can work on it's own data until such time as the
server's becomes available.

In Half-Life, backtracking simply resets the positions to the server's
version. Because there tends to be little in the way of moving
objects, and fewer of any size or speed, this is an acceptable method.
Every so often a player will "flicker", but people are used to that online.

If speeds are high, or many noticable objects are being predicated,
then you require something more subtle, such as bringing the positions
into line over several frames. This can result in things rolling up
hill, and other weirdness, so it isn't ideal either. There isn't really
a good answer, unfortunately.

There is another difficult choice, too. An uncorrected difference can
mean enough motion to take someone out of cover on the client, while
in fact they stopped. If the local player then shoots this projected
version, what do you do? If you use the client's version, players
complain about being shot "round corners". If you use the servers
version, then players complain about seemingly "invulnerable"
opponents.

Again, Half-Life recently switched to the first method from the
second, as in general, it makes life much easier for clients on slower
connections. They don't have to worry about "leading" or
second-guessing other players so much, as if they shoot the version on
their machine, then it counts as a hit, even if the player wasn't in
actuality "there".

> -- I gratefully await your experience in these areas.



[ cruise / www.casual-tempest.net / www.transference.org ]

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUAPWTXG/di0Z5STRufAQEhMQP/ZFXsb04tFoA+eulkpMSICWvaF/uIwqIi
rbbczKjsgi9kiTZQoGR9tW6HN9Ah1tU7hJKwJymOsx9noyHZ/nS0ELdstflFO/yr
Q+8ITO+w5ykQSeCh76PH4Ia1+TdtKitID1FVjD6i0to9ZKKqqTTZXxhxwiX2NiEm
elllfbtF3Ng=
=xCgb
-----END PGP SIGNATURE-----