Networking with SpiderMonkey - jMonkeyEngine 3.0 - page 389

How it works...
Like in the previous recipes, it's the server that is in control of things. The client merely
says it wants to fire and any checks happen on the server side (although it's fine to mimick
verification on the client side to save bandwidth). The recipe doesn't contain any specific
verifications (a player can fire at any time), but this is explained more in Chapter 2 , Camer-
as and Game Controls .
Unlike in Chapter 2 , Cameras and Game Controls , we can't use the camera as input; in-
stead, we use the direction of the firing player and apply the yaw for up and down tilt.
Bullets are different on the server and client side. On the server, they are merely logical ob-
jects. Like the non-instant bullets from the Firing non-instant bullets recipe of Chapter 2 ,
Cameras and Game Controls , they work like slow rays, moving through the world until
they hit something or move out of range.
On the client, the bullet is a bit different from the server side, and is based on the control
pattern. The client finds out about the bullet in ClientMessageHandler , as the first
update is received. It sees if ClientBullet exists already, and if not, it will create a new
one. All ClientBullet does then is update the position in the controlUpdate meth-
od.
It's not the actual fire message that creates the bullets, but the first time a BulletUp-
dateMessage is received on the client. The client will keep updating the Bullet's posi-
tion, much like the player positions, until a message says it's no longer alive. At this point,
it will be removed.
The recipe currently sends all bullets to all players. As with players, this could (and prob-
ably should) be based on a need-to-know basis to avoid cheating (and excessive bandwidth
usage).