Software Requirements Specification
Geogra-Phun
1. Introduction
1.1 Purpose
The purpose of this document is to identify and outline the requirements for development of Geogra-Phun, an interactive map-based geography game. It will also provide background information about the project. This document will illustrate relationships and data-flow between the modules.
1.2 Project Description
1.2.1 Description
The Geogra-Phun game will be a map based geography game with three different modes of play.
The first mode of the game displays a random state. The player must identify the state’s name. After a set amount of time, the game will begin to display the neighboring states as a hint. Points are assessed by how quickly the player found the name of the state. An incorrect response deducts points.
In the second mode the fact that every state can be identified by a subset of its neighbors is used. In this mode the game has a state in mind, and the player is asked to identify this state. Neighboring states would be provided as clues until the player can identify the state in question. More points are given for identifying the state by its minimal identifying set of neighbors. Fewer points are given for responding incorrectly.
The third mode of the game involves a line drawn between two major cities. The player is asked to identify all of the states touched by the line. The player may also be asked to identify major cities that are touched by a line between several states.
A multi-player option will have two to four players competing in the above scenarios. The players will be competing based on their speed in identifying states in all of the above modes of play.
1.2.2 Scope
The initial design will be based on the 48 contiguous states. The design will be abstract enough to allow additional modules to be created. For instance, it should be easy to add support for other continents with little modification to the base program. The multi-player option of the game may function off one computer or over a standard TCP/IP network.
· Figure 1.2.2a Context Diagram for Geogra-Phun
1.3 Software Application Objectives
The Geogra-Phun Game needs to be written on an easily extensible game engine. The game will take advantage of modular data so that extra functionality can be added at any time with very few core modifications.
2. Data Model
2.1 Considerations
All information pertaining to a map of each state will be stored in a file. The file will have information on how to draw the state and where cities in that state are located. Questions, answers and their associated point values will also be kept in data files. These data files will be loaded at runtime.
2.2 Entity Relationship Diagram (ERD)
· Figure 2.2a Entity Relationship Diagram for Geogra-Phun
2.3 Requirements
To implement a modularized data model requires that the files be formatted in a very precise manner. Questions, answers and their point values would be kept together in the file. There is also information about which states need to be displayed on the screen for a specific question. The map images will be stored as an ordered array of points on the border along with the state name and abbreviation. A list of the neighbors of a state are also stored. A list of major cities are kept with the state information and could be displayed to the screen for specific questions.
3. Process Model
3.1 Considerations
The game is going to be composed of modules that handle their own data. There will be a module for the game control, user input, score keeping, database access and map display.
3.2 Data Flow
Diagram (DFD)
· Figure 3.2a Data Flow Diagram for Geogra-Phun
3.3 Requirements
The database files will be read and interpreted by the database access module which will pass a question pool to game control. Map information will be read in by a rasterizing module and passed to game control. The game control module will be in charge of choosing a question to ask, receive input and decide if the response was correct. The display module will display the map information based on what question game control chooses. Since the point systems may be different between games, the score-keeping module will assign and keep track of points.
4. Revised Plans
4.1 Remaining Phases
Basic design of the project has been completed. Detailed design of the interfaces for each module will continue through the development of prototypes 2 and 3. Analysis of feedback from each prototype will be used to advance the design of the game. Debugging and testing will be continuous up to release.
4.2 Estimated Completion Schedule
|
Phase |
Estimated Time for Completion |
|
Prototype 2 |
3 weeks |
|
Prototype 3 |
4 weeks |
|
User Testing |
2 weeks |
|
Debugging, testing, and completion |
2 weeks |
· Figure 4.2a Estimated Times for Phase Completions
5. Conclusion
5.1 Summary
Other enhancements to the game can be made via extensions to the modules that are defined for the base system. The ability to import new maps and questions will make the game flexible, maintainable and increase its longevity.
5.2 Conclusion and Recommendation
Given
the time constraints and technical issues, this project could be implemented by
a single group. As a graphical user
interface is implemented it should be tested by a group of people in the age
group that the program is targeted at.
5.3 Contacts
Jarrod Gray, Sandor Pethes, Jason Wendling (group 7) can answer any additional questions. Farrell Brown can be contacted at (864) 654-4278 or farrelb@bellsouth.net.