Documentation Standards

Team Epicurity:

Software Design Specification Outline

Version: 2.0

CS 4500, University of Utah
February 15^th, Spring 2008

SDS recommended content

1. Introduction

1.1 Purpose of this document

This is the Software Design Specification for Epicurity’s Tower Defense game. This document will outline the software design and specification of our Tower Defense Game in addition to system architecture, and software requirements as agreed upon by the customer and the project team.

1.2 Scope of the development project

Team Epicurity will develop an online Flash based Tower Defense game. Tower Defense is a genre of video games popularized by Starcraft and Warcraft 3, but has recently taken off as an online flash game. So far, however, the flash versions pale in comparison to the originals. We are determined to reduce this gap, and make one of the best tower defense games on the internet. When users first enter our web-page the flash application will launch, presenting game-play options such as difficulty and game modes.

1.3 Definitions, acronyms, and abbreviations

AS – Action Script

TD – Tower Defense

1.4 References

Desktop TD - http://www.handdrawngames.com/DesktopTD/game.asp

Vector TD - http://www.candystand.com/play.do?id=18047

Blizzard Entertainment - http://www.blizzard.com/

1.5 Overview of document

This document will contain specifications of the design of our software. It is a high level explanation of how the game will function. This document will also serve to explain the users interaction with the application.

2. System architecture description

2.1 Overview of modules / components

Components:

· Game-play window – contains a side bar with buttons to chose towers and short descriptions of the towers, a side bar across the top of the web browser displaying points, life totals, time until next wave, and resources, and the main viewing window where towers will be placed.

· Menus – Menus for selecting game-play options

· Scoreboard – Displays high scores

· Game-play Logic – Stores game state, controls target AI, tower AI, submitting scores.

Subsystems:

· Path-finding AI – the intelligence behind path decisions

· Collision Detection – used by path-finding AI to determine if a shortest path is blocked

2.2 Structure and relationships

The game-play logic stores all the information that will be displayed by the game-play window and scoreboard. The game-play window and menus will send commands to the game-play logic.

2.3 User interface issues

· Hardcore Gamer – To cater to users with this persona we will provide keyboard shortcuts that speed up game play. We want to hold their interest so they keep playing.

· Casual Gamers – The GUI should be intuitive so and simple so that people who do not game that much can play easily. We want to hook them like cocaine.

3. Detailed description of components

3.1 Component template description

Identification	The unique name for the component and the location of the component in the system.
Type	A module, a subprogram, a data file, a control procedure, a class, etc
Purpose	Function and performance requirements implemented by the design components, including derived requirements. Derived requirements are not explicitly stated in the SRS, but are implied or adjunct to formally stated SDS requirements.
Dependencies	How the component's function and performance relate to other components. How this component is used by other components. The other components that use this component. Interaction details such as timing, interaction conditions (such as order of execution and data sharing), and responsibility for creation, duplication, use, storage, and elimination of components.
Interfaces	Detailed descriptions of all external and internal interfaces as well as of any mechanisms for communicating through messages, parameters, or common data areas. All error messages and error codes should be identified. All screen formats, interactive messages, and other user interface components (originally defined in the SRS) should be given here.
Data	For the data internal to the component, describes the representation method, semantics, and format. This information will probably be recorded in the data dictionary.

3.2 Gameplay window

Identification	Game-play window
Type	Module
Purpose	Visually display the game. The inputs are keyboard shortcuts and mouse clicks and the output is a visual representation of the game state
Dependencies	Depends on the game-play logic which provides the information that is displayed
Interfaces	Contains a side bar with buttons to chose towers and short descriptions of the towers, a side bar across the top of the web browser displaying points, life totals, time until next wave, and resources, and the main viewing window where towers will be placed.
Data	Buttons and tower and target graphics

3.3 Menus

Identification	Menus
Type	Module
Purpose	Display game options and allow the user to make decisions, and to submit scores
Dependencies	Game play options menu s displayed before the game starts. Submitting scores requires final game state but is optional.
Interfaces	It has buttons and covers the screen. It communicates with the game-play logic via function calls.
Data	Buttons

3.4 View window

Identification	Scoreboard
Type	Module
Purpose	Record and display scores
Dependencies	Depends on the game-play logic and menus to provide scores and call the scoreboard
Interfaces	It is an ordered list of scores. It communicates with the game-play logic via function calls.
Data	We will store the scores in a database.

3.5 Game-play Logic

Identification	Game-play logic
Type	Module
Purpose	Stores the game state and handles all of the game-play, such as enemy AI, and handling input from the user
Dependencies	It depends on the game-play window and menus for user input.
Interfaces	It is not visible to the user. It interfaces with the game-play window and menus via function calls and data sharing.
Data	Its data will be stored in variables and possibly some data structures.

4.0 Reuse and relationships to other products

We are starting from scratch and not reusing (currently).

5.0 Design decisions and tradeoffs

We chose flash instead of Java or C++ because it is portable and easy for people to use; it doesn’t require most people to download and install any software on their computers.