Rolling out a ROApp - Programming GPS and OpenStreetMap Applications with Java - page 187

starts the game cycle for each round and all players in each round. The
running players get the chance to move (to a safe place) before the chasers
start moving.
In every round, every player is required to announce his destination (a
valid station on the map) where he is going to head next:
destination = currentPlayer.getDestination( time2move );
This ServerPlayer method is not just getting the identity of a player.
In this case, the player must announce his next move to remain in play.
Therefore, the client call is blocked for a well-defined time to move (in
the properties). If the player fails to submit the next destination, the
game branches o to the catch block of the TimeoutException . For a quick
implementation, the game designer can end the game in this case.
12.8.3 ROAF Reconciliation
The rule \every player is required to announce his destination" may sound
a little fuzzy in the context of a computer program. The reason behind
this rule is the reconciliation of the board-game constraints with a potential
real-world scenario.
When playing the board game, each person (i.e., operator) moves his
physical player from one station to a neighboring station during his turn.
For the board game, it makes no difference, whether the player is actually
moved or being picked up and set down on the destination. The only
thing that matters is the valid destination. On the other hand, the ROApp
needs to be designed without conflicts with real-world actions. Therefore,
LCPlayers can not simply jump from origin to destination. They really
have to move there and the task is to reconcile motion and duration within
the game rules.
The game rule dictates that the chasing players have to \hit" the running
player at a valid station. Since a computer needs precise instructions, this
means that the four double values describing the Position s of a runner and a
chaser have to match precisely. This is hard to achieve, since double values
are internally coded with binary fractions and can not always represent
decimal fractions precisely. So even parsing a decimal number from a string
can vary the actual value. This problem can be overcome by introducing a
tolerance of a few meters. This tolerance agrees with the fact that you have
to walk a few steps from a subway station to catch a cab. Even better, each
station should be dened by the area (polygon) dened by the subway's
platform, the bus station, and the taxi stand. One question remains: How
fast should the players move? In the real world, the question is \How fast
can a cab move conforming to trac rules, trac lights, and the trac
itself?