I.Identification

See:
          Description

I.Identification

����������� Project Name:Sokoban

����������� Authors:���������� Kamil Baranowski

����������������������������������� Kevin Blomseth

����������������������������������� Antony George

����������������������������������� Janice Lin

����������������������������������� Joshua Thompson

����������� Version:����������� 2.0

����������� Date:��������������� 11/19/2001

 

II.Design Overview

 

The Sokoban game will be implemented as an event-driven application.The game revolves around a central Game class which serves as a communications link between the graphical user-interface contained in the Sokoban class, the client-server networking model and the Map class.When a message is received from either the GUI class Sokoban or from the networking classes ServerThread or Client, the Game class will respond to the message by determining what type of message it is and which class should handle the message.The Game class will then call the methods of the appropriate classes so that the message can be carried out.The Game class will also be responsible for the saving and loading of previous games.The LevelEditor class will provide the level editing functionality of adding and removing objects from the map.It will also implement the saving and loading of levels functionality.

The actual game-play will be implemented within the Map class.Whenever the Game class receives a message about a movement, a level change, restarting a level, an undo, or an instant replay, it will inform the Map class and the Map class will then carry out the task.The Map class will keep track of the location of the walls, crates, and incinerators.The Map class will also contain between one and four Robot classes.Each Robot class is responsible for all information pertaining to the individual user including game statistics, location on the map and the user name.As well, the Robot class will keep track of each movement made in a stack.Each time a move message is received from the Game class, a Move class is created with information describing the move and then it will be added to the stack.The movement tracker will be used to implement the undo feature as well as the instant replay feature.

The networking will be implemented using the client-server model.To connect to a game, the Client class will create a socket connection to the Server class running on another machine.Each client has its own copy of the map on the server and updates it whenever it receives a message from the server.The Server class is responsible for accepting connections from Client classes on other machines.Once a connection has been received, the Server class will then create a new ServerThread class to communicate with the new client and then return to listening for connections.Each ServerThread class will be responsible for communication with a client.The Server class also provides broadcasting functionality.Whenever a message is received that all clients need to know about, such as a movement or chat message, the Server class will pass the message along to each ServerThread which in turn will inform its connected client.

 

III.Design Issues

 

Issue:Which software architecture should be used in the design of Sokobon?

Alternative A:Sequential Architecture

Advantages:������ People think in a sequential manner.

Disadvantages:�� Code would be different to split up for multiple people to write.Program would be difficult to implement in this manner.

Alternative B:�� Event Driven Architecture

Advantages:������ Sokobon is an event driven application given due to the nature of the interaction between the user and the system.

Disadvantages:�� There is a lot of time spent waiting.

Alternative C:�� Client/Server Architecture

Advantages:������ There is a client server present in the multiplayer aspect of the program.

Disadvantages:�� Only works for the networking aspect and not for the rest of the program. Programmers lack experience using client/server architecture.

Decision:We chose a combination of Alternatives B and C. We chose to implement the program with alternative B, and we chose to use alternative C to facilitate implementation of multiplayer.

 

Issue:Should the map be kept on the server or the client?

Alterative A:Storing the map on the server

Advantages:������ The map is kept consistent between clients.

Disadvantages:�� There is more network traffic. The response would be dependent upon connection speed.

Alternative B:Storing the map on the client and having the server send small updates about what moves happened.

Advantages:�������� Less data has to be transferred, meaning updates are quicker. It also allows for the proposed messaging system.

Disadvantages:���� It's difficult to keep the map synchronized across all of the individual clients.

Decision: We chose to go with keeping the map on the client, because we felt that it was fairer for the user.

 

Issue:What data structure to use for keeping track of moves?

Alternative A:Create a linked list class that would create a linked list of created move objects for each move.

Advantages:�������� Creating a new class of an expandable linked list would provide customability in the class.

Disadvantages:���� A new Linked List class would have to be to created, which would take time and effort with room for error.

Alternative B:Use an array with a fixed length.

Advantages:�������� Easy and quick access and predefined class for use.

Disadvantages:���� Array size needs to predefined, leading to either running out of room or having a lot of extra room. Also leads to difficulty in reordering objects

Alternative C:Use a Vector of move objects to keep track of the moves.

Advantages:�������� There is a predefined Vector class that provides ability to place objects wherever you want in the vector and has an easily changeable size.

Disadvantages:���� Using a vector is less efficient than using an array.

Decision:We decided to use the vector due to the fact that it is already a present class that would facilitate stacking of objects.

 

Issue:������ Should single-player and multi-player be designed using separate classes for each.

Alternative A:Implement both single-player and multi-player as one class

Advantages:�������� Fewer classes would be used which would lead to lesser coupling

Disadvantages:���� The design is not as decomposed as it could be which means that there are classes that may be more congested then they need to be and therefore more difficult to implement.

Alternative B:Implement the single-player and multi-player classes so they extend from an abstract game-play class

Advantages:�������� The two have similar functionality and so the over-ridden inheritance would lessen the necessary work.

Disadvantages:���� Allows a programmer to access protected methods and attributes and possibly mistakenly alter them.

Alternative C:Implement the single-player and multi-player classes as separate individual classes

Advantages:�������� The design is more decomposed leading to more cohesion between the classes.The modules would be smaller and easier to assign to programmers for implementation.Testing would be made easier and the level of maintainability would also be increased.��

Disadvantages:���� The two classes would repeat each other in a large part of the game-play functionality.

Decision:We chose to implement the game using Alternative A because it allows for fewer classes being used and less coupling.

 

Issue:What should the relationship between the GUI and lower-level game classes

Alternative A:incorporate one within the other

Advantages:�������� Faster to implement; less coupling

Disadvantages:���� More difficult to upgrade and modify the GUI since it is integrated within each individual class

Alternative B:Separate GUI from the underlying structure

Advantages:�������� Allows for easier modification of the GUI; makes application more modular for ease of upgrading; easier to understand and follow the logic of the program

Disadvantages:���� Increases coupling

Decision:Alternative B because we are interested in ease of expansion and modification for future versions.

 

IV.Tools

The following is a list of compilers and other development tools used and their version numbers:

 

Program:��������� Java 2 SDK Standard Edition

Version:����������� 1.3.1

 

Program:��������� Together

Version:����������� 4.1

 

Program:��������� Microsoft Visual J++

Version:����������� 6.0

 

Program:��������� Adobe Illustrator

Version:����������� 9.0

 

Program:��������� Microsoft Word

Version:����������� 2000

 

 

V.Libraries

 

Library: java.io.*

Reason: This will facilitate file communication and networking of the game.

Licensing Restrictions: No known licensing restrictions.

 

Library: java.net.*

Reason: This will facilitate java networking of the game.

Licensing Restrictions: No known licensing restrictions.

 

Library: java.util.*

Reason: This will facilitate the vectors and timer.

Licensing Restrictions: No known licensing restrictions.

 

 

Library: javax.swing.*

Reason: This will facilitate the full implementation of the game and GUI.

Licensing Restrictions: No known licensing restrictions.

 

 

 

Library: java.awt.*

Reason: This will facilitate the full implementation of the game and GUI.

Licensing Restrictions: No known licensing restrictions.

 

 

 

VI.External References

 

Our external references can be found at the following locations:

 

Specification Documentation: http://latte.java.calpoly.edu/~kbaranow/srs.html

 

Prototype:http://latte.java.calpoly.edu/~kbaranow/grid/02.html

 

UML Diagram: http://latte.java.calpoly.edu/~kbaranow/classdiagram.gif

 

JavaDocs: http://latte.java.calpoly.edu/~kbaranow/javadocs/index.html

 

Coding Standards: http://www.csc.calpoly.edu/~jdalbey/SWE/code_std.html