Design Specification - BattleTans
Table of Contents
- Structural Design
- New Game
- User Interface
- BattleTans -
- Lounge Screen
- Two Player
- Networking Structure
- Lounge Interface
- Lounge Interface Implementation
- Piece Info
- Client Interface
- Class Inheritance
- Package Dependencies
List of Figures
- Figure 1 - BattleTans Opening Screen
- Figure 2 - Single Player Configure
- Figure 3 - Two Player Lounge and Pop-up
- Figure 4 - Lounge Object Dependencies
- Figure 5 - Two Player Game Interface
- Figure 6 - BattleTans Single Player High Score
- Figure 7 - BattleTans Network Structure
- Figure 8 - Object Roles In Network
- Figure 9 - Flow of Data During Networked
- Figure 10 - Network Class Hierarchy
- Figure 11 - Top Level of jTans
- Figure 12 - guimain package
- Figure 13 - calc package
- Figure 14 - jTans Package Dependencies
This document describes the BattleTans puzzle application. It offers
technical descriptions of how the application is to be implemented, and
the relationships between components of the system. The intended
audience of this paper is members of the CS 452 Software Engineering
What follows is a general description of the interactions and structure
of the system.
The purpose of this document is to provide the reader with a precise
understanding of how the BattleTans application is to be implemented.
This will be accomplished through describing interactions between jTans
and the new BattleTans components, along with graphics demonstrating
- Scope of the
This application may be used on a remote computer, but is intended to
be used on a LAN. The two player functionality is intended to occur
between two computers on the LAN. There was no existing network
functionality in jTans, thus it had to be created.
This section contains an overview of the BattleTans system components,
which will be integrated into the jTans system. We will show how each
of the new components we are creating interacts with existing jTans
components, and how the new components interact with each other.
The main function of the jTans code calls two distinct
interface and functional components, which are the Display Figure
Component and the Editable Figure Component.
The display figure
component is represented on the interface
as the region where the finished puzzle is displayed. In a structural
sense, it is an object made for the application whose sole purpose is
to display the puzzle pieces.
The editable figure component is
the region of the board
where the pieces are manipulated by the user in order to complete a
puzzle. It is where the heart of the functionality of jTans is located.
Our proposal calls for the creation of a two player interface. There
will be three component regions in this interface; one for the user to
manipulate his own pieces, a second to display the current state of
pieces of the opponent, and a third region to display the state of the
completed puzzle. The user manipulation region is obviously an Editable
Figure Component, and the completed puzzle region is a Display Figure
Component. The opponent state region is an Editable Figure Component,
where the inputs to the coordinates of the pieces are specified not by
the user, but by the opponent over the network. The protocols for the
network data transmission will be discussed later.
Two modifications to the jTans classes will be necessary. New class guimain.NonEditableFigureComponent
will extend EditableFigureComponent to display incoming network data for opponent's
moves. Method guimain.EditableFigureComponent.obscure() will be implemented
to cause the EditableFigureComponent to no longer be visible. Mouse input is
- New Game Types
For a Two Player game there are two game types that have been proposed
for the game. These Best of Five and Fastest Five. Best of Five is
where the two players each work on a puzzle until it is completed. The
person to complete the most puzzles wins the match. Fastest five
involves playing five single puzzle matches one after the other. The
first person to complete all five puzzles wins. Each of these can be
implemented by calling the single player or two player instances using
loops, and recording the results. Functions will be called to manage
and keep track of which player wins the most games.
All weapons will inherit from a superclass Weapon, which
provides a use() method. This is implemented in each weapon class to
carry out the weapon action.
This section will detail the structure of interfaces in BattleTans.
interfaces dicussed will concentrate primarily on those that are not
on jTans interfaces, namely, the BattleTans two player Lounge
- Wind The implementation is similar to that of Bang Table,
save that the movement occurs over a period of 10-15 seconds as opposed
to instantly. Wind implements use() to call
Calc.CalcPiece.setPosition(x,y) for each of the board pieces to move
them a random distance in the direction of the wind (also random).
- BattleTans -
The Main screen of BattleTans will be have a very basic layout. It is
sessentially a graphic of the BattleTans logo followed by three options.
Figure 1 - BattleTans Opening Screen
This can be achieved through a BorderLayout on the container panel, the
logo being assigned to Center, with another panel containing the three
options being assigned South. A Simple gridlayout of the three options
will display the buttons. Clicking on each of the buttons will change
screen to that respective choice.
The first button will be One Player BattleTans ("Training"), which when
clicked will lead to the One Player configuration screen. The second
button when clicked will lead to the Two Player Lounge ("Combat")
which will be discussed later.
The lounge involves most of the interface changes being added
to the jTans application. This screen is not based on any component or
panel in jTans.
Figure 3 - Two Player Lounge and Pop-up Challenge
The screen is divided into three basic panels, which have been
by their Java/Java Swing components. The layout of the container pane
be set to Borderlayout, which is conducive to the design of the Lounge.
The first panel, assigned to the Borderlayout.Center of the container
pane, will house the Lounge chat functionality. The panel contains a
multi-line text field, displaying the text from the chat conducted by
users. The field itself is housed in a JScrollPane to allow users to
scroll through the chat text.
Below the text field are two input elements. The first is a
text field, used to enter text to be entered into the chat text field.
This is accomplished by typing in the desired text and pressing the
button located to the right.
The second panel contains the information of the users participating in
the lounge, and is assigned the Borderlayout.East attribute to the
container pane. The first object in this panel, a multi-line text
field, is housed in a JScrollPane much like the chat field. It,
displays the user names and IP addresses of users on the network
participating in the lounge. Below the text field is a button
"Challenge." By selecting a user name from the list of users and
clicking on the challenge button, the selected user will be informed
the challenge via a small pop up window. The window contains the
pertinent information of the challenge, including the user name of the
challenger and the game type. The window also contains two buttons
labeled "Accept" and "Decline" for either accepting or declining the
The third panel of the interface contains the input objects used to
specify a type of game. The first is a radio select button associated
with the label "Fastest Five," which when selected chooses the fastest
five game type.
Below these two inputs are the ones associated with the "Best of Five"
game. The first input is a radio button labeled "Best of
which when selected enables the best of five game play.
Figure 4 - Lounge Object Dependencies
This describes the relationships of the objects in the lounge screen.
Each node represents an object. Each line represents membership between
objects, flowing top to bottom.
- Two Player
The two player gameplay is similar to that of the single player
although there are several significant changes. The Editable Figure
Component used to house the pieces for the jTans game would be
to display the progress of the opponent. It would be placed next to
Editable Figure Component used by the user to solve a puzzle.
Figure 5 - Two Player Game Interface
The second change would be a display for the weapons. This display
allow the user to select a weapon to be used, and to know which weapons
have already been used.
In Fig. 7, the network structure will have a single machine having the
lounge server object residing on it. The Lounge Server
object will have the duty of keeping track of all the available players
in the network and coordinating network game play. The lounge server
can be instantiated on any machine including the client's machine, but
for our purposes we can visualize the lounge server as a separate
Figure 7 - BattleTans Network Structure
The client machines, which will be operated by regular users, will have
a Client Object
instantiated. The Client Object's main duty will be to allow the
BattleTans client to receive coordinates from the Lounge Server object
during network game play. Figure 7, shows how the Lounge Server object
resides in the server, and the Client Object resides in the BattleTans
client machine. This figure also shows how the client communicates with
the server when registering. The client will send the server name and
network information to the Lounge Server object in order to maintain a
list of available players.
Figure 8 - Object Roles In Network
Fig 8 shows the flow of data between two network players. The data
flow occurs between Client #1 and Client #3, and the Lounge Server
object acts as a network traffic controller between the two clients.
The Lounge Server object receives the shape piece information from
both clients, and then routes them to the appropriate opponent.
Figure 9 - Flow of Data During Networked Game
Figure 10 - Network Class Hierarchy
The classes in the figure above represent the design of the network
implementation of BattleTans, which will use the Java RMI networking
capabilities. The design of the network implementation takes into
account concurrency issues as well as organizational problems such as
how the system will keep track of matches between players across the
network. The reason why RMI was chosen as a network communication tool
is mainly due to RMI's ease of use and also because it lends itself
well for book keeping purposes of players and matches. RMI can take a
class, which resides on one end of the network, and allow it to be
instantiated remotely across the network and have functions called.
This interface inherits from the java.rmi.Remote class and declares
remote functions which can be called across the network. This
class must be created due to RMI system rules.
This class implements the LoungeInterface class and provides the actual
implementation for its remote functions. This object will have the list
of available players across the network, called "AvailablePlayers",
which is an array of type Player. This array will be filled with values
when clients across the network register with the LoungeServer object.
This class will also maintain a list of current network matches. This
is stored in an array of type Match called "ListOfMatches".
This class contains data members which reflects the appropriate data
which should be stored whenever a match takes place. It contains
Player1 and Player2 of type Player, which are the two opposing clients.
GType is a string which will store what type of match is being played
(e.g. FastFive or BestOfMatch). PuzzleList is an array of
DisplayFigure, which is the class that holds the puzzle to be solved.
The TimerObj will be a java implemented Timer object that will be
started in FastestFive matches. CoordBufferP1 and CoordBufferP2 are
arrays of type PieceInfo which will act as buffers to store the shape
information data across the network so that no information is lost
during network transfer. Score1 and Score2 will be of type integer and
will be used to keep track of scores during a BestOfMatch game type.
This class encapsulates information about a client who wants to play
over the network. The Name is a string to represent the description of
the player. The IPAddress is an integer to represent the local area
network address of the client.
PieceInfoThe PieceInfo class
information about a game piece which will be sent to the Lounge Server
object. The CalcPiece represents one of the seven available geometric
pieces which the user manipulates. The xPos and yPos are the
two-dimensional coordinates of the CalcPiece.
The ClientInterface class inherits from the java.rmi.Remote class, and
declares a remote function.
ReceiveCoordinatesFromLounge()-allows the client object to receive
coordinates from the lounge. This function allows a client to receive
opposing player coordinates from the lounge after the opposing player
sends their coordinates to the lounge.
This class implements the ClientInterface interface.
- RegisterPlayer() - a client will call this function to send Name
and IP Address information to the server.
- SendCalcPieceInformation() - sends the information of the
local users most recent shape movement information to the
Lounge server object. Within this function, the server will
redirect the shape info to the correct
- UnregisterPlayer() - removes information of a client from the list
of available players
- SendMessage() - sends strings to the server for chatting
The BlueJ IDE was used to analyze the existing jTans source in order to
give an overview of how the individual classes related to one another.
In all diagrams, nodes represent classes. A solid line points at a
class inherited from. A dotted-line extends from a class to a function
call inside another class.
- ConnectToServer()-a non-remote function which will call the Lounge
Server's RegisterPlayer function.
non-remote function which will call the Lounge Server's
SendCalcPieceInformation() to store game piece information on the
- SendMessageToLounge()-a non-remote function which will call the
LoungeServer's SendMessage() to send a string to the lounge.
Figure 11 - Top Level of jTans
This demonstrates the top level of the jTans class hierarchy.
jTansApplication, the standalone program, and jTansWebstart, the Java
Webstart version, both inherit from the AbstractApplication class.
AbstractApplication takes care of the high-level game setup.
Figure 12 - guimain package
guimain contains the MainWindow class, which sets up the main
window. DisplayFigureComponent displays the puzzle (solution) worked
on, and EditableFigureComponent is the main puzzle workspace.
Figure 13 - calc package
calc takes care of the most complex code: playing piece handling and
calculations for solution checking. CalcPiece is the parent class for
playing piece classes. CalcPieceT is the trapezoid, CalcPieceMT is the
Medium Triangle, CalcPieceGT is the Large Triangle, CalcPiecePT is the
Small Triangle, and CalcPieceC is the Square. CalcPolyPoints handles
most of the calculations regarding playing pieces.
Figure 14 - jTans Package Dependencies
The Package Dependencies diagram gives a higher level view of the
jTans source. This shows how the class diagrams above are related.
- a Chinese puzzle consisting of a square divided into seven pieces
be arranged to match particular designs
- jTans - an
Tangrams using Java
- One Player - The single user mode of tangrams gameplay. Users can
a single puzzle to finish or pick 5 puzzles and complete them as
- Two Player - BattleTans implementation of multiplayer Tangrams
players compete for the fastest aggregate time in fastest
- Single Puzzle - in the single player or multiplayer mode, users
able to either select a puzzle or choose one at random to play in
or two player match mode.
- Fastest Five - a game type in BattleTans that involves picking
and completing them as quickly as possible
- Fastest N Puzzles - in the two-player match mode. a N amount of
are chosen. The two users then compete the puzzles as quickly as
- Editable Figure Component - a sub class of the gui main class
the region of the user interface that is editable
- Display Figure Component - a sub class of the gui main class that
the display figure used in tangrams
- Dia - is a
diagram creation program released under the GPL license.
- BlueJ - is an
environment specifically designed for introductory teaching. We
used it to
help visualize the original jTans source.