This category may be a bit redundant but consists of a compilation of other information into specific questions and answer as per project specification.  As the actual description of our game has fluidly changed throughout the development process, this specification depends heavily on my interpretation of our ideas and has a high probability of changing.

1.  Project Description

What kind of game are you planning to build?
Our game will consist of robots fighting in an arena.  They will have a Primary Weapon (melee), Secondary Weapon (projectile) and a Special Weapon which will combine to form a game flexible in its implementation of physics and faster paced than a standard FPS.  Because it takes place in an arena, it is similar to the Street Fighter genre of game; however, robots are controlled from either a first or third person point of view. 

What are the goals of the game, how do players win, how do they lose?
Players win through the calculation of their win/loss ratio.  Games will be further developed into rounds which will either be specified with a time limit or death count.  The number of rounds won will be the total score of a player. 

What are the interesting or unique aspects to your game?
The customizability of robots will, hopefully, be one of the unique aspects of the game.  In most fighting games (Street Fighter style), players are forced to use the predefined attacks and weapons that come with their character.  In most FPS games, any character can use any weapon.  However, in our game, we wish to have the unique aspects of both game types; individual robot models will have specific attacks or benefits AND robots will have the flexibility to use most or all of the weapons available.
One 'nice to have' feature we would like is a form of currency/points which can be used between deaths to purchase special weapons.
The fact that our game has the interactive feel of an FPS combined with the fast paced action of a fighting game should provide it with a lot of fun.

What are the list of features of your game?

2. Group Management

What are the major roles in your group's management?
There are no major management roles.  All our decisions are made by consensus.  However, it appears that in these first couple weeks there is a balance between the idealism of members working on other roles and the person actually implementing the module.  Although everyone wants each of the other modules to be robust, we want each of our parts to be as simple as possible.  The balance shifts toward the implementor; if you want something done a specific way, the only way to ensure of that is to code it yourself.

How will decisions be made? By leader, consensus?
Consensus, or vote if strongly split.  This strategy seems to have worked well when we originally picked a genre for our game.

How will you communicate? Email, meetings in the lab, discussion board?
E-mail, meetings in the lab nearly every other day, discussion board, AIM, phone.  The best form of communication so far is face-to-face meetings in the lab, especially because so far we have needed to make many decisions that affect the actual look and play of the game.  I anticipate that AIM will become more and more useful as we focus more on individual modules in pairs.

How will you know when you're off schedule, and how will you deal with schedule slips?
Based on the goals we set weekly in our status reports, and the goals we set in each meeting, it's easy to tell when we're off schedule.  In order to deal with the problem, we allocate more of our people to the specific module and lessen the responsibilities of the person who is behind schedule.

Who will produce the weekly group status reports?
Each member is reponsible for posting their own status reports on the webpage, in a sort of blog format.  The group status report will be written together as a group and one member will be selected to add it to the webpage.

3. Project Development

What are the development roles and who will handle them?
Graphics/Art – Johnny, Long
Networking – Eddie, Grace
Physics – Jeff, Jenn
Input – Grace, Jenn
Audio – Eddie, Johnny
Web – Eddie, Everyone
Engine – Jeff, Johnny, Everyone

What tools will you use?
Visual Studio .NET
OpenGL
DirectX
Photoshop
OGRE

How will you do testing?
Everyone will be responsible for testing their module. During integration, everyone will help test whole project.  Any large problems that members deal with can be tackled with the help of any other member familiar with the tools they are using.

How will you do documentation (both internal group documentation as well as external player documentation)?
Internal documentation is the responsibility of the person working on the module.  As long as the code is written in a modular and logical fashion, it should be enough that even if there are problems the member who wrote the code will be able to explain the logical flow of the files.
External documentation can be performed by any member (each member will have access to modify the webpage).  Status reports and meeting minutes will be posted on the webpage.

4. Project Schedule