Project: The Watson Game



Project: The Watson Game

Function: Database

Subsystem: Overall Database Responsibility

Author: Marc Van Gelder

Date: 5/8/2005

1 Introduction 4

1.1 Goals and objectives 4

1.2 Statement of scope 4

1.3 Software context 4

1.4 Major constraints 4

2 Data design 5

2.1 Internal software data structure 5

2.2 Global data structure 5

2.3 Temporary data structure 5

2.4 Database description 5

3 Architectural and component-level design 7

3.1 Program Structure 7

3.1.1 Architecture diagram 8

3.1.2 Alternatives 8

3.2 Description for Component 1: ‘elevator’ Table 8

3.2.1 Processing narrative (PSPEC) for Component 1 8

3.2.2 Component 1 interface description. 9

3.2.3 Component 1 processing detail 9

3.3 Description for Component 2: ‘lifechallenges’ Table 9

3.3.1 Processing narrative (PSPEC) for Component 2 9

3.3.2 Component 2 interface description. 10

3.3.3 Component 2 processing detail 10

3.4 Description for Component 3: ‘objectlist’ Table 10

3.4.1 Processing narrative (PSPEC) for Component 3 10

3.4.2 Component 3 interface description. 11

3.4.3 Component 3 processing detail 11

3.5 Software Interface Description 11

3.5.1 External machine interfaces 12

3.5.2 External system interfaces 12

3.5.3 Human interface 12

4 User interface design 12

4.1 Description of the user interface 12

4.1.1 Screen images 12

4.1.2 Objects and actions 12

4.2 Interface design rules 12

4.3 Components available 12

4.4 UIDS description 13

5 Restrictions, limitations, and constraints 13

6 Testing Issues 13

6.1 Classes of tests 13

6.2 Expected software response 13

6.3 Performance bounds 13

6.4 Identification of critical components 13

7 Appendices 14

7.1 Requirements traceability matrix 14

7.2 Packaging and installation issues 14

7.3 Design metrics to be used 14

7.4 Supplementary information (as required) 14

7.5 Mantis 14

7.6 Subversion 14

SOFTWARE DESIGN SPECIFICATION

Introduction

The Watson Game (WAG) is a three-dimensional interactive multiplayer online role-playing game currently based on Binghamton University’s Watson Building. New players start the game as a freshman and progress through each of the four years of college until graduation. Academic and life challenges measure each player’s progress through the game.

1 Goals and objectives

The objective of the game is to succeed in the progression from freshman to graduation in 4 years with the highest possible GPA. The player’s information is stored in a Microsoft Access Database. There will be a set number of academic challenges per school year to reach the next rank. Life challenges will occur at different locations and times throughout the game. The end of the game is accomplished when the player graduates.

2 Statement of scope

The Watson Game consists of a server, client, web-client, and database. The server communicates with the database through the SQL language to obtain information requested by the client. The database contains all of the stored information needed throughout the game. This includes information such as faculty, elevator, and knapsack. The web-client allows a browser with a required plug-in to interface with the Watson Game, instead of using the client software. The client software is a three-dimensional interface for use by the users to interact within this game.

3 Software context

The original intent of this software was for use within Binghamton University’s Computer Science Program. It is a project that is continually worked on by sections of CS 495. This game is intended to be expanded, eventually cover the Watson Building, and then to the rest of the campus. In the end, it is to be used as a recruiting tool for Binghamton University.

4 Major constraints

The only two major constraints are time and communication. Each semester there is only about four weeks to complete improvements to the Watson Game. Communication between individuals and groups is key. Busy schedules prevented everyone to really coordinate meeting times. Each group had a different idea on how the game should progress.

Data design

The database is a Microsoft Access database. There are currently 15 separate tables, which are challenge, character, coordinate, course, doors, elevator, faculty, hotspot, knapsack, lifechallenges, npcharacter, object, objectlist, prerequisite, and question. All of the data needed throughout the game are saved in these tables.

1 Internal software data structure

The challenge table contains the questions and answers for each of the academic challenges. The character table consists of the user’s attributes, completed challenges, and other required information. The coordinate table holds the coordinates of items and hotspots. The knapsack table has the items that each user has in their knapsack. The object table contains the name, weight, and description of all the objects in the game. This table is linked to the objectlist table, which allows the user to obtain the item, and now allows how many.

2 Global data structure

All of the tables are available to be used by the server and client.

3 Temporary data structure

There are currently four tables that are not used yet in the game. These tables are course, npcharacter, prerequisite, and question. The course table contains the Computer Science courses needed to graduate. The npcharacter table has the location and attributes of non-player characters. The prerequisite table shows what courses must be done prior to taking the core courses listed in the course table. The question table has questions and answers posed to show the player around the game.

4 Database description

The database used is a Microsoft Access database. There are 15 tables currently involved.

challenge – Contains the questions and answers used in the various courses.

character – This contains the player’s information. Some of these attributes will be eventually used to affect game play.

coordinate – This table represents a three dimensional point in the game space.

course – This contains the college courses that are required in order to advance in the game or to graduate, if they are already a senior.

doors – This table represents the door at each office and whether they are open or closed.

elevator – This new table represents the elevator, what floor it is on, and whether the doors are open or closed.

faculty – This contains the members of the Binghamton University Watson building faculty. These members may pose challenges or provide hints.

hotspot – Contains the points in the three dimensional space that signals the beginning of a challenge whenever the player walks into it.

knapsack – This represents a bag that the player carries with them. Currently, there is no cap on the number of objects per knapsack.

lifechallenges – This represents life challenges that players may face in the real world. There are a set number of experience points (XP) that the player can gain or lose depending on what they choose to do about the challenge.

npcharacter – This contains the non-playing characters. NPCs may pose questions or comments to the player and generally hinder progress in the game.

object – This represents an object in the game, such as a pencil, paper, or piece of paper.

objectlist – This represents what object is in what knapsack and how many of the item there are.

prerequisite – Contains the courses that are required to have been taken before the current wanted course.

question - This represents a question posed to the player. This isn’t currently implemented.

Architectural and component-level design

The Watson game is built from three main components: the server program, the client program, and the database. There is an optional fourth component for playing the game from within a web browser. This is the web-client program.

1 Program Structure

There are eleven relationships between the tables. Based on the requirements, they were either one-to-one or one-to-many. The relationships are shown here:

▪ course and prerequisite (one-to-many) – Linked by CourseID. This relationship shows which courses are prerequisites to the core CS curriculum classes. It is not being used in this implementation.

▪ course and faculty (one-to-many) – Linked by CourseID. It determines which faculty member teaches a specific CS course. Not used in implementation.

▪ course and challenge (one-to-many) - Linked by CourseID. This relationship determines which challenge questions belong to a CS course.

▪ challenge and faculty (one-to-many) – Linked by ChallengeID. This relationship shows which professor extends a specific challenge.

▪ hotspot and faculty (one-to-many) – Linked by HotSpotID. Determines the relationship between the professor’s office and the hotspot associated.

▪ hotspot and coordinate (one-to-many) – Linked by CenterCoordinateID. This shows at which coordinate a hotspot is located.

▪ hotspot and npcharacter (one-to-many) – Linked by HotSpotID. This relationship shows where a non-playing character is considered a hotspot in the game. It is not being used in this implementation.

▪ question and npcharacter (one-to-many) – Linked by QuestionID. This relationship shows which questions are being asked by a non-playing character.

▪ knapsack and character (one-to-many) – Linked by KnapsackID. This relationship identifies the knapsack associated with that character.

▪ knapsack and objectlist (one-to-one) – Linked by ObjectListID. This relationship is used to show which objects are currently in the knapsack.

▪ ObjectList and Object (One-to-Many) – Linked by ObjectID. This relationship links the characteristics of the objects to the object list.

1 Architecture diagram

[pic]

2 Alternatives

There are no alternative architectural styles used for the database.

2 Description for Component 1: ‘elevator’ Table

1 Processing narrative (PSPEC) for Component 1

The elevator table contains three fields. The primary key is the ElevatorID field, which shows what elevator is being queried. This key is an automatically incremented positive number. The fields are shown as follows:

ElevatorID – primary key, number, required (no duplicates)

Location – text, 2 character limit, required

StateOfDoors – text, 10 character limit, required

2 Component 1 interface description.

All interaction is done via the Structured Query Language (SQL)

3 Component 1 processing detail

There is no algorithmic behavior with this table.

1 Interface description

Not applicable.

2 Algorithmic model (e.g., PDL)

Not applicable.

3 Restrictions/limitations

See section 3.2.1 for the field restrictions.

4 Local data structures

Not applicable.

5 Performance issues

As the database size increases, the search time will increase, but this isn’t a problem that is anticipated anytime in the near future.

6 Design constraints

The field restrictions are described in section 3.2.1.

3 Description for Component 2: ‘lifechallenges’ Table

1 Processing narrative (PSPEC) for Component 2

The lifechallenges table contains four fields. The primary key is the LifeChallengeID field, which shows what life challenge is being queried. This key is an automatically incremented positive number. The fields are shown as follows:

LifeChallengeID – primary key, number, required (no duplicates)

LifeChallengeName – text, 50 character limit, required

Points – number, integer, required

HotSpotID = number, integer, required (duplicates ok)

2 Component 2 interface description.

All interaction is done via the Structured Query Language (SQL)

3 Component 2 processing detail

There is no algorithmic behavior with this table.

1 Interface description

Not applicable.

2 Algorithmic model (e.g., PDL)

Not applicable.

3 Restrictions/limitations

See section 3.3.1 for the field restrictions.

4 Local data structures

Not applicable.

5 Performance issues

As the database size increases, the search time will increase, but this isn’t a problem that is anticipated anytime in the near future.

6 Design constraints

The field restrictions are described in section 3.3.1.

4 Description for Component 3: ‘objectlist’ Table

1 Processing narrative (PSPEC) for Component 3

The objectlist table contains three fields. The primary key is the ObjectListID field. This key is an automatically incremented positive number. The fields are shown as follows:

ObjectListID – primary key, number, required (no duplicates)

ObjectID – number, integer, required

NumberOf – number, long integer

KnapsackID = number, integer, required (duplicates ok)

2 Component 3 interface description.

All interaction is done via the Structured Query Language (SQL)

3 Component 3 processing detail

There is no algorithmic behavior with this table.

1 Interface description

Not applicable.

2 Algorithmic model (e.g., PDL)

Not applicable.

3 Restrictions/limitations

See section 3.4.1 for the field restrictions.

4 Local data structures

Not applicable.

5 Performance issues

As the database size increases, the search time will increase, but this isn’t a problem that is anticipated anytime in the near future.

6 Design constraints

The field restrictions are described in section 3.4.1.

5 Software Interface Description

The client and server software communications to the database using the Structured Query Language (SQL)

1 External machine interfaces

Not applicable.

2 External system interfaces

Not applicable.

3 Human interface

Not applicable.

User interface design

There is no human interface for the database.

1 Description of the user interface

Not applicable.

1 Screen images

Not applicable.

2 Objects and actions

Not applicable.

2 Interface design rules

Not applicable.

3 Components available

Not applicable.

4 UIDS description

Not applicable.

Restrictions, limitations, and constraints

The Watson Game currently relies on a Microsoft Access database for the disconnected mode. The database is to be ported to MySQL so that it isn’t tied to any one operating system. The client program, doesn’t have any such dependency, and should be usable on any operating system.

This game is not meant to be a Massively Multiplayer Online Role-Playing Game (MMORPG) and has a limit on how many concurrent connections that can be made. The limit has not been tested or explicitly implemented.

Testing Issues

Databases are not usually tested, since they only contain data. Often the queries used to request or modify data do have to be tested fully before being used in a finished product.

1 Classes of tests

Each query is currently written using Microsoft Access using the Structured Query Language (SQL). The white-box testing method will be used to determine whether the expected result has occurred. Black-box testing is not necessary at this point.

2 Expected software response

Each query is expected to return the requested rows, values, and formats specified.

3 Performance bounds

Not applicable.

4 Identification of critical components

The queries used for courses, challenges, and hotspots are the most important. The queries for the npcharacter, questions, and prerequisite are the least critical at this stage of game play.

Appendices

1 Requirements traceability matrix

Request# Request Section

1. Needs an elevator table 3.2.1

2. Needs life challenges table 3.3.1

3. Needs to keep the number of each object in each knapsack 3.4.1

2 Packaging and installation issues

This software should at a minimum be portable so it can be run on any chosen operation systems. These include Windows, Linux, and Macintosh. The database, when totally ported, to MySQL, will then be able to be run on any operating system.

3 Design metrics to be used

Not applicable.

4 Supplementary information (as required)

Not applicable.

5 Mantis

This is the bug/issue tracker used. All three database components had an initial bug submitted to this system. Each issue was resolved and comments were added to Mantis.

6 Subversion

All database updates were centrally located in the subversion repository. This was used as a replacement for the old concurrent versions system (CVS).

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download