| |
|
|
 |
|
|
|
|
Last Updated:
31st Oct, 2005, 11:47 GMT
|
| |
|
JOGRE API
|
| | |
|
The JOGRE API has been designed so that functionality which is common to all (or almost all) types
of games is taken care of. This functionality includes organising users,
table lists and player lists within tables. The API also deals with player chat which
can be global, private to a table or private to an individual user.
The following diagram visually shows the package structure of the JOGRE API.
The package structure has got simplier in alpha 0.2 with three main package
for holding client classes, server classes and common classes which both the
client and server make use of.
The main package is the org.jogre package which most other packages
exist under. However the JOGRE API is also packaged with the TableLayout
jar file from clearthought (in yellow) which the org.jogre.awt
package uses extensively and the XML parser NanoXML (in brown) which is
used for sending communication in XML form.
Arrows are used to show the dependencies between
packages. Most dependencies are in one direction to keep coupling low,
except the awt & client packages (although the client
to awt communication is achieved using interfaces).
|
| |
 |
| |
|
- info.clearthough.layout -
TableLayout manager which provides the power of GridBagLayout but
is much easier to use.
- nanoxml -
Very small XML parser which is used primarilaly for communication object serialization.
-
Common Packages
- org.jogre.common -
Contains classes which are used both in the server and a client. These are
mostly data classes such as TableList, Table, UserList, User, PlayerList, Player etc which store
details on users and tables currently being played. It also contains the important JogreModel
class which is used to store the state of a game on client and on a server (optional).
- org.jogre.common.playerstate -
The state of a player is stored as classes in this directory (state design pattern).
These states include viewing, seated, ready to play and game started.
- org.jogre.common.util -
Contains a number of utility packages which most of the other packages make use of. These
include singleton classes which are used for loading properties/language labels. Also includes
common file utilities and a small logger.
- org.jogre.common.comm -
Contains 2 interfaces and a number of communication classes. Most communication
between a server and a Client is transferred as Comm objects.
-
Client Packages
- org.jogre.client -
Contains a number of classes specific to a JOGRE client.
- org.jogre.client.awt -
Contains various GUI components used in the creation of the JOGRE interface. Most of the
key classes in the JOGRE API are in this package.
Key Classes
A number of key classes exist in the JOGRE API. These key classes are
abstract and need to be extended to be used. Also some of the
classes contain abstract methods which must also be implemented. This pattern of
creating an application is known as the Template Design Pattern - a programmer
fills in the bits which are specific to his specific game - the rest is already
done in the API classes. The naming convention is usually to replace the word
Jogre with the name of the game. i.e. JogreModel becomes ChessModel.
|
| |
| Package |
Class/Interface Name |
Synopsis |
|
|
JogreClientFrame
|
This abstract class declares the main game frame where a user can see
users of the left, tables on the top right and a broadcasting style message
chat box on the bottom right. To create a new client frame for a game, such
as Chess for example, a class called e.g. ChessClientFrame extends this class
and implements 2 abstract methods for returning the correct
JogreTableFrame class (e.g. ChessTableFrame).
|
|
JogreTableFrame
|
The important JogreTableFrame which is where each game is played. Each time
a new table is created one of these frames appear. This class creates the
buttons at the top of the screen, the player list at the bottom left and the
message chat box on the bottom right. The main game area is set in the sub
classes e.g. ChessTableFrame using the setGamePanel (JPanel) method.
To use this class a class must extend it e.g. ChesTableFrame. Its fields
must include a data model (JogreModel e.g. ChessModel), a view of the data
(JogreComponent e.g. ChessBoardComponent) and a controller (JogreController
e.g. ChessController) for understanding mouse movements etc on the view.
The constructor in the sub class should initialise these MVC fields and
MUST call the setMVC (model, view, controller) method as this class
makes use of these.
|
|
JogreComponent
|
This class creates the view in the JOGRE MVC (model/view/controller)
architecture. This class extends a JComponent and also implements the
Observer interface. By implementing the Observer interface a change in the
model (JogreModel) which calls the JogreModel.refreshObservers () method will
automatically repaint this class.
Mouse/keys events can listened on using a JogreController which is set
using the setController method of this class. |
|
|
JogreController
|
Adapter game controller class which creates empty methods for the
MouseListener, MouseMotionListener and KeyListener event interfaces.
This class also contains a link to the JogreModel, a connection thread to the
server and also a JogreComponent where the mouse movements/key presses are taking
place on.
To use this controller a class must extend it e.g. ChessController and
then override one of its event methods, update the correct model and send
communication to other users. To use the controller on a JogreComponent,
a JogreComponent calls its public void setController (JogreController
controller) method.
|
|
|
CommTableMessage
|
Abstract base class for table messages. This class is used for creating
communication objects between games e.g. CommExecuteChessMove.
From alpha 0.2 it is only necessary to create objects for very complex games as
communication properties can be used.
|
|
|
JogreModel
|
Abstract class which holds the state/model of a particular game when
extended. This class extends the Observable class so that JogreComponent
classes can update themselfs depending on changes made in this classes.
For a very simple example, to create the model for a game of
tic-tac-toe a class TicTacToeModel should extend this class and add a 3x3
two dimensional int array i.e.
int [][] = {{0, 0, 0}, {0, 0, 0}, {0, 0, 0}}.
|
|
| |
|
All of these key classes (with the exception of CommTableMessage) must be extended
from the JOGRE API to create a new game. The following UML diagram shows how a game of
chess can be created using the JOGRE API. The classes on the bottom are the chess
classes and the classes at the top are from the JOGRE API / Java SDK.
|
| |
|
| |
|
The ChessClientFrame class contains a main method which when
executed, creates a JFrame with the various users, tables and global
chat on the screen. This screen generally doesn't change from game to game
i.e. ChessClientFrame contains very little code.
When the new table button is clicked a ChessTableFrame is created which
is the key class of a game. The parent class JogreTableFrame creates
buttons at the top, a player list and table chat on the bottom.
The actual game of chess is rendered in the
middle of screen and is created in JOGRE using a MVC (model/view/controller)
style architecture. The chess board in the middle (ChessBoardComponent)
is created from an AbstractBoardComponent which can be used to easily
create game boards (i.e. is also used to create a checkers board).
The ChessModel contains data relating to a game of chess including
an integer array of size 64 (8 by 8 cells of a chess board). Example values of
the array are: 0 = Empty, 1 = White Pawn, 2 = White Knight etc. The
ChessBoardComponent registers with the model so that every time the
ChessModel changes the board will refresh itself with the pieces
in the correct position.
The ChessController controls the
ChessBoardComponent i.e. listens to mouse events and updates
the ChessModel if a move has taken place.
The JogreController also has a link to the
TableConnectionThread and can inform the server that a move
has taken place and keep other clients in synch.
This is a very brief introduction / summary of what is required
to create a JOGRE game. A much more indepth look, with full source
listings and UML diagrams is available in the various
tutorials.
|
| |
| [ top ] |
| | | |
|
|
