Problem Description

The semester project for the Fall 2006 SWD class is a client-server implementation of the video game Pong (origionally by Nolan Bushnell in 1972). In Pong each player has a paddle that they can move. The objective is to use your paddle to block the ball from hitting your goal (the area behind your paddle) and try to make the ball hit the opponents goal. The project will involve removing specified class files and replacing all or part of them with you own code. This document is intended to present a rough structure of the system as well as provide links to other supporting documents such as JavaDoc and UML.

System Level Architecture

• Client/Server Model

  This implementation of Pong is inherently designed to run over the internet (or a network), which suggests one of two design patterns: client/server or peer-to-peer. The client server pattern was chosen over the peer-to-peer since it is an older pattern and is better defined than the peer-to-peer - which requires dealing with additional overhead to create and maintain a Pong server that does not have a permanent home. It is understood that the central server is a single point of failure because it’s the hub of all communication; however, given the time constraint, it is an acceptable alternative.
  
  The syschronous lines (filled arrows) represent synchronous communication over TCP/IP or synchronized calls in Java. The asynchronous lines (non filled arrows) represent event driven actions. The top call is the Client setting up the GUI (ConnectionImpl). 1) is the Client creating the Socket to connect to the server. This cause the Server to accept the connection and 2) initialize a ServerHandler. 3) is the Client sending the ConnectMessage. If successful the Client then switches GUIs to the WaitImpl.

• Model-View-Controller

  The client part of Pong follows the model-view-controller (MVC) design pattern. The MVC pattern was chosen since the program has one underlying model with multiple independent views. The views of the model need to be generated dynamically based on factors such as user interaction with the controls. The views should be able to be modified without changing the model.

Component Level Architecture

• Client

  The Pong Client interacts with the views and controllers of the underlying model through the ClientMVC interface. There are three implementations of the ClientMVC interface: ConnectionImpl, WaitImpl and PongImpl. These implementations will be covered in more detail below. The ClientHandler class wraps a socket connection to the Pong server. The Client class is an implementation of the frame that holds the GUI. It also has references to the ClientHandler and the ClientMVC implementations. Based upon user input, Client will switch between the ClientMVC implementations.
  Client Package Diagram (UML)

  • Connection View

    The ConnectionImpl presents fields for entering server name (or IP), username and password. There are also buttons for submitting the entered information and choosing to play offline (not enabled). If playing offline is selected, the user is immediately taken to the PongImpl. If the information is submitted, the entered values are passed to the ClientHandler which wraps the values into a message and sends it to the Pong server. There are two possible responses from the server: success or failure. If a successful login is received then user is taken to the WaitImpl. If a login failure is recieved the user is prompted to try again.

  • Wait View

    The WaitImpl present the user with two options signal to the server that you are ready to play or disconnect from the server.

  • Pong View

    This view is a player’s system interface during actual gameplay. The view consists of two major parts. The first is the header that contains each players name and score. The second is the PongComponent. Once gameplay has started the PongComponent responds to the users mouse movements by moving the paddle.

• Server

  The Pong Server is a central location that handles message passing between clients. The server creates ServerHandlers and GameHandlers as necessary to deal with communication. It also maintains a connection to the database to be able to store and retrieve statistics.
  Server Package Diagram (UML)

  • Server Handler

    Each time a new client connects to the Server, a ServerHandler is created. The ServerHandler has a thread that listens for incoming messages from a Pong client. The ServerHandler then unrolls and passes the messages to the Server for handling. The ServerHandler is able to detect when a Pong client has timed out or has been dropped and then proceeds to notify the Server accordingly, before destroying itself.

  • Game Handler

    When a request to make a new game is received by the Server, a GameHandler is created. Before a game starts, the GameHandler distributes the game parameters to all clients. The GameHandler then registers itself with a shared timer thread. This allows the game to send updates to clients on a regular basis. Once all users have left a game the GameHandler destroys itself.

• Common

  Common data elements are used to facilitate communication between the client and the server. The main classes are for representing messages and users. Several shared components are also included in the Common package.
  Common Package Diagram (UML)
  Conenction Package Diagram (UML)
  Properties Package Diagram (UML)

Project Links

JavaDocs for Pong

To run the jar files double click or use the command: java -jar pong-client.jar or java -jar pong-server.jar

Pong client jar (right click and save as)

Pong server jar (right click and save as)