Game Development Reference
In-Depth Information
3. A strategy is needed to collect all the objects that should be affected by server
physics and assign them to
PhysicsObjectControl
(unless this has been
done in
SceneComposer
already). Objects that should have server physics should
also have
serverControlled
set to
true
and a unique ID, which is known
by both the client and the server. The resulting spatials should be stored in the
physicsObject
class map, as follows:
bigBox.addControl(new PhysicsObjectControl(uniqueId));
bigBox.getControl(PhysicsObjectControl.class).setServerControllled(true);
physicsObjects.put(uniqueId, bigBox);
4. In the
update
method of
ServerPhysicsAppState
, we parse through the
values of the
physicsObject
map. If any of the item in
physicsObjects
has
PhysicsObjectControl
that
isServerControlled()
and their
isActive()
is
true
, a new
PhysicsObjectMessage
should be created
as follows:
PhysicsObjectMessage message = new
PhysicsObjectMessage();
5. It should have the ID of
PhysicsObjectControl
as
objectId
and
phys-
icsLocation
and
physicsRotation
of
RigidBodyControl
; refer to
the following code:
message.setObjectId(physicsObject.getControl(PhysicsObjectControl.class).getId());
message.setTranslation(physicsObject.getControl(RigidBodyControl.class).getPhysicsLocation());
message.setRotation(physicsObject.getControl(RigidBodyControl.class).getPhysicsRotation());
6. The message is then broadcasted to the clients.
We'll revisit the server code in a bit, but first let's look at what is needed for the client to
receive messages.
1. First of all, the client has to have
BulletAppState
set up.
2. Next, it needs to have knowledge of the objects to be handled by the server phys-
ics. If the objects are gathered from the scene, a strategy is needed to make sure
the IDs are the same, or they're read in the same order.
3. They should then be stored in the
Game
class as on the server.
