Global Positioning System Reference
In-Depth Information
In a classroom situation, the class can be split into server and client
developers and receive server/common and client/common packages, re-
spectively. Since server and client software are separated, they can be de-
veloped independently. Each team can appoint a GUI developer to create
a GUI for server and client software, respectively.
Naturally all GUI developers can again form a team. In the best case
classroom scenario, there is a classroom with a connected PC pool and a
beamer. Since the beamer can serve well as a visual front end for the whole
class, the GUI team can attack the following problems.
Problem 13.2 (Create a server GUI.) The
main
method of
roa.ldn.server
.ServerEngine
is prepared to create a GUI with
srvEngine.createGUI()
.
Add a server window showing the server's bounding box, the network, and
the moving players.
A solution can be found in the
Navigator
software. Of course, there is
much more a GUI developer can come up with. Problem 13.2 is important
for the collaboration of all teams. Ideally, there is a beamer connected to
the server machine and everyone in the room can watch the current server
and game status. Note that the server GUI should not display a map image,
since the game is actually restricted to the network.
The
RandomPlayer
represents the minimum implementation of a player.
A programmer can take the player as is, set up the game server, and run a
first game round to make sure it works. Then he can start modifying the
player, run another game round, implement decision making, run another
round, etc.
RandomPlayer
s can always be used to fill in missing players until new
players start playing against each other. Finally, the developed player can
go online to challenge other players. With this development cycle, the
player can be validated at any time and provides motivation to drive the
development.
The ROApp developer can also configure
RandomPlayer.main
for any
number of required players and roles to improve the server logic step by
step. Clients and server can run on different JVMs connected by the net-
work. For the client player, the server should be set up to run on a separate
computer to start, end, and restart games over the entire development ses-
sion. The developer should not be able to and should not have to touch the
server at any time after its startup. Instead of modifying the server code,
the developer should create a \must have" list and communicate it to the
server team; that is the main idea and advantage of distributed application
development.
In a game of only
RandomPlayer
s, the developer has a hard time to re-
ally know what's going on. He could direct the players' positions to the
System.out
on a console, but that is not really helpful. Also, it would be
Search WWH ::
Custom Search