David Pape
Joe Lau
Brendan



Adaptation of the board game Freedom in the Galaxy to a graphical computer simulation of said game might best be
handled through direct translation of the rules into source code. Doing this will require construction of several
classes, and libraries containing rules packages. Each physical game piece (i.e. tiles, map, etc...) should be
translated into an object which may be manipulated by the rules libraries during game play.

A brief overview of the rules and system led to a preliminary design which modularizes objects, rules, and game functionality
into multiple libraries. The libraries include the Game Objects library, the Graphics library, the Rules library, and
several optional libraries such as Game Server and Game Client Networking libraries, and additional libraries for saving and
loading ongoing games. The Rules library would control game play, and be the main library for the game. The objects
library would allow creation of objects, as well as determining their storage and access methods. The Graphics library would
allow the display of information returned by the rules library to the players, creating the interface for the game. If
networking was to be built into the game, then the Server Library and Client Library would each allow for the transmission
of game information in a predefined protocol, and upon receipt of the transmission pass the information to the Rules Library
(server side) or the Graphics Library (client side).

Assuming that network gaming was required (to avoid sharing input devices between two players, and to work around the
limitation of the board game which allows all players to see each others' pieces), then the server and clients would need
to meet the following Requirements:

Server would:

Interpret and calculate game play via Rules Library.
Send errors to clients.
Save and load games.
Control client connections.
Track the current turn/phase.
Report all errors to a log file.
Determine and control units visible to clients.

Client would:

Provide graphical interface for the game using the
Graphics Library.
Display visible objects and the game map.
Do preliminary out-of-phase checks to prevent the players from flooding the server with invalid requests.
Display unit information.

To achieve the functionality above, the class would be divided into multiple teams, each of which would develop, or work with
other teams to develop one of the listed modular libraries. Teams would be divided as follows:

Team 1:  Develop protocols for communication between libraries,

         as well as a network communication protocol, and decide
         in what data structure(s) to store game objects.
Team 2:  Program the Game Objects libraries, and determine 
         intralibrary method communication.
Team 3:  Program networking side of game, and a protocol 
         interpreter according to specifications provided by 
         Team 1.
Team 4:  Design and program map and unit display for the 
         graphical interface (client side).
Team 5:  Design and program user command interface, and 
         integrate the map display into the client.  Interface
         client command interface with networking libraries.
Team 6:  Program the rules libraries and interface those
         libraries with the server networking libraries.
Teams could be composed of 2 to 4 members, and, optionally,
eliminating Team 1 and allowing the entire class to decide on library/networking communication protocols would allow teams of
4 members each. It is likely, however, that due to disagreements between design and requirements, elimination of Team 1 might
cause the development process to extend itself indefinitely.

Each library in the game would be based upon a class inheritance system diagramed below:

The Universe class would be an aggregation of all other classes
in the game, much as the Universal set is an aggregation of all members of all other sets. Below the Universe class are the
Unit, Galaxy, and Possessions classes. Each of these classes is an abstract class, and the Possessions and Galaxy classes
are agregations of the classes beneath them. The Unit class shares only inheritence relationships with the classes beneath it, as
a single unit is not composed of other units. This class could become an aggregation of the inheriting units if it were changed
to the "Population of the Universe" class. However, due to the extreme differences noted between Unit types, we feel it is best
as an abstract parent class.

Due to the lack of double inheritence in java, classes that inherit from multiple parent classes should be designed to inherit
only from the class that they are most closely related to, then
flagged as having attributes of other classes. These flags could be easily checked for in code dealing the with the other parent
classes, and the class could be handled appropriately. One such class is the Possessions class, in which the possesions possess
a boolean "is_unit" flag.

We feel that all use cases should be controlled in the Rules libraries, and that these libraries
should be designed only after all the object classes have been designed. This will allow the rules
libraries to be designed to accomodate the data structure storage methods of the classes, and the
access methods each class possesses. A preliminary requirements analysis of the rules suggests
that these will be the most extensive and complex of the libraries, and will need to take into
account all attributes of the other classes as well as the aforementioned properties. This means
that a use case diagram will require further analysis and design, and may well be much more complex
than the attached Class diagram.

In short, we feel that a Use Case diagram for this project is simply too complex and too detailed
to be completed in such a short amount of time, as there are far too many use cases to consider.