CS4500 Software Requirements Specification

February 5, 2008

Team Here For Beer



1. Introduction

1.1 Purpose of this Document

This is the Software Requirements Specification for Team Here For Beer's Tower Defense game. This document will outline the software design and specification of our Tower Defense Game. The Tower Defense Game is a DirectX based Real-Time strategy game targeted to the Windows platform.

1.2 Scope of the Development Project

The Here For Beer Tower Defense (HFBTD) game is a Real Time Strategy (RTS) game built for the Windows Operating System. HFBTD will be built using the DirectX graphics API.

1.3 Definitions, Acronyms, and Abbreviations

  • DX9 - DirectX 9
  • HFBTD - Here For Beer Tower Defense
  • RTS - Real Time Strategy
  • SRS - Software Requirements Specification
  • Twitch Game - A type of game where users must react quickly to circumstances in order to continue playing (such as Tetris)
  • UI - User Interface
  • Wave - A Group of Enemies, or other entities that will arrive, and attempt to depart together.

1.4 References

Flash Tower Defense Game, Vector Based
Another Tower Defense Game
DirectX 9 Tutorial

1.5 Overview of Document

This document contains all of the software requirement specifics. There is a general description of who is going to use our application, how it is going to work, and what technologies we are using to make it work. We also outline and describe specific parts of the project.

2. General Description

2.1 User Personas and Characteristics

  • Casual Gamer: This type of person plays games on the weekends in short bursts. They are familiar with videogames, but may not be as experienced at twitch style gameplay and complex control schemes.
  • Core Gamer: This type of person plays games for a few hours per day, minimum. They are quite comfortable with all types of videogames, especially games that involve complex control schemes involving multiple sets of hotkeys. These types of players enjoy difficult challenges and tend to gravitate towards harder difficulty settings.

2.2 Product Perspective

This game is a standalone game, meant to be played by a single player on a single machine. However, there will be a webservice that the game may optionally report scores to. This webservice will save high-scores and track the scores of other players. Messages will be exchanged between the webservice using the http protocol.

This product is built to run on a Windows machine using DirectX 9. The user must have a DirectX 9 capable graphics card, an Intel Pentium 4 or higher class cpu with no less than 512MB of memory.

2.3 Overview of Functional Requirements

  1. Must be a video game in the RTS genre.
  2. Must allow complex control schemes for advanced users, and simple controls for common users.
  3. Must be easy to learn for Casual Gamers, but complex to master for Core Gamers.
  4. Must contain a simple UI for easy interaction with the user.

2.4 Overview of Data Requirements

High scores will be reported to a webservice to track high scores of players.

2.5 General Constraints, Assumptions, Dependencies, Guidelines

This game will require a computer with DirectX 9 or later. It may also require a connection to the internet if the player wants to submit their high score. It should run on any Windows operating system, though Windows Vista is not officially supported.

2.6 User View of Product Use

  • User Starts the Program
    • Main Menu:
      • Start Game
        • Start a new game. The User will move to the Game Play Screen.
      • View High Scores
        • The User will be sent to a website to view the Web based Score Tracking System.
    • Game Play Screen:
      • The User will first be presented with some options to configure the game. The options include:
        • Map Type
        • Difficulty Setting
      • Once the user has selected their desired parameters, they are dropped right into the game.
      • The HFBTD game requires only the mouse to play, however keyboard shortcuts may be available.
      • Game Play will take play in the following fashion:
        1. The User will start with 0 Towers built, and a small amount of money. The Grid will be partially covered with pathways for enemies, but will be largely open Grid Space.
        2. The User may Select a Tower type from the list of tower types on the right hand Navigation. If the user can afford it, they may buy said tower by placing it on an empty Grid Square on the Map. The User can build towers at any time provided they have appropriate room and resources.
          1. Existing towers on the Grid can upgraded as well for a fee. This will increase the Tower's Damage Rate / Fire Rate / Hit Ratio.
        3. There will also be a button labeled "Send Enemies", which will do what it sounds like, and send a "Wave" of enemies. The Wave of enemies will enter the Grid from one side of the Enemy path, and leave through the other side (All maps will have paths with only two points of contact with the edge of the grid).

Game Objectives

  • The User needs to prevent as many Enemies as possible per wave from reaching the end of the path. They do this by strategically placing towers along the path the enemies take.
  • For each enemy killed, the User will gain a small amount of money which they can use to purchase new towers or upgrade existing towers.
  • For each enemy in the wave that makes it through the grid successfully (i.e. The User's towers were not able to destroy the enemy), the User will lose one Life point.
  • If all the enemies in the wave are either destroyed, or make it through the grid, the wave is over. Another wave will not begin until the user starts the wave by clicking the "Send Enemies" button.
  • If the User makes it through all the waves, the game is over, the user has won, and is asked to upload their final score.
  • If the User looses all Life points, then the game is over, the user has lost, and is asked to upload their final score.
    • Web Based Score Tracking System
      • There will be a Web Front end programmed in Flash. This will allow the user to parse through the submitted high scores in an intuitive fashion.

3. Specific Requirements

3.1 External Interface Requirements

Operator/user interface characteristics from the human factors point of view

  1. Mouse Interface allows the user to point and click on towers to place them on the map.
  2. Keyboard Shortcuts will allow quick selection of a tower so it can be placed directly on the map.
  3. A button to send the enemies/start the next round.
  4. A current score display.
  5. Auto highlighting boxes on the grid so the user knows which box the tower will be placed on.

Characteristics required of the interface between the software product and each of the hardware components

  1. The interface will use the DirectInput library from DirectX 9.0 for mouse and keyboard input.
  2. Any mouse and keyboard that works with DirectX will be sufficient for our product.
  3. A video card that supports DirectX 9.0b.

Interfaces with other software components or products, including other systems, utility software, databases, and operating systems

  1. The webservice that publishes a players scores.
  2. Sends a players name and score via an http get request at the end of a game.
  3. This webservice will maintain a database of previous scores for all players.
  4. Serves a webpage providing a user access to previous scores and top scores.
  5. DirectX 9.0 libraries (DirectInput and Direct3D) WindowsXP/Vista Only.

3.2 Detailed Description of Functional Requirements

3.2.1 Template for describing functional requirements

Purpose A description of the functional requirement and its reason(s)
Inputs Which inputs; in what form/format will inputs arrive; from what sources input will be derived, legal domains of each input element
Processing Describes the outcome rather than the implementation; include any validity checks on the data, exact timing of each operation (if needed), how to handle unexpected or abnormal situations
Outputs The form, shape, destination, and volume of the output; output timing; range of parameters in the output; unit measure of the output; process by which the output is stored or destroyed; process for handling error messages produced as output

3.2.2 Map Selection UI

Purpose The map selection user interface is the first thing displayed to the user. It gives them the ability to choose different maps (classified by their difficult level).
Inputs The user will select the map they would like to play.
Processing The map will be loaded by the game engine and map state will be set to an empty grid of locations where the player can build turrets.
Outputs The selected map will be displayed and gameplay can then begin.

3.2.3 Main UI

Purpose The main UI contains a graphical list of towers that can be built or upgraded, buttons for controlling the game (such as sending a wave of enemies or quitting) and game information such as score, cash on hand, etc.
Inputs The user will select a tower that they would like to eventually place on the map or select a button to control the game.
Processing X/Y locations of the mouse will need to be checked to make sure the clicked location is valid. Because each tower costs a certain amount of money, the amount of money will need to be verified before allowing the user to select the clicked on tower. If the user clicks a button, the button's action will be executed.
Outputs If a player clicked a valid tower, it will be highlighted to inform the user of the currently selected tower. Score and cash information will be continuously updated as the player plays the game. If the player clicked a button, the button's action will be executed (such as quitting the game or sending a wave of enemies).

3.2.4 Map

Purpose The purpose of the map is to give the player an area to build towers. It is a 2-D grid with predescribed locations where the player can build turrets. It also defines the path enemies will take through the map during gameplay.
Inputs The user will click on grid boxes embedded throughout the map to indicate where towers should be placed.
Processing The location of tower placement will be checked to make sure it's a valid location and that no towers already exist at the location.
Outputs The output will be the tower being placed in the location the user has selected.

3.2.5 Gameplay

Purpose This is the main portion of the game where the user sends waves of enemies through the selected map. The turrets the player has built will then destroy as many enemies as possible.
Inputs The inputs will be the type of enemies to send on each wave and the difficulty of killing each enemy (enemies require a certain number of hits from turrets before they are destroyed). It becomes more difficult to kill enemies as the player progresses, so the current level of the player will also be an input.
Processing The game state will change based on how many enemies are killed. Enemies will be removed from the screen when they are destroyed. The number of enemies that traverse the map without dying will be kept track of.
Outputs The score and amount of cash will increase for each enemy killed. The difficulty level will increase after each wave of enemies. If any enemies traversed the map without dying, the player will lose a life. If the player has lost all lives, their game is ended.

3.2.6 High Score

Purpose The high score functionality allows players to submit their high scores to a centralized database to compare their gameplay abilities with other players.
Inputs When the user finishes playing a map, they will be asked to enter their name. The high score and map name are also inputs.
Processing To prevent fake high scores from being submitted, the submitted information is appended to a secret key and then hashed. The centralized database performs the same operation to make sure that the submitted information was hashed with the same secret key. The submitted information is then stored in a MySQL database.
Outputs The output of the high score interface is a flash-based frontend listing the high scores, name, and possibly map name the high score is associated with.

3.3 Performance Requirements

We need to maintain at least 20 frames per second during gameplay.

3.4 Quality Attributes

The application is very self-contained. All attempts will be made to deal with and check errors. Coding is done in an object-oriented fashion to allow for easier maintainability and extensibility.

3.5 Other Requirements

None at this time