Project: The Watson Adventure Game
Function: Client
Subsystem: Integration of Residential Life Challenges
Author: Joshua Ruff
Date: 05/08/2005
Class: CS-495 Spring 2005
Project: The Watson Game
Function: Client
Subsystem: Integration of Residential Life Challenges
Author: Joshua Ruff
Date: 05/08/2005
Table of Contents
1. Introduction…………………………………………………………………………………..…3
1.1 Goals and objectives…………………………………………………………………..3
1.2 Statement of scope…………………………………………………………………….3
1.3 Software context………………………………………………………………………3
1.4 Major constraints……………………………………………………………...............3
2. Architectural and component-level design……………………………………………………..4
2.1 Program Structure…...………………………………………………………….……..4
2.1.1 Architecture diagram………………………………………………...……..4
2.1.2 Alternatives………………………………………………………………....4
2.2 Description for Component Integration of Residential Life Challenges..……..…..….4
2.2.1 Processing narrative (PSPEC) for component Integration of Residential
Life Challenges……………………………………………………………..…….4
2.2.2 Component Integration of Residential Life Challenges interface
description…………………………………………………...……………………5
2.2.3 Component Integration of Residential Life Challenges processing
detail………………………………..…………………...………………………...5
2.3 Software Interface Description………………………………………………………..6
2.3.1 External machine interface…………………………………...…………….6
2.3.2 External system interface…………………………………………...………6
2.3.3 Human Interface……………………………………………………………6
3. User interface design………………………………………………………………….………...7
3.1 Description of the user interface………………………………………………………7
3.1.1 Screen images………………………………………………………………7
3.1.2 Objects and actions………………………………………………………………….8
3.2 Interface design rules………………………………………………………………….8
3.3 Components available…………………………………………………………………9
4. Restrictions, limitations, and constraints……………………………………………………….9
5. Testing Issues…………………………………………………………………………………...9
5.1 Classes of tests………………………………………………………………...............9
5.2 Expected software response…………………………………………………...............9
5.3 Performance bounds………………………………………………………….............10
5.4 Identification of critical components………………………………………………...10
6. Appendices…………………………………………………………………………………….10
6.1 Requirements traceability matrix…………………………………………….............10
7. Use of mantis………………………………………………………………………………….10
8. Use of subversion……………………………………………………………………………...10
Class: CS-495 Spring 2005
Project: The Watson Game
Function: Client
Subsystem: Integration of Residential Life Challenges
Author: Joshua Ruff
Date: 05/08/2005
The Watson Adventure Game
1. Introduction
The Watson Adventure Game is modeled similar to the “old” ZORK game in which you move
through a fixed area and take on enemies, challenges, and collect items. Instead of being a combat game
the Watson Game is academically based. This document will discuss all data, architectural, interface and
component-level design of the software for the Watson Game.
1.1 Goals and Objectives
The goal of the game as a player is to make your way from a freshman through four years in the
Watson School of Engineering. On the other end the goals and objectives for the software package of the
Watson Game is to resemble an adventure game, where the player is moving around in a fixed sized
environment. The environment must resemble that of the Engineering building on the Binghamton
University Campus. During the game the user should be able to pick up useful items that are required to
complete challenges the user will come upon. The user will work there way through the courses, known as
challenges, to reach the end of the game where they have completed the required four years. The game will
allow multiple players who log on to a server and be able to see and interact with each other. The user
should be able to log off the game and return exactly how they left.
1.2 Statement of Scope
When starting the game the user will be asked to log on to a server, if the user enters and incorrect
username or password they will be given the correct error message. If they successfully logged on then
they will be entered into the game at the starting point or at the point in which they last left the game. If the
user is a new player they can create a user name and password and pick the major in which they want to
take. Each player will start with a $100.00 parental donation, identification card, and a book bag that will
be able to hold anything they pick up during the game. During the game the user should be provided with
the function to have there past information stored, such as grade point average, health, and items collected.
This part of the game will be handled by the server portion of the software, which will store data by the use
of an access database. The database portion of the software will hold all information for the player. For
example, it will keep the items collected, challenges completed, and position of the player at all times. The
client part of the software, implemented in C++ is responsible for all displaying everything to the user.
Such as, hot sports, other players, teachers, messages, and all interaction between the player and the
environment.
1.3 Software Context
The purpose or real reason for the development of the Watson Game is to provide a tool for
introducing new Watson students or possible students to the environment of Binghamton University. They
will be able to see the engineering building exactly how it is in real life, learn where important teachers in
the field work, possible problems they will come across during their college years, and a small sample of
what they will expect to learn. The game is a great tool for recruiting and giving students a head start. By
playing the game they can learn such things as where to go get their lab top fixed, where to go when they
are hungry, and where teacher’s offices are located. The game is something that could make the transition
into college a little easier and comfortable.
1.4 Major Constraints
Major constraints that could impact the manner in which the Watson Game is specified, designed,
implemented or tested is the way the game is implemented. Those that work on the game are students in a
senior seminar class who only get about three fourths of a semester to look at the existing code and come
Class: CS-495 Spring 2005
Project: The Watson Game
Function: Client
Subsystem: Integration of Residential Life Challenges
Author: Joshua Ruff
Date: 05/08/2005
up with a possible solution to the problem. Then where they left off is given to the following semester
resulting in a slow implementation of the software.
2. Architectural and Component Level Design of Integration of Residential Life Challenges
In the implementation of integration of residential life challenges the approach taken was to use
the existing pieces of the code that were used for very similar task.
2.1 Program Structure
The first requirement for a residential life challenge is to have a hot spot that activates the
challenge. The existing code used a vector which allowed unlimited hot spot creation. So I determined to
use the already implemented code as it was already more efficient than any other method. So hot spots for
the challenges are stored in a vector allowing fast and easy access to them. Since unlimited residential life
challenges can occur at once there is a list that will keep track of the challenges that are active or not yet
triggered. This is determined by the use of a true/false variable that will be set to true if challenge is not
activated or false if challenge is activated. This variable will be in the HotSpot class, very similar to the
design of picking put items. There is also a list that stores all challenges allowing a loop through the
challenges when needed and also retrieve the next challenge as well. After the hot spots are create they
have an identification number assigned to them and by the use of a switch statement the type of hot spot
collided with is determined and the correct action takes place.
2.1.1 Architecture Diagram
Example of a vector:
Hot Spot Vector
0
1
2
3
4
5
6
7
8
9
List
A[0]………………………….A[Capacity-1]
2.1.2 Alternatives
Other possible designs for the implementation residential life challenges were to use a list for
storing the hotpots. The problem with this is all other hot spots in the game are stored in a vector which
allows storage for unlimited hot spots. When looping through all hot spots to detect a collision the vector is
used so it would be meaningless to store residential challenge hot spots in another location.
2.2 Description for component Integration of Residential Life Challenges
In this section the process of the integration of residential life challenges will be discussed in
detail.
2.2.1 Processing narrative (PSPEC) for component Integration of Residential Life
Challenges
When the Watson Game is started everything that needs to be present at the beginning of the game
is initialized, including the residential life challenges hot spots. A call to the initialization function is made
and the hot spots are added to the vector. Hard coded messages are created for current testing purposes.
This information is sent and handles by the ClientChallengeHandler as an object of this class is created
Class: CS-495 Spring 2005
Project: The Watson Game
Function: Client
Subsystem: Integration of Residential Life Challenges
Author: Joshua Ruff
Date: 05/08/2005
running the constructor function is ran. Following the call to the initialization function and loop through
the hot spot vector is made creating collision points for all hot spots and also setting the hot spots in the
game. As you run a scene there is a call to checkHotSpotCollision function which checks to see if the user
has collided with a hot spot. By the use of a switch statement if the current hotspot in the vector is collided
with and it is a residential life challenge then the correct actions take place. The hotpot is set to no longer
active, the status list is updated, and the correct screen display is generated. When the correct screen
display is sent there is a call to the displayClientChallenge function which displays the correct message,
which is currently hard coded into the game.
2.2.2 Component Integration of Residential Life Challenges interface description
The user interface for inputs and outputs for the integration of residential life challenges is when
the game is started the hot spots are initialized inputting them into the hot spot vector. As the user plays the
game and hits these hot spots the challenges will be displayed. Further outputs will be integrated into the
game in the future such as hints and experience points.
2.2.3 Component Integration of Residential Life Challenges processing detail
In this section a detailed description of the algorithmic process will be given. As step by step
description of what happens in the code with residential life challenges.
2.2.3.1 Interface description
During the algorithmic process the residential life challenge hot spots are initialized during the
loading process of the game. After loading is finished the hot spots are present and can currently be seen
due to testing purposes. When a hot spots is hit the correct message will be displayed to the user.
2.2.3.2 Algorithmic model
Hot Spots added to vector
|
Collision points and hot spots initialized
|
During run scene checks for hot spot collision
|
Residential life challenge collision detected
|
Hot spot set not active and added to lists
2.2.3.3 Restrictions/Limitations
Currently the restrictions of the implementation of residential life challenges is that they are hard
coded into the game and do not interact with the server side of the system. There is only one challenge that
is currently hard coded into the game for testing purposes. The staring hot spot and the solution hot spot
are activated at the same time, so this needs to be changed so that the starting hot spot is only activated and
when it is collided with the solution hot spot is then activated. This will probably be solved when the
integration between the client and the server part of the software takes place. Another limitation currently
is the experience points for solving a residential life challenge are also not implemented. Again this will
probably be solved when communication between client and server takes place.
2.2.3.4 Local data structures
Local data structures used in the implementation are objects of the classes HotSpot and
ClientChallengeHandler. These are used to access needed function from those classes. When hot spots are
created they are initialized with a specific identification number used later in the process when checking for
Class: CS-495 Spring 2005
Author: Joshua Ruff
Project: The Watson Game
Date: 05/08/2005
Function: Client
Subsystem: Integration of Residential Life Challenges
collisions. Once again a vector is used to store all hot spots and access them. During hot spots collision
detection the use of a switch statement is used as each case is identified using the assigned identification
number when hot spot was created.
2.2.3.5 Performance issues
Currently the performance of the residential life challenges is not completely functional. The goal
for completion of the residential life challenges is to have all starting hot spots initialized when the game is
loading and when each hot spots is hit the corresponding solution hot spots will be added to the hot spot
vector and put into the game. All information for display purposes will be stored in a table for residential
life challenges in the database. Interaction between the client and the server group will make this possible.
As the software stands the initialization of the starting hot spots is working but the solution hot spots are
integrated at this point as well. This was mainly for testing purposes as there was not enough time to
integrate the correct method. Currently there is no interaction between the server and the client so all
display messages are hard coded into the client portion of the code.
2.2.3.6 Design Constraints
There are currently no design constraints for residential life challenges. The vector for hot spots
allows for unlimited hot spot storage and creation. When a starting hot spot is triggered the id for the
solution hot spot and its messaging and point will be stored in the database. Everything that is required for
a successful implementation of residential life challenges is possible and available in the code base.
2.3 Software Interface Description
All software interfaces to the outside world will be discussed in this section.
2.3.1 External machine interfaces
The game allows multiple players who can play from any machine that can log on to the VPN
client available at Binghamton University. The user must also connect to the server so accessibility to the
data base is active. Each user will be playing at their own location and see other players elsewhere. All
users will be able to hit hot spots and the game will keep track of what hot spots each person has hit. When
dealing with residential life challenge hot spots this is also true, any user can be working on solving any
residential life challenge depending on the which hot spot they had activated. The server will run off from
a central computer located in the engineering building.
2.3.2 External system interface
As discussed in the above section you will have to be connected through the Binghamton
University VPN client to run the game and connect to the server unless using a University computer. The
server contains all information in the database for each player. Allowing users to log out and return to the
game at the point which they left with all completed task kept up to date.
2.3.3 Human interface
The human interface of the game allows the user to see all that is present in the Watson building
along with the displaying of messages, options, and in the near future a functioning chat interface. The chat
interface will allow users to communicate with each other to just talk or communicate about strategies. The
displays for residential life challenges when completed is all hot spots will be hidden so the user will be
unaware when colliding with a challenge and this is true for the solution hot spot as well. Messages will be
displayed to the user when needed. Further discussion of the residential life challenge user interface will be
explained in the following section.
Class: CS-495 Spring 2005
Project: The Watson Game
Function: Client
Subsystem: Integration of Residential Life Challenges
Author: Joshua Ruff
Date: 05/08/2005
3. User interface design
In the following section a description of the user interface design dealing with residential life
challenges will be explained in detail.
3.1 Description of the user interface
When you start the game the user will be able to move throughout the third floor of the
Engineering Building. All rooms and features will be visible. The starting hot spots for residential life
challenges will not be visible when this section of the software is completed. When a hot spots is collided
with the user will be displayed with a message, as shown if figure 4.1. The message will contain the
residential life challenge task and how to possibly solve the problem. The user will then look for the
solution but again the hot spot will not be visible. If the user finds the correct location to solve the
challenge a message will be displayed to the screen, as shown in figure 4.2.
3.1.1 Screen images
Figure 4.1: Display of message when residential life challenge is triggered.
Class: CS-495 Spring 2005
Project: The Watson Game
Function: Client
Subsystem: Integration of Residential Life Challenges
Author: Joshua Ruff
Date: 05/08/2005
Figure 4.2: Display of message when solution of residential life challenge is found.
3.1.2 Objects and actions
Objects are initialized in CWatsonGamePlay class which allows the use of the GUI function
located in CGUIButton and CGUIPanel, these objects are used to create the screen images that display the
messages for residential life challenges. When the panel and button care created for residential life
challenges they are only used to display the message to the screen. No action occurs when user clicks the
ok button, as shown in the two figures above 4.1 and 4.2.
3.2 Interface design rules
The standard method for creating the panel and button for display to user is as follows.
Example of creating panel:
clientChallengePanel.Init();
clientChallengePanel.SetSize(0.4f, 0.2f);;
clientChallengePanel.SetPosition(CVector3( 0.0f, 0.0f, -1.1f));
clientChallengePanel.SetColor(panelColor);
clientChallengePanel.SetBorderColor(CVector3(0.8f, 1.0f, 0.0f));
clientChallengePanel.SetOpacity(0.3f);
clientChallengePanel.SetBorderThickness(4.0f);
clientChallengePanel.SetTextColor(textColor);
clientChallengePanel.SetTextPosition(CVector3(-0.37f, 0.16f, 0.0f));
clientChallengePanel.SetTextShadowColor(CVector3(0.0f, 0.0f, 0.0f));
clientChallengePanel.SetLineSpacing(0.016f);
clientChallengePanel.AddLine("This is a client triggered challenge");
clientChallengePanel.SetTextFont(1);
clientChallengeMenu->AddMenuPanel(clientChallengePanel);
Class: CS-495 Spring 2005
Project: The Watson Game
Function: Client
Subsystem: Integration of Residential Life Challenges
Author: Joshua Ruff
Date: 05/08/2005
Example for creating button:
clientChallengeButtonOk.Init();
clientChallengeButtonOk.SetSize(0.06,0.02);
clientChallengeButtonOk.SetPosition(CVector3(0.00f, -0.15f, -1.0f));
clientChallengeButtonOk.SetColor(buttonColor);
clientChallengeButtonOk.SetBorderColor(textBoxBorderColor);
clientChallengeButtonOk.SetOpacity(0.5f);
clientChallengeButtonOk.SetBorderThickness(2.0f);
clientChallengeButtonOk.SetTextColor(CVector3(0.6f, 1.0f, 0.0f));
clientChallengeButtonOk.SetTextPosition(CVector3(-0.02f, -0.002f, 0.0f));
clientChallengeButtonOk.SetTextShadowColor(CVector3(0.0f, 0.0f, 0.0f));
clientChallengeButtonOk.SetText("Ok");
clientChallengeMenu->AddMenuButton(clientChallengeButtonOk);
The object clientChallengePanel is used to create the panel for message, all the following functions are part
of CGUIPanel that contains function to build the images needed. The object clientChallengeButtonOk is
used to create the button for the user to click to remove message.
3.3 Components available
All function needed to create the display for messages are available in the two classes discussed in
above section. These functions are available to all files by simply create an object of that class.
4. Restrictions, limitations, and constraints
Currently the only restrictions to the integration of residential life challenges is that there is no
code available that handles the activation of the solution hot spots when the starting hot spot is collided
with. This will need to be integrated before the implementation of residential life challenges works
correctly.
5. Testing issues
The following section will discuss the type of test that is needed to test the functionality of
residential life challenges at this point in the software.
5.1 Classes to test
The classes that will be involved in the testing of residential life challenges are
CWatsonGamePlay, HotSpot, ClientChallengeHandler, and InteractionManager. CWatsonGamePlay
currently handles the initialization of the hot spots and cration of the display. The HotSpot class is used for
its function for creating and accessing the hot spots. ClientChallengeHandler handles specification actions
for residential life challenges. InteractionManager contains a function used in the identification process of
the hot spots.
5.2 Expected software response
When testing the functionality of residential life challenges the software should respond by
displaying a hot spot directly in from of Professor Iwobi’s office and also an hot spot in front of Professor
Head’s office. The hot spots at Iwobi’s office is the staring hot spot, it will give you a message of the
triggered challenge. The hot spot at Head’s office will give you the solution message. Currently both of
these hot spots are created and made active during initialization so it is possible to hit the solution hot spot
first. The solution to this will be dealt with by next semester’s class.
Class: CS-495 Spring 2005
Project: The Watson Game
Function: Client
Subsystem: Integration of Residential Life Challenges
Author: Joshua Ruff
Date: 05/08/2005
5.3 Identification of critical components
The critical components to pay particular attention to in the testing process is the activation of hot
spots, make sure they are visible in the game. Another important part is that the correct message is
displayed at the correct hot spot. This will become more critical in future implementation.
6. Requirements traceability matrix
U1
U2
S1
S2
S3
User shall collide with starting hot
spot
User shall find solution hot spot
System shall create hot spot
System shall detect hot spot
collision
System shall display message
S1, S2, S3
S1, S2, S3
U1, U2
U1, U2
U1, U2
7. Use of mantis
During the coding process of residential life challenges the use of mantis became very important.
I was able to post messages with needs from the other sections in the project. And also see the progress of
those needs, as well as see the progress of others working on similar assignments as me. Mantis was a
great tool for fast and easy progress communication.
8. Use of subversion
Subversion was used during the coding process to be able to update the final code that you will be
putting your code into. Users when finished upload their code to subversion then when others update the
changes are added. At the end of our project a problem arose with subversion forcing use to have to
manually integrate our code together, which turned out to be a long process. As a result of this it was very
evident how helpful the use of subversion actually is as all changes are recognized and added automatically
by the program.
Class: CS-495 Spring 2005
Project: The Watson Game
Function: Client
Subsystem: Integration of Residential Life Challenges
Author: Joshua Ruff
Date: 05/08/2005