Physics with Bullet - jMonkeyEngine 3.0 - page 441

How it works...
The first thing we did in the recipe was to lay some ground work by defining a new control
called PhysicsObjectControl to be applied to the objects that should be handled by
bullet physics. This control can either be added at runtime; alternatively, if Scene Com-
poser is used to lay out levels and scenes, it can be added to the objects beforehand. It's re-
commended that you define which ones should be handled by the server by setting
serverControlled on the relevant objects before they're being added to the scenes.
The ID should then be set in a deterministic way on both the client and the server when
they parse the scene for the objects.
The architecture to handle the physics might very well look different in another implement-
ation, but here, the AppState pattern was used so that it could be easily added as an ex-
tension to the existing framework from Chapter 7 , Networking with SpiderMonkey . In this
chapter, we didn't use any physics for the players but simply checked the height of the ter-
rain to find out where the ground was. Hence, we added an optional BetterCharac-
terControl instance to the player—again, a change that would still make it compatible
with the previous implementation. However, this was only added on the server side. For
client-side physics, a similar change would have to be made there.
The server will check every update and see whether any of the objects with serverCon-
trolled enabled is active and will send any updates to the clients. Actually, you could
leave out the physics all together on the client and simply update the spatial's rotation and
translation, if you wanted. This would lower the requirements on the client's hardware, but
this will only work if all of the physics are handled by the server of course.