Project The Watson Game

Document Sample
Project The Watson Game Powered By Docstoc
					Project: The Watson Game Function: Client Subsystem: Integration & Testing Author: Ari Perlstein Date: 05/05/2005

Class: CS-495 Spring 2005 Project: The Watson Game Function: Client Subsystem: Integration & Testing

Author: Ari Perlstein Date:05/05/2005

1

2

3

4

5 6

7

Introduction ................................................................................................................. 3 1.1 Goals and objectives ........................................................................................... 3 1.2 Statement of scope .............................................................................................. 3 1.3 Software context ................................................................................................. 5 1.4 Major constraints ................................................................................................ 5 Data design.................................................................................................................. 6 2.1 Internal software data structure ........................................................................... 6 2.2 Global data structure ........................................................................................... 6 2.3 Temporary data structure .................................................................................... 6 2.4 Database descriptio ............................................................................................. 6 Architectural and component-level design ................................................................. 6 3.1 Program Structure ............................................................................................... 6 3.1.1 Architecture diagram .................................................................................. 6 3.1.2 Alternatives ................................................................................................. 6 3.2 Description for Component n.............................................................................. 6 3.2.1 Processing narrative (PSPEC) for component n ......................................... 7 3.2.2 Component n interface description. ............................................................ 7 3.2.3 Component n processing detail ................................................................... 7 3.3 Software Interface Description ........................................................................... 7 3.3.1 External machine interfaces ........................................................................ 7 3.3.2 External system interfaces .......................................................................... 7 3.3.3 Human interface .......................................................................................... 7 User interface design................................................................................................... 8 4.1 Description of the user interface ......................................................................... 8 4.1.1 Screen images ............................................................................................. 8 4.1.2 Objects and actions ..................................................................................... 8 4.2 Interface design rules .......................................................................................... 8 4.3 Components available ......................................................................................... 8 4.4 UIDS description ................................................................................................ 8 Restrictions, limitations, and constraints .................................................................... 8 Testing Issues .............................................................................................................. 9 6.1 Classes of tests .................................................................................................... 9 6.2 Expected software response ................................................................................ 9 6.3 Performance bounds.......................................................................................... 10 6.4 Identification of critical components ................................................................ 10 Appendices ................................................................................................................ 10 7.1 Requirements traceability matrix ...................................................................... 10 7.2 Packaging and installation issues ...................................................................... 10 7.3 Design metrics to be used ................................................................................. 11 7.4 Supplementary information (as required) ......................................................... 11

Class: CS-495 Spring 2005 Project: The Watson Game Function: Client Subsystem: Integration & Testing

Author: Ari Perlstein Date:05/05/2005

SOFTWARE DESIGN SPECIFICATION

1

Introduction
The original intent of the Watson Adventure Game was to simulate the path of a Watson student through a typical eight semesters in the Computer Science program. The player must overcome challenges, while striving to maintain a high grade point average. If the player successfully navigates the challenges they will graduate. As the team leader for the client group this design specification will focus on the C++/Glut driven graphical user environment.

1.1

Goals and objectives
Although there are many goals of the Watson Adventure Game, it is easiest to view them as sub-goals of two main objectives. They are as follows: 1.) A Software Development Learning Experience: Gaining the perspective of working on a medium scale software development is essential to any Computer Science degree. As team leader this learning objective is seen as paramount. Each person in the client group was assigned varying weight problems to solve. Some students were given small independent problems while others were given dependent roles. The most difficult barrier to break was communication. Through the use of a custom list serve for the client group, a code consolidation tool (Subversion), and a bug tracking system (Mantis) we strived to reach our goals and gain a positive learning experience. 2.) A Living Watson Senior Project: Providing the Watson school with a continually updated three dimensional adventure game is useful to both the students and the school. The client is kept portable so it can be demonstrated for perspective students or other interested parties. This objective also encapsulates all of the programming done by the students that they may not have been exposed to yet, such as Open GL or protocol handling. Overall the Watson senior project provides a valuable tool for everyone involved.

1.2

Statement of scope
The following eight objectives provide a clear scope for the client’s growth this semester. 1.) Protocol Handling: Ruslan Kadylyak is to provide support for all functions that require input or output to and from the server. This function is of the utmost importance because it is depended upon by many other functions. (See graph below)

Class: CS-495 Spring 2005 Project: The Watson Game Function: Client Subsystem: Integration & Testing

Author: Ari Perlstein Date:05/05/2005

2.) Open GL Update and Repair: John Basias and Matt Berger were to provide Open GL graphics support to the client group. This includes repairing the current door models, placing new elements in the GUI, and supporting functions in which other persons in the team might have less then adequate experience. This is the other important bottleneck to the integration of the client GUI this semester. 3.) Elevator Installation: Anthony Morrow was to install the elevator, a new element into the Open GL environment. It is supposed to be a new container in which players can enter and choose a floor. Unfortunately the other floors are not implemented yet so the elevator will not move. 4.) Integration of Residential Life Challenges: Steve Liberati was to implement new challenges that are hot spots randomly placed through the levels. The challenges are speed bumps like, “Your laptop has broken. Go to Professor Heads office for a screw driver.” He was also supposed to aid the options team with the turning on and off of hotspots. 5.) Options Panel: Mike Leighton and Juhyung Kim were to implement a new control panel that can turn on and off sounds, hot spots, and the diagnostics mode. 6.) Avatar Display: Derek Loomba was to enhance the current avatar manager to display other players that are currently playing the game. Once Ruslan finished the UDP protocol he was take the information about the other avatars from the server and display them. 7.) Display of Statistics: Carl Tsue and Phillip Fong were to take the server’s data returned by Ruslan and display some common characteristics about the Watson Adventure Game. 8.) Chat Feature: Luis Callejo and Todd Grober were to implement a new function so that players that are concurrently logged on could speak to each other over an AOL Instant Messenger like GUI. This function was also very dependent on Ruslan’s implementation of the new UDP protocol.

Class: CS-495 Spring 2005 Project: The Watson Game Function: Client Subsystem: Integration & Testing

Author: Ari Perlstein Date:05/05/2005

Juggling Interactions and Dependencies Within the Client Group

1.3

Software context
The Watson Adventure Game was intended to be used as a demonstration piece for perspective Binghamton students. It is also supposed to display a cross section of the type of work that Binghamton Computer Science students accomplish during their tenure.

1.4

Major constraints
The most basic constraint to overall design is to stay within the problems assigned to the group. There are innumerable issues that can be undertaken, but there is not enough time to handle them all. Students in the client group need to focus on their task and finish in a timely manor. If students do not complete their task promptly, others cannot gain much ground on their issues.

Class: CS-495 Spring 2005 Project: The Watson Game Function: Client Subsystem: Integration & Testing

Author: Ari Perlstein Date:05/05/2005

2

Data design

2.1

Internal software data structure
Not Applicable

2.2

Global data structure
Not Applicable

2.3

Temporary data structure
Not Applicable

2.4

Database description
Not Applicable

3

Architectural and component-level design
Not Applicable

3.1

Program Structure
Not Applicable

3.1.1

Architecture diagram
Not Applicable

3.1.2

Alternatives
Not Applicable

3.2

Description for Component n
Not Applicable

Class: CS-495 Spring 2005 Project: The Watson Game Function: Client Subsystem: Integration & Testing

Author: Ari Perlstein Date:05/05/2005

3.2.1

Processing narrative (PSPEC) for component n
Not Applicable

3.2.2

Component n interface description.
Not Applicable

3.2.3

Component n processing detail
Not Applicable

3.2.3.1

Interface description
Not Applicable

3.2.3.2

Algorithmic model (e.g., PDL)
Not Applicable

3.2.3.3

Restrictions/limitations
Not Applicable

3.2.3.4

Local data structures
Not Applicable

3.2.3.5

Performance issues3.2.3.6 Design constraints
Not Applicable

3.3

Software Interface Description

3.3.1

External machine interfaces
Not Applicable

3.3.2

External system interfaces
Not Applicable

3.3.3

Human interface
Not Applicable

Class: CS-495 Spring 2005 Project: The Watson Game Function: Client Subsystem: Integration & Testing

Author: Ari Perlstein Date:05/05/2005

4
4.1
4.1.1

User interface design
Description of the user interface
Screen images
Not Applicable

4.1.2

Objects and actions
Not Applicable

4.2

Interface design rules
Not Applicable

4.3

Components available
Not Applicable

4.4

UIDS description
Not Applicable

5

Restrictions, limitations, and constraints

The biggest constraint in this software project is student motivation and time management. Due to the fact that this project is being worked on as the part of a two credit senior seminar course, the motivation that a student has can be easily stifled. Time management is also a factor because students need to finish their work in a timely manor so that it may be tested and passed onto the rest of the team. This project must also remain completely portable so that it can be easily demonstrated. Another difficult hurdle was working with the server group and their new code. The UDP protocol was never fully implemented which destroyed any hopes for implementing most of the new functionality. Often when new server code was downloaded from Subversion it would run and compile, but would constantly complain of runtime errors.

Class: CS-495 Spring 2005 Project: The Watson Game Function: Client Subsystem: Integration & Testing

Author: Ari Perlstein Date:05/05/2005

6

Testing Issues

Testing this software development was the largest problem that I had to encounter. Most students did not complete their code until the last day or shortly before the software was due. No students uploaded pieces of code early so that tests could be made preemptively. Limited testing was possible and unfortunately the finished product still has bugs.

6.1

Classes of tests

A black box testing technique was employed to ascertain progress of existing bugs with the Watson Adventure Game. After each student uploaded code to the subversion server, they sent out a message to the list serve and the software was tested to conclude feasibility. The following tests were prepared, but due to time constraints could not be completed. 1.) Graphical Testing: This consists of testing all elements that were newly placed into the environment. a. Using the improved door models and ensuring proper placement. b. Depressing all new buttons in different situations to prove continuity of code. c. Display all new panels to ensure their proper placement and accurate contents. 2.) Protocol Testing: This consists of testing the new protocols implemented to send and receive data between client and server. a. Using telnet to test the text based transmission control protocol implemented to exchange small amounts of information. b. Using Sean Egan’s custom tool to test the newly implemented protocol for transmission of concurrent player coordinates and their attributes.

6.2

Expected software response

The software currently uploaded on Subversion is not tested and contains many bugs. As team leader I made a dead line for code to be uploaded to the Subversion by Friday May 6th for testing. Only one person’s code was uploaded before that deadline, Matt Berger’s placement of the new door models. On Sunday May 8th new code was constantly uploaded and overwritten on Subversion and there was no possible way to debug. As of Sunday May 8th at 1:00 PM the code on Subversion compiled and ran, but froze immediately. Many students’ code is written, but commented out in the project files because they started to late. As of right now the only two portions I can confidently comment on are Matt Berger’s placement of the new door models and the UDP protocol. Class: CS-495 Spring 2005 Project: The Watson Game Function: Client Subsystem: Integration & Testing Author: Ari Perlstein Date:05/05/2005

Matt Berger placed instances of the door models throughout the levels in proper alignment, but the new door models by John Basias were never tested. The UDP protocol was built and implemented by Ruslan Kadylyak, but was never fully tested or integrated due to server issues and lateness of completion. It is placed on a separate folder on Subversion. As for the rest of the issues, I cannot even give status due to the tardiness of the students’ efforts.

6.3

Performance bounds

Performance for the client portion of the Watson Adventure Game can no longer be ascertained because the last update I compiled and tried to debug barely ran. There was no way to debug due to the tardiness of code updates.

6.4

Identification of critical components

The critical components to the Watson Adventure Game are the protocol handling and graphical model. The protocol handles all data transmission between client and server. The game can run in standalone mode, but functionality is decreased. The graphical model is also mission critical due the fact that the entire game depends on the proper display of graphical components to the player.

7
7.1

Appendices
Requirements traceability matrix
Section 1.2 1.4 1.4 1.4 1.4 1.4 1.4 1.4 1.4

Requirement Portability of Client Protocol Implementation Elevator Implementation Statistics Implementation Options Implementation Door Model Implementation Chat Implementation Avatar Display Residential Life Challenges

7.2

Packaging and installation issues

The following instructions were given to the client group for installation and implementation:

Class: CS-495 Spring 2005 Project: The Watson Game Function: Client Subsystem: Integration & Testing

Author: Ari Perlstein Date:05/05/2005

1.) Download the codebase here: http://www.cs.binghamton.edu/~steflik/cs495b/WatsonGame_F04/ConsolidatedC odebase/WAG_2004_Consolidated.zip a. Extract and make the whole thing an archive (uncheck read only) 2.) Download glut here: http://www.xmission.com/~nate/glut/glut-3.7.6-bin.zip a. Put glut.h in msvsdir\VC\include\GL\glut.h b. Put glut32.lib msvsdir\VC\lib\glut32.lib c. Put glut32.dll windows\system\glut32.dll 3.) Download the database here: http://www.perlstein.org/WAGDatabase.mdb a. Make it an ODBC datasource in Control Panel  ODBC sources b. Name is “Watson” and point it to the WagDatabase.mdb file 4.) OFF CAMPUS: Download the Binghamton Cisco VPN here: http://www.perlstein.org/BingVPN.exe a. Connect to the PODS domain with your typical login…this must be done before you use tortoise. 5.) Download Tortoise here: http://www.cs.binghamton.edu/~steflik/Subversion/TortoiseSVN-1.1.3UNICODE_svn-1.1.3.msi a. url: svn://bigyellowcat.cs.binghamton.edu b. username: lastname c. password: last 4 digits of social 6.) Download the new project files from subversion. a. Watson Game.dsp: This fixes the issue that CDoor.h and CDoor.cpp are not in their respective engine directories in the project. You can download this file or just add them yourself. b. (IF YOU ARE GETTING UNRESOLVED EXTERNALS DO ^ THIS ^ STEP)

7.3

Design metrics to be used

Not Applicable

7.4

Supplementary information (as required)

Mantis Bug Tracker: The Mantis system was extremely useful to aid in communication between the groups, but students should, in the future, use this tool to a greater extent. Subversion: The Subversion code consolidation tool was also irreplaceable, but code was uploaded too late to truly take advantage of its power. Most students never understood its functionality and would ask me what they were to do with completed code on Sunday May 8th even though I had sent numerous emails all semester pertaining to it and Mantis. Class: CS-495 Spring 2005 Project: The Watson Game Function: Client Subsystem: Integration & Testing Author: Ari Perlstein Date:05/05/2005


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:2/1/2010
language:English
pages:11