Project Proposal
What kind of game are you planning to build?
The game will consist of multiplayer vehicle combat in an enclosed arena. Combat will be conducted by aiming at and shooting the enemy vehicles with weapons.
What are the goals of the game, how do players win, how do they lose?
We anticipate having multiple modes, each one with unique victory conditions. Primary development will be focused on one mode: free for all.
The goal of the free for all mode is to eliminate the other players. The surviving player is the winner. The goal for each player is to shoot the enemy players, while avoiding taking damage from enemy projectiles. When a player takes too many hits, he is destroyed, and reduced to a spectator until the end of the match.
What are the interesting or unique aspects to your game?
Players can move along any wall of the arena, including the obstacles in the arena. This allows for smaller environments conducive to faster, nerve twitching action. A variaty of powerups that effect both individual players and the world itself for both good and bad will add to the gameplay.
What is the list of features of your game?
Key Features
One vehicle type
Obstacles
One weapon type
One game mode: Free-For-All
Physics - Collision Detection
Graphics - First & Third Person Camera Support
User Input - Gamepad Controller
Network - 4-Player Support
Sound - Global Sound Effects/Music
GUI - Heads Up display
GUI - Main Menu
GUI - Start/Join Game Menu
Additional Desired Features
Powerups
More vehicle types
More weapon types
In-game obstacle generation
More game modes: Timed, Kill Limit, Team Victory, etc
Network - More Players Support
User Input - Configurable Controls
Sound - Localized 3D Sounds
Sound - Configurable Settings
Graphics - Configurable Settings
Graphics - Particle Effects
GUI - Graphic Options Menu
GUI - Sound Options Menu
GUI - Control Options Menu
Super Awesome Cool Dream Features
Even more powerups
Grapple Gun
Melee Weapons
Team Weapons
AI vehicles
More arenas styles
User Input - Force Feedback on controllers
User Input - Keyboard/Mouse control
Graphics - Multithreaded Rendering
GUI - User Manual/Help Menu
Network - Player-to-Player messaging
Group Management
The management of the group will be a group endeavor itself. The major project decisions, such as game design and feature lists, will be made as a group during meetings. Smaller decisions, such as module specific questions, will be handled by the group members assigned to that aspect of the project.
In addition to emails, and twice weekly group meetings, our website will feature private message boards for the group where group members may pose technical or design questions for the other members. Additionally, each member will be responsible for maintaining a blog on our site that will detail his own individual progress.
The site itself will be maintained by our webmasters: Patrick and Tamir. Martin will be responsible for creating weekly group progress reports, also to be featured on the group website.
At every meeting, the team progress will be assessed. Should the project be falling behind schedule, the group will decide how to reassign our tasks in order to accommodate the area of the project in need. It may also be determined at these meetings whether to sacrifice non-key features or simply not meet the planned schedule.
Project Development
Development Roles
Graphics - Jerome, Martin
Network - Patrick, Tamir
Kernel - Patrick, Tamir
GUI - Martin, Jerome
User Input - Tamir
Sound - Jay, Tamir
Physics - Jay, Ardavan
Art - Everyone (Ardavan lead modeler)
Integration - Everyone
Testing - Everyone
Development Tools
.NET Development Stuido 2003/2005
DirectX
FMod
RakNet
Tortise CVS
Fruity Loops
SoundForge
3DS Max
Milkshape 3D
Adobe Photoshop
Testing Procedure
Individual modules will be tested as they are created or modified. The group members assigned to a module are responsible for the debugging and testing of that module. Modules will be integrated one by one, debugging and testing at each level of integration.
Once we have frozen our development, the in-house game testing will commence. All members will participate in testing and adjusting the game. During this alpha testing phase, it will be mandatory for all members of the team to play the game repeatedly. Each group member will of course specialize in testing his aspect of the game, but everyone is expected to contribute to all aspects of testing.
Next we will go into a beta test phase where we will open up the game to a select group of users without proprietary game knowledge. Based on their responses we will further modify the game play and user interfaces. Throughout this phase, group members will continue in-house testing as well.
Documentation
Internal Documentation
Group members are expected to document their code in order to help the rest of the team understand sections of the code to which they do not normally contribute. Additionally, every module team must create a document detailing the interfaces of their module, and its dependencies.
Game Documentation
Minimally, a README file will be included with the launch title that details the controls used by the game, and a navigation map for any menus the launch title includes. An ingame option screen to map buttons will be added if time permits.