CS4500 Software Design Specification, Version 1 (High-Level)

February 8, 2008

Team Here For Beer

1. Introduction

1.1 Purpose of this Document

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

The HFB Tower Defense Game is a DirectX based real-time strategy game targeted to the Windows platform.

1.2 Scope of the development project

A real-time strategy game titled: Here For Beer Tower Defense will be developed. The game will be made using C++ and the Microsoft DirectX 9.0 SDK. The game will be similar in genre to current hit Flash-based games (see: 1.4 References Section) but will harness the power of modern graphics hardware. The single player game will consist of a single grid space where a number of "maps" (number TBD) can appear. Each map will define a path in which the waves of enemies during that game will progress. The player can stop the enemies by building and upgrading towers on the grid, which will automatically attack enemies that are in their fire distance radius (in the tradition of typical tower based real-time strategy games).

The game will provide lasting single player value through its dynamic action and large spectrum of strategy, rather than through large amounts of graphical assets.

The project will also include a web front end programmed in Adobe Flash 9.0. The single player game can upload high scores via the internet to our server, which can later be browsed via the Flash-based front end.

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

1.5 Overview of Document

This document will contain specifics about the design of our software. It is a high level explanation of how the game will function, and which components will be developed to help it do so. This document will also serve to explain the technologies used to develop the application, as well as the user's interaction with the application.

2. System Architecture Description

2.1 Overview of Modules / Components

• Game Application - HFBTD will consist of two main components running on independent threads (to seperate CPU and graphics lag from each other).
  • Game Logic Component - This will be the main part of the project. This component will manage all the interactions during the actual gameplay between the different entities in the game. The game logic component will keep track of the following key items:
    • User keyboard / mouse interaction.
    • Enemy artificial intelligence.
    • Player tower artificial intelligence.
  • Game Rendering Component - This component of the application will run on its own thread and interact with DirectX on behalf of the application. This application will use the DirectX SDK 9.0.
• High Scores Server - There will be a small server application built to store and retrieve high scores set in the game.
• Web Front End - An Adobe Flash frontend application that will display the high scores achieved in the game thus far.

2.2 Structure and Relationships

2.3 User Interface Issues

The following image represents the main screen in the HFBTD application. The entirety of the game will take place in a screen that will look somewhat like the following:

The web interface will have a simple list based GUI for looking through the high scores that have been submitted to the database.

3. Detailed Description of Components

This will be completed in the SDSv2.

4. Reuse and Relationships to other products

Graphically, HFBTD is being designed to use a few well written graphic functions to create complex graphical effects. Inheritance will play a major role in product implementation. This will allow for ease of reuse by creating many functions that are used by all entities in the game. In addition, we will be using a small set of rendering functions together to create our graphical interface. These functions will be written as efficiently as possible and will keep us from reimplementing the same code when we could be focusing on improving the overall experience of the game. Because the goal is to learn how to use DirectX, we are not reusing any existing DirectX game or graphics engines. This is because it is far more educational for us to implement the types of things we need ourselves than it is to dig through documentation to figure out how to manipulate an available open source engine.

5. Design decisions and tradeoffs

Our threaded design will allow the game logic to be operating independent of the rendering engine. This will help the game to scale well, and play the same across multiple types of systems because timing is going to be handled in a thread separate from graphics rendering. This decision was an important one to guarantee that if a player plays this game on his grandmother's machine, followed by his own he/she will get a similar experience.

The threaded design was also created with user experience in mind. Because input is constantly happening, and the game is constantly being updated the experience for the user should feel much smoother than if input was being processed in between screen renderings.

While there are many existing frameworks and programming languages that would greatly speed up the development process, we ultimately decided that we wanted to create our game using C++ and DirectX. The elegance and efficiency of C++ helped influence the decision, but it also comes with fewer restrictions and a different type of learning curve. Creating a game engine allows much more developer creativity than figuring out how to to configure an existing one - this tradeoff alone makes C++ and DirectX our development platform of choice.

Graphically, we made the decision to use vector graphics instead of traditional 2D sprites. We are currently planning on leaving 3D graphics as a future enhancement if time allows. This creates an interesting tradeoff, but ultimately we decided to go with the more math dependent vector graphics and leave sprites behind for all parts of our game. The advantage is that we won't have to spend any time in graphics editors tweaking our small images. The disadvantage is that animating vectors requires a lot more math than masking off sprites. Because of our background in science and not art, the decision to use vector graphics makes the most sense.

6. Pseudocode For Components

It is still fairly early in the development process to give a large amount of pseudocode. The following are a few of the object designs we are using so far:

BasicEnemy extends GameEntity (class)

• Public
  • draw_me(), draws an enemy (currently an animated rotating box for test purposes).

• Private
  • Variables containing information about rotation amounts, color, radius, and location.

DirectInput (class)

• Public
  • Constructor initializes DirectInput.
  • Methods for retreiving location of mouse pointer (x/y and game grid position).
  • Methods for retreiving information about keyboard input.

• Private
  • Variables for DirectInput handles.
  • Variables for mouse coordinates and mouse button states.
  • Variables for screen information (so mouse position is always kept inside game window).

GameEntity (base class)

• Public
  • Method that must be implemented by child class to draw the object (virtual draw_me()).
  • X/Y coordinate info.

GameManager (class)

• Public
  • Methods for adding and drawing GameEntity objects.
  • Methods for retrieving game state.

• Private
  • Vector list of GameEntity objects.
  • Variables indicating state of game, such as score, paused state, lives left, current level

GameRenderer (class)

• Public
  • Variables containing information about Direct3D.
  • Methods for initializing the window and Direct3D.
  • Method that sets up screen and then tells renderable objects to draw themselves (entities, UI, etc.).
  • Methods for drawing primitive shapes (grids, lines, mouse, boxes, particles, etc.)

• Private
  • GameRenderer singleton object.

HFBTowerDefense (main entry point)

Contains _tmain() entry point, initializes and executes GameManager and GameRenderer.

Particle (class)

• Public
  • Methods that control particle movement such as velocity and acceleration.
  • Methods that control color and size.

• Private
  • Variables that keep track of particle.

Score (class)

• Public
  • SubmitScore(), static method that submits high score to web application.

• Private
  • Method for generating an MD5 hash of a string.

Thread (class)

• Public
  • Method for starting a thread.

• Protected
  • Method for class to set itself up to execute as a thread.

• Private
  • Thread handle and arguments.

7. Appendices

Not Applicable.