Spring-based handling of server corrections in physic sim?
Author
Hi!
Think of an autodrome-scenario, where there are numerous collisions
between user-controlled vehicles, and possibly some dynamic obstacles
like crates or tire stacks. I was thinking about the best way to
handle this scenario over a network, and was hoping to collect some
thoughts.
My assumptions are:
.) Only player input is tranferred from client to server, server
distributes game state to clients.
.) Client prediction is used as described in the well known "zen of
networked physics" paper
.) Objects must not visually penetrate, so some sort of client-side
collision detection & handling is a must.
My first approach was to have a complete dynamic simulation on each
client which is updated regularly to reflect the server
corrections.
Now a serious problem arises: If an object is corrected to a position
where it interpenetrates the locally predicted client object, the
local simulation explodes, yielding very dissatisfying jittering
effects. Interpolating the objects to their correct positions makes
things better but still not acceptable IMO.
Now my idea is to let the physic simulator handle the correction by
attaching springs to objects which pull them to their correct
positions. This way, all constraints resulting from contacts can be
resolved by the rigid body simulator, which should overall result in
better behaviour.
Of course measures must be implemented to guarantee stability,
e.g. above some error threshold springs should not be used.
I found no papers describing this method, and this makes me suspect it
somehow won't work out ;-) Any ideas?
regards cm
Here's how most games seem to do it: Everybody knows that crates shatter and barrels go flying when they hit a car. They don't actually have an effect on the local simulation of the car.
The thing is, the player is too busy busting through stuff to notice that the car doesn't go "bump" over those crates. Thus, they can be purely client-side, and don't need to match up between different clients.
Btw: From looking at it in the beta, I think this is what Auto Assault (the "MMO" car battling game) does with most of the destructible scenery.
The thing is, the player is too busy busting through stuff to notice that the car doesn't go "bump" over those crates. Thus, they can be purely client-side, and don't need to match up between different clients.
Btw: From looking at it in the beta, I think this is what Auto Assault (the "MMO" car battling game) does with most of the destructible scenery.
Author
You are right, that certainly is a good idea for obstacles. An entirely different beast, however, is the collision between two/multiple players, where no such approach is appropriate. Any other thoughts?
regards
cm
What a lot of people do is "add smoke and shake the camera" when a local collision is detected, or a collision is sent from the server. That way, you won't notice so much if the other player drives away unscathed.
What traditional military simulations do (they are peer-to-peer with no cheating problem) is to report a collision when sensed to the other guy, but let the other guy figure out whether to do anything about it. They also do that for weapons hits, btw.
What traditional military simulations do (they are peer-to-peer with no cheating problem) is to report a collision when sensed to the other guy, but let the other guy figure out whether to do anything about it. They also do that for weapons hits, btw.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
