Chief Architects: Lori Peacock, Max Preston, Megan Murphy
Chief Programmers: Lori Peacock, Max Preston, Megan Murphy
Chief Documentarians: Lori Peacock, Max Preston, Megan Murphy
"Three Minds are always better than one."
That is, we feel each of these three positions will be better
held by the entire group in a collorative effort. If each
group memeber is assigned a distict role, it will inhibit our
ability to work together and create a well designed, well written
and well documented final project.
Tic Tac Toe:
Implemented by Megan Murphy, this game simulates classic tic tac toe allowing users to choose the icon of their choice, and keeping a running score of games between two users.
Chomp:
Implemented by Max Preston, this game simulates eating a candy bar, with the goal of avoiding the last bite.
Dots:
Implemented by Lori Peacock, this game allows users to connect dots in an attempt to complete the most boxes.
We also plan to implement 2 or 3 of the following games:
Connect 4 Pipe Dream Black Box Bejeweled Minesweaper
OOGA will be a framework which allows users to play one of a number
of implemented games. Running OOGA will create a window (JFrame) containing
a file, option and help menus as well as 3 JFrames. The largest frame
(located in the left of the window) will be set as the game board of the
users choice of game. Another frame will supply score information set
as each game is played. The final frame will contain buttons constant to
all games (such as play, view high scores, reset, exit, ect...). The File
will contain a pull out list of all implemented games and allow the user to
choose the game he or she wishes to play. From this choice, the options menu
will be set to allow the user to customize aspects of the game. The OOGA class
will control this window, as well as contain a private game controller which
will all be set by the users game choice.
To implement this, we will use a heirarchy of Controllers. Each game will
have a Controller that stores its Model, its game board GUI, its score GUI and its
player information. This way the actual game Models are independant of the number
of players which will ficilitate adding AI and/or network capabilites.
Each game will also (as mentioned above) have a Model that will inherit from
a parent model class. The job of the model is to take in player information and
store the game data. In order to accomplish this, the Model must extend Observable
and implement ActionListener. This allows the Model to be observed by the GUI's and
listen for GUI actions which are used to update game information.
The game board GUI will store only GUI information and information on the current
player. It will have a private Model which it will Observe. The GUI will then update
based on changes in the model so that the graphical image will reflect the staus of
the game. That is, the user will click on the GUI and the Model will be listening for
that click. The model will then determine what it needs to change in itself based on
its current player and this action. It will then notify its observers (the game board
GUI and the score GUI) of this change.
In order for all of this to work together, we will also have a Player class that
stores score and image info. The Players will all be stored in the Controller so that
the Model and GUI's will get information about the current player from this location.
The difficult part of this implementation will be getting the required information
to each of the GUI's because of the limits of Observers. We do not, however, anitsipate
this causing too much of a problem.
Java Documentation of Major Classes
Right now, this site contains information on the following classes:
OOGA Class
Controller Abstract class
Model Abstract class
Player Class