Documentation Standards

Project Plan Document

Online Tower Defense

Team Epicurity

Version: 1.0

CS 4500, University of Utah
Spring 2008

1.0 Introduction

1.1 Project Overview

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.2 Definitions, Acronyms, and Abbreviations

AS – Action Script

TD – Tower Defense

1.3 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.4 Overview of Document

The rest of our Project Plan will be organized into three sections:  Project Organization, Team-Specific Aspects, and a Sketch of Requirements.  The Project Organization section is designed to discuss specific organization strategies of the coding and individual responsibilities.  The Team-Specific section is designed to describe the organization of the team, team meeting times, and individual skills of team members.

2.0 Project Organization

2.1 Process Model

We will be using a process model very similar to the Agile Coding model, with a focus on early deliverables and large amounts of user feedback.  The format of web-based TD and Flash will be extremely conducive to this process model.

·        Basic understanding of Flash and the ActionScript scripting language

·        Working Prototype of a simple Tower Defense

·        Beta Testing

·        Deliverable Tower Defense Game

·        Testing/Revision Cycle

·        Development of Additional Features

·        Final Delivery of Product

2.2 Organizational Structure and Responsibilities

We will assign specialized roles to team members with more experience (i.e. Tyler will be in charge of most of the website, since he has experience in the web design field).  Since most of the team members do not own Flash CS3, the majority of the code will be done in the lab as a group, however, this will be a by-product of our lack of CS3, and not a focus of our process model.  Therefore there will still be some amount of individual coding.

Also, all team members will share responsibility of documentation and deliverables with a rotating assignment of weekly management reports and group creation of Project Plan, SRS, SDS, and VVR/VVP documents.

·        Casey – Game-play implementation and developer

·        Mark – Lead Developer

·        Matt -  Team Leader, developer, and Thomas C. Henderson “handler”

·        Tyler – Webmaster, Network Admin, and developer

 

2.3 Organizational Boundaries and Interfaces

·        Customer(s) – Everyday user paying the TD game.  A customer will load our site and the game will launch automatically, offering game-play options.  In addition, any businesses wanting to buy banner space on our website.

·        Instructor – Oversees the project process and has final decision on any major changes.

2.4 Reviews, walkthroughs, inspections, and audits

Reviews: Similar to the agile process model, we will begin each team meeting with a short and simple overview of each member’s progress the previous week, along with any complications team members encountered.

Walkthroughs: Our walkthroughs will be a relatively informal review technique in which a developer leads the other team members through an assigned section of code, and the review team will identify possible problems and improvements.

Inspections/Audit: Our team will use Inspections and Audits as a technical review of small pieces of code with a focus on the review process and possible ways for team members to improve their code.

3.0 Team-specific aspects

3.1 Management Objectives and Prioritories

Team Epicurity is composed of Colorful People with varying schedules, therefore a large section of our team management is going to be deadline management and team meeting co-ordination.  We will be using a GoogleGroups mailing list to communicate the majority of team information, as well as scheduling requests and deadline reminders.  At the end of each meeting, we will also spend some time discussing the next meeting, and confirm that no new complications have arisen. 

Team Epicurity team management will be a largely consensus approach, with the majority ruling, with extreme cases of contention as the exemptions.

3.2 Team name

Our team name is Epicurity.  Epicurity is a sub-set, or form, of hedonism that defies traditional definitions of hedonism.  Followers of Epicurity believe that the ultimate goal in life is in fact to maximize pleasure, but they accomplish this through moderation.  Hedonists will gorge themselves on delicious foods, Epicuritists will eat delicious food, but in moderation.  We chose this name not because any of us are practitioners of Epicurity, but because it was both interesting and obscure, thus almost guaranteeing that we wouldn’t later regret the choice.

3.3 Possible Meeting Times

All team members are finished with class by 1:45 pm on each day of the week, however Casey has work until 5:30 each night, therefore evenings and weekends are the best opportunity for team meetings.

3.4 Team's Range of Skills and Experience

Summarize the skills and experience that your team has collectively. Organize this according to categories (e.g., writing code in various programming languages, project team experience, working with children); include individual names and level of skill or experience in each area. Be imaginative; think of skills that could help your team in your teamwork, in the project work, or in understanding and working with your client's needs. It is strongly recommended that you use one or more tables to present this information. A clear presentation style is to list the skills as row labels, team members as column levels, and then to fill in numeric values in the cells to indicate the strength of experience for that person in that category. Provide a key that guides interpretation of the numeric values; for consistency and ease of reference across teams, we strongly recommend using the scale 1 = very experienced, 3 = some experience, 5 = no experience.

Skill

Casey

Mark

Matt

Tyler

Programming Languages

C/C++

3

2

3

3

Java

2

1

2

3

C#

3

3

2

5

Haskell

5

5

5

2

Scheme

5

5

5

3

Web Technologies

Ruby

5

5

5

1

JSP

5

4

5

4

HTML

2

3

3

2

JavaScript

3

4

5

3

Flash/ActionScript

4

2

4

4

Tomcat

4

5

5

5

Imaginative

Being Colorful

1

1

1

1

 

4.0 Preliminary Sketch of Project Requirements

4.1 Overview of Functional Requirements

A Tower Defense game commonly consists of a group of targets moving from one or more starting points to one or more final positions with the goal of the game being to prevent the targets from reaching the final points.  A player of a TD is given a set of possible structures with strengths and weaknesses (i.e. ground or air targeting only) and a given cost.  Different versions offer a distinct path for the targets to travel, or a wide open approach with players being allowed to construct mazes for targets to pass through.  Some TD games do not allow for any targets to get past without a loss, while others provide a life total that each target that leaks through deducts from.

Online TDs are a subset of Tower Defense games, and are characterized by lower graphical requirements and usually a smaller selection of targets and defenses.  Online TDs often have scoreboards players use to compare their performance to other players, and rarely any other kind of multiplayer competition.

4.2 Overview of Data Requirements

The input for a TD game consists of mouse clicks and keyboard shortcut keys used by the players to choose and place towers, upgrade towers, and/or sell towers for resources.  The output will be a Flash based application displayed in the user’s web browser.  Since it is entirely played in a web browser, there will be no data stored on the user’s system.

4.3 General Constraints, Assumptions, Dependencies, Guidelines

The product must be Web-based.                                                                                                                                                                                                    This product requires Flash

4.4 User View of Product Use

This section should provide a user's-eye-view of using the product. This can include dramatic scenarios that demonstrate the product in operation. Describe the setting, the possible appearance of the screen(s), and give samples of the data that is stored, entered, or output.

As discussed earlier, when a player first enters our website, the Flash application will launch a short intro, and then prompt the player with some simple game-play choices, such as Difficulty Level and game modes.  After choosing game modes, the player is presented with a game board in the center of screen, with beginning tower options on the side bars.  A player can then place and/or sell towers with some starting resources, and when complete with the initial building process, will press Start.  After the Start button is pressed, each wave of targets will appear after a set amount of time.  After a set amount of levels or when a user runs out of lives, the game ends, a final score is calculated, and players are asked to give a name for their score, which is then stored on a scoreboard.

Change Log for Project Plan:

Date

Version

Description

January 29, 2008

1.0

Project Plan Document Created.