Raisin Brand

Village DefenseTM
Software Design Document

Vincent Speckner, Harrison McLain, Brody Hudson

Software Design Document

TABLE OF CONTENTS
1.

INTRODUCTION

1.1

Purpose

1.2

Scope

1.3

Overview

1.4

Reference Material

2.

SYSTEM OVERVIEW

3.

SYSTEM ARCHITECTURE

4.

3.1

Architectural Design

3.2

Decomposition Description

3.3

Design Rationale

DATA DESIGN

4.1

Data Description

4.2

Data Dictionary

5.

COMPONENT DESIGN

6.

HUMAN INTERFACE DESIGN

6.1

Overview of User Interface

6.2

Screen Images

6.3

Screen Objects and Actions

1. INTRODUCTION
1.1 Purpose
This document is intended to identify and/or further clarify the purpose of Village Defense
(henceforth referred to as our game) and the design choices we have decided upon for its
making.
For further information on the game itself, view the Project Proposal document.

1.2 Scope
While the scope will be expanded to encompass as many features as possible given the fixed
development timeframe, the minimum scope is to include all listed A features on our
1

Software Design Document

Features List document. The development process can be considered complete at that point,
however implementation of the B list features is the target that we shall aim for.
The benefit of achieving this level of scope will be maximizing time efficiency; all necessary
features will be present and minimal time will be spent on excessive or redundant content.

1.3 Overview
This document will go on to explain and elaborate upon the following things:

Overview of the system itself

System architecture

Various design choices

1.4 Reference Material

Separate documents referenced to in this one include:

Features List

Project Proposal presentation document

2. SYSTEM OVERVIEW
The game is designed as a Java application that can run on any computer using minimal
resources. It will be activated by one driver file that will run all other processes, all of which will
be within one package file.

3. SYSTEM ARCHITECTURE
3.1 Architectural Design
The game makes use of several distinct modules that each process and display information.
2

Software Design Document

The first system is the underlying code that applies globally and contains variables tracking
resources and scores. The majority of the base games code is in that module.
The second module is the persistent terrain map. It consists of an array of JPanels that
together consist a grid. On this grid the tiles are displayed to make the games map. Trees,
walls, and other types of terrain that will not often change are handled by this system. It must
be capable of detecting when a tile must change, finding the appropriate image from a tileset
array, and then rendering the map again.
The third module is a similar grid, although it is invisible and will appear as a layer over the
terrain map. This will handle the actions of character sprites and other things that move
across the map regularly. It must also manage pathfinding through interaction with the terrain
map to check for obstacles.

((Provide a diagram showing the major subsystems and data repositories and their
interconnections. Describe the diagram if required. ))

3.2 Decomposition Description

((Provide a decomposition of the subsystems in the architectural design. Supplement with
text as needed. You may choose to give a functional description or an objectoriented
description. For a functional description, put top level data flow diagram (DFD) and structural
decomposition diagrams. For an OO description, put subsystem model, object diagrams,
generalization hierarchy diagram(s) (if any), aggregation hierarchy diagram(s) (if any),
interface specifications, and sequence diagrams here.))

((

)) Means we do not have the relevant information for this section

3.3 Design Rationale

((Discuss the rationale for selecting the architecture described in 3.1 including critical issues
and trade/offs that were considered. You may discuss other architectures that were
considered, provided that you explain why you didnt choose them.))

Software Design Document

4. DATA DESIGN
4.1 Data Description
((Explain how the information domain of your system is transformed into data structures.
Describe how the major data or system entities are stored, processed and organized. List any
databases or data storage items.))

4.2 Data Dictionary

((Alphabetically list the system entities or major data along with their types and descriptions.
If you provided a functional description in Section 3.2, list all the functions and function
parameters. If you provided an OO description, list the objects and its attributes, methods and
method parameters.))

5. COMPONENT DESIGN
((In this section, we take a closer look at what each component does in a more systematic way. If
you gave a functional description in section 3.2, provide a summary of your algorithm for each
function listed in 3.2 in procedural description language (PDL) or pseudocode. If you gave an
OO description, summarize each object member function for all the objects listed in 3.2 in PDL
or pseudocode. Describe any local data when necessary.))

6. HUMAN INTERFACE DESIGN

6.1 Overview of User Interface
Certain keys will be bound to specific action that will allow for quick reactions to situations.
Each of these keys will have a separate icon that can be clicked if you are not sure what to
do.

6.2 Screen Images

JPanel will be used to incorporate 32x32 sprites into the overall view, these images have a
counter image to simulate movement, and they will be constantly switched to make the
images seem like they are moving.

Software Design Document

6.3 Screen Objects and Actions

On either side of the screen, there will be either options for adjusting random elements of the
game such as music volume, sound volume, etc. The actions that can take place are if the
user clicks on the turret or defender icon and chooses where to place it down.