Design Specification - BattleTans

Contributors

Jim Kelly
Phil Thomas
Johnson Joseph
Timothy Bieniosek
Joseph Purayidathil

Table of Contents

Preface
  1. Introduction
    1. Purpose
    2. Scope
    3. References
    4. Overview
  2. Structural Design
    1. New Interfaces
    2. New Game Types
    3. Database
    4. Weapons
  3. User Interface
    1. BattleTans - Main Screen
    2. Lounge Screen
    3. Two Player Gameplay
  4. Networking Structure
    1. Overview
    2. Class Hierarchy
    3. Lounge Interface
    4. Lounge Interface Implementation
    5. Match
    6. Player
    7. Piece Info
    8. Client Interface
    9. ClientInterfaceImpl
  5. Class Inheritance Diagrams
  6. Package Dependencies
  7. Glossary

List of Figures

  1. Figure 1 - BattleTans Opening Screen
  2. Figure 2 - Single Player Configure Screen
  3. Figure 3 - Two Player Lounge and Pop-up Challenge Window
  4. Figure 4 - Lounge Object Dependencies
  5. Figure 5 - Two Player Game Interface
  6. Figure 6 - BattleTans Single Player High Score Page
  7. Figure 7 - BattleTans Network Structure
  8. Figure 8 - Object Roles In Network
  9. Figure 9 - Flow of Data During Networked Game
  10. Figure 10 - Network Class Hierarchy
  11. Figure 11 - Top Level of jTans
  12. Figure 12 - guimain package
  13. Figure 13 - calc package
  14. Figure 14 - jTans Package Dependencies

    Preface

    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 Workshop.

    1. Introduction

      1. Purpose

        2. 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 these relationships.

      2. Scope of the Product

        3. 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.

      3. References

      4. Document Overview

        5. What follows is a general description of the interactions and structure of the system.

    2. Structural Design

      3. 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.

      1. New Interfaces

        2. 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 still accepted.

      2. New Game Types

        3. 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.

      3. Weapons

        4. 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.
        • 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).

    3. User Interface

      4. This section will detail the structure of interfaces in BattleTans. The interfaces dicussed will concentrate primarily on those that are not based on jTans interfaces, namely, the BattleTans two player Lounge interface.

      1. BattleTans - Main Screen

        2. 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 the 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") screen, which will be discussed later.

      2. Lounge Screen

        3. 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 Window

        The screen is divided into three basic panels, which have been diagramed by their Java/Java Swing components. The layout of the container pane will 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 single-line 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 submit 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, however, displays the user names and IP addresses of users on the network participating in the lounge. Below the text field is a button labelled "Challenge." By selecting a user name from the list of users and clicking on the challenge button, the selected user will be informed of 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 challenge, naturally.

        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 Five" 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.

      3. Two Player Gameplay

        4. The two player gameplay is similar to that of the single player gameplay, although there are several significant changes. The Editable Figure Component used to house the pieces for the jTans game would be duplicated to display the progress of the opponent. It would be placed next to the 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 would allow the user to select a weapon to be used, and to know which weapons have already been used.

      4. Networking Structure

        1. Overview

          2. 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 machine.

          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

        2. Class Hierarchy

          3. 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.

        3. LoungeInterface

          4. 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.
          • 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 opponent.
          • UnregisterPlayer() - removes information of a client from the list of available players
          • SendMessage() - sends strings to the server for chatting purposes.

        4. LoungeInterfaceImpl

          5. 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".

        5. Match

          6. 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.

        6. Player

          7. 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.

        7. PieceInfo

          8. The PieceInfo class encapsulates 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.

        8. ClientInterface

          9. 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.

        9. ClientInterfaceImpl

          10. This class implements the ClientInterface interface.
          • ConnectToServer()-a non-remote function which will call the Lounge Server's RegisterPlayer function.
          • SendCoordinatesToLounge()-a non-remote function which will call the Lounge Server's SendCalcPieceInformation() to store game piece information on the lounge.
          • SendMessageToLounge()-a non-remote function which will call the LoungeServer's SendMessage() to send a string to the lounge.

      5. Class Inheritance Diagrams

        6. 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.

        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.

      6. Package Dependencies

        7. 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.

      7. Glossary

        • Tangrams - a Chinese puzzle consisting of a square divided into seven pieces that must be arranged to match particular designs
        • jTans - an implementation of Tangrams using Java
        • One Player - The single user mode of tangrams gameplay. Users can select a single puzzle to finish or pick 5 puzzles and complete them as quickly as possible.
        • Two Player - BattleTans implementation of multiplayer Tangrams play. Two players compete for the fastest aggregate time in fastest puzzles.
        • Single Puzzle - in the single player or multiplayer mode, users will be able to either select a puzzle or choose one at random to play in single player or two player match mode.
        • Fastest Five - a game type in BattleTans that involves picking five puzzles and completing them as quickly as possible
        • Fastest N Puzzles - in the two-player match mode. a N amount of puzzles are chosen. The two users then compete the puzzles as quickly as possible.
        • Editable Figure Component - a sub class of the gui main class that displays the region of the user interface that is editable
        • Display Figure Component - a sub class of the gui main class that shows the display figure used in tangrams
        • Dia - is a gtk+ based diagram creation program released under the GPL license.
        • BlueJ - is an integrated Java environment specifically designed for introductory teaching. We used it to help visualize the original jTans source.