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

ServerObject by its behavior. Technically, the RO might run stand-alone
on a PC, while the SO is running in a server environment.
Consequently, the server can sneak in local server objects created locally
inside the server logic. How about a PoliceCar pulling over speeding cars?
In the case of a game scenario, the local objects can serve as agents to
observe the client objects and report any misbehavior to the server logic.

Update: distributed real-world application. Prototyping is learning. In the
process, the architect can and should revisit the initial vision once in a
while. From the introduction, analysis, and implementation of Server
Object s, a ROAF law can be derived, which was loosely introduced ear-
lier: Each RO can only connect to one server at a time. This law is a
technical directive and aligns with the design of the Java language, where
each object can only inherit from one other object.
Semantically, this law is important to avoid conflicts in the simulated
world. Due to the design structure, where ROApps are combined into one
ROAF, any actor should only exist once. Otherwise, one RO could enter
two different ROApps (i.e., in London) and their outputs, the SOs could be
combined in a third ROApp. Then, the initial (driving) RO would face its
clones making identical moves. The server would have to disqualify at least
one of them, the warning would go all the way to the RO, which would have
no chance to react or to survive. Nevertheless, this law does not inhibit
multi-server scenarios since every RO can have multiple (cascaded) SOs.

12.8 The ROApp Scenario

12.8.1 The RandomPlayer Client
The identification and authorization handshakes are now in place. Since
the abstract LCPlayer can not be instantiated, the RandomPlayer serves as
an erratic client with a minimum (dumb) implementation to participate in
a game. The main method serves as the development environment to create
players, identify them, enter the server scenario, and play. The developer
can tune probabilities for every method, introduce delays, and raise com-
plexity with every development step. A RandomPlayerFactory can continue
to produce new random players with random IDs to randomly identify and
re-enter a game over the complete server uptime. Since RandomPlayer.main
takes care of registering the client, the random player instance can catch
the server callback by overriding the initialization to trigger the game entry:

public void init( GameSet gameSet ) {
super.init( gameSet ); // initialize LCPlayer ...
// ... trigger player initialization from server call back
// set random station and enter scenario ...
// delay method return during development