|
||||||||
PREV NEXT | FRAMES NO FRAMES |
I.� Identification
See:
Description
I.� Identification
����������� Project Name:� Sokoban
����������� Authors:���������� Kamil Baranowski
����������������������������������� Kevin
Blomseth
�����������������������������������
����������������������������������� Janice
Lin
����������������������������������� Joshua
Thompson
����������� Version:����������� 2.0
����������� Date:���������������
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
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. |
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
|
||||||||
PREV NEXT | FRAMES NO FRAMES |