Physics with Bullet - jMonkeyEngine 3.0 - page 436

Getting ready
This recipe is for those who have a fundamental understanding of both Chapter 7 , Network-
ing with SpiderMonkey , and Chapter 8 , Physics with Bullet . This recipe will describe how
to implement networked physics in the networked fps that was discussed previously in the
topic. Since this is built on top of the existing framework, an AppState pattern has been
chosen to isolate as much of the physics code as possible. There will be some overlapping,
though.
Physics can be expensive as it is and has its own problems and requirements. Sending
translations and rotations for objects over the network with every tick will seriously affect
the bandwidth load. The ground rule is this: send only what you must.
Divide physics objects into those that you're interested in sharing and those that you don't.
In most games, this means separating those that affect the gameplay and those that don't.
For example, a meter-sized crate that can be climbed upon will definitely affect the game-
play. It has to be networked.
A bucket that can be kicked or small debris from an explosion do not affect the gameplay
and should only have local physics. It doesn't matter if they show up in different places for
different players.
The second part of the rule is this: send only when you must. There's no point in sending an
update for an object that is not moving.