What kind of game are you planning to build?
We plan to build a racing/shooting game with a capture-the-flag emphasis, using a Transformers First Generation motif.

What are the goals of the game, how do players win, how do they lose?
The goal of the game is to accumulate as many points as possible. Players can gain points by damaging each other or reaching a specified point (the flag) first and returning it to another specified point. The game ends when a predetermined number of flags is captured or when a time limit is reached (user-configurable).

What are the interesting or unique aspects to your game?
There are 2 basic modes of gameplay, where we implement both a racing and a shooting game with Autobots from Transformers. Players have the ability to switch between modes, whichever is more advantageous. Once the flag is retrieved, other players will gang up on the flag carrier.

What are the list of features of your game? Prioritize them into at least three categories: "Must Have", "Would Be Really Nice", and "Cool But Only If Ahead Of Schedule".

"Must Have"
Must be (of course) 3D, distributed multiplayer, and real-time.
Must have a driving component with basic steering, acceleration, braking, top speed, etc.
Must have a shooting component with projectiles, damage, energy requirements.
Must have radar or some detection system.
Must have basic user-interface.
Must have basic user input capabilities (keyboard and mouse), with separate interfaces for both robot (shooting) and car (driving) modes.
Scoring system must be implemented.
Maps/levels (at least 2) must be implemented
Explosions
Timing is required.
Collision detection and resolution (however minimal) is required

"Would Be Really Nice"
Physics (momentum, ballistic motion, friction)
Improved collision detection and resolution (car spin-outs)
View changes (from first to third person), rotating camera, instant replay
Introduction
Music, sound effects
Multiple weapons and power-ups (turbo-boost, missiles)
Special capabilities (Mirage turning invisible)

"Cool But Only If Ahead Of Schedule"
Particle systems
Allow trash talking during the game
Storyline

2.Group Management

What are the major roles in your group's management?
Spokesman - Matt Devico

How will decisions be made? By leader, consensus?
Consensus

How will you communicate? Email, meetings in the lab, discussion board?
Email, meetings in the lab, discussion board

How will you know when you're off schedule, and how will you deal with schedule slips?
If the milestone for a given date is not reached, then we are behind schedule.
First, we will have a backup person to help the other who fell behind. We will also have code review. Also, if the problem is completely infeasible, we will have a specification change. Finally, we will prioritize the problems we have at the moment and concentrate on the critical slip-ups. We will push back on the others, perhaps delaying implementation or debugging of those items until alpha or beta testing. Since we are all CS majors, it also goes without saying that we will sacrifice sleep if behind schedule.

How will you produce the weekly group status reports? Individually, by a documentor?
Weekly group status reports will be done individually and turned in at the instructor/group meetings.

3.Project Development

What are the development roles and who will handle them?
Edwin Cheung - graphics
Matt Devico - graphics
Duc Truong - networking
Don Quach - basic game design and collision detection/resolution
Leo Mortero - input, integration
Stan Chin - game engine coding

What tools will you use?
Visual C++, DirectX 8.0, maybe SoundForge, CakeWalk, Quake 2 + Transformers TC

How will you do testing?
Play the game. We will also unit-test each individual component as we implement it. There will be a basic integration test over the range of inputs for the components, but we hope to catch most bugs with logic and game playing. We will catalog bugs with a simple web page (bug #, bug severity, description, owner, component, date, resolution).
How will you do documentation (both internal group documentation as well as external player documentation)?
We will have in-code comments that we can strip out with a basic parser that will describe components. When we check in a file, we will also put in descriptions of what was changed.
For player documentation, we will have a small README file.

4.Project Schedule

Define a set of milestones with a specific definition of what each milestone is, what it means to complete each milestone, and when you expect to complete them. Define the milestones at two scales, a high level set of key milestones like integration and design freeze, and a low level set of weekly milestones.