Game Idea

Star Control Gold is a 3D rendered, 2D space shooter in the style of the vintage Space War, and Star Control's Hypermelee. Our game will support this type of game play as well as (hopefully) other game modes such as a Soccer version where the ships would try to capture and bring a ball to the opposing team's goal while the other team would try to shoot the ball carrier to make that ship lose possession of the ball.

We chose this type of game because of the nostalgia factor, it has an easy to grasp overview of the playing field, and simplified collision physics. The 3D rendering ability allows for advanced graphics and eye candy so that it doesn't have the visual drawbacks most 2D games run into. The game play allows for a great variety of variations; for instance 'Soccer', 'Maze', 'Asteroids', 'Tag', 'Sumo'. The only real limitations are time and imagination.

The goals for gameplay, in order of priority, are:

- Battle Mode
- Free for All - Be the last ship flying
- Team Mode - Kill the other team, preferably not your own
- Soccer Mode
- Score the most goals

The core features of the game are:

Input: Mouse and Keyboard
Game play: Basic ship physics, Bullet physics, Collisions, and Game State Changes (Start/End detection)
Graphics: Render the ships and weapons
Networking: Client / Server Model
Sound: Basic "Play Sound Now" for one shot playback
Other: 3D Ship Models, Ammunitions Models

Some lesser features are:

Input: Gamepad and Joystick
Game play: More advanced physics models, Alternate Game Modes
Graphics: Addition of playing field eye-candy and particle engine
Networking: Efficient and accurate version of Client / Server
Sound: Basic background music, and 3D sound effects

The least important features are:

Game play: Yet more game play modes, robust and clean GUIs
Graphics: Even more playing field eye-candy, Shader effects
Sound: Game interactive music effects

Group Management

Member Roles

These are our initial roles in the group. As we complete components of the engine (i.e. sound, input, and networking will take less than three weeks), certain members of the group will begin work on general gameplay, and/or freelance. Each lead will be responsible for making sure that their component is on track and will report their component's progress to the group. If their component is slipping off of schedule they are responsible to make sure the group knows so we can adjust our time accordingly to accommodate.

Group Contact: Rock Yuen
Game play: Piotr Dollar
Graphics: Rock and Anson
Networking: James and Marshall
Sound: Brian Ellis
Input: James

The Decisions

When possible by consensus, but if the component leader feels that too much time is being wasted on the decision they will step in and decide. Generally, the group will operate pretty democratically; everyone should feel comfortable voicing suggestions and objections. Since the different components of the engine and the game will vary greatly in complexity, our roles will be rather fluid; as one person completely a portion of the game, he'll be free to help others on other components.

Group Communication

Communication will mainly be done though email as its asynchronous nature allows for ease of accessing. In support of this, we all have instant messenger access to each other for more responsive communication and are going to try and find stable time to work together in the lab so as to keep each other appraised of the project status as well as to offer our support and expertise in regards to questions that may arise while programming.

The Schedule

Schedule maintenance will be performed in combination with the weekly status reports. We will be keeping an expected timeline that each module of the game will follow, as well as one for the game as a whole. The status reports should include mention of the expected status of the component the person is working on plus a general impression of how the project is proceeding. If a component is slipping behind, we will evaluate if the slip is acceptable within the goals of the project. If so, the schedule will be updated to reflect this delay. If not, we will divert manpower to that component as necessary. Ideally those familiar with the component in question will be diverted so as to minimize and learning curve necessary to help with that component.

The Status Reports

Weekly Status Reports will be produced by each group member about his area of work for that week. Updates will be posted on the website.

Project Development

The Roles

See above for specific role assignments

The Tools

CVS, code backup and synchronization
MS VC++ 7.0
XP, DirectX9.0 - Stable test bed, all computers are the same, will be developing from other computers than just the lab, but the code must always work on the lab computers.

The Testing

Besides the test and check when developing, scheduled whole component and whole project level tests will occur with the group present so we know where we stand besides just a place on a timeline. Lots more game play testing (IE playing the game for fun in the lab) as the quarter ends and we hopefully start on the fine grain features.

The Documentation

User end documentation will be produced towards the end of the quarter, both to promote a focus on the programming at the beginning as well as to allow for us to learn how many optional game play modes we can realistically add to the game.

Code documentation will take the form of detailed .h file information, so all that is needed to use a module is very clear from reading just the .h file. We may also maintain a documentation webpage, with short tutorials on class definitions. The actually implementation will make use of Hungarian Notation for consistency in variable naming, function header comments reiterating and potentially expanding on the material put forth in the .h file, and whatever inline comments the author deems necessary. For modules with more people working on them, the inline and header comments will be focused upon as they are more likely to be used; whereas the modules with few people should focus on their .h file comments as the code comments will likely be for the author's benefit only.

Initial Project Schedule

High Level Milestones:

Week 2: CVS up and running, all members familiar with working copy and procedures to integrate code.
Week 4-5: Initial integration - networking completed and working
Week 7: Freeze on new game play modules
Week 8: Freeze on new project features
Week 9: Mass Debugging

Low Level Milestones:

Input (James):

Wrapper class for DirectInput already written. If the networking goes smoothly, I'll add joystick, and possibly action mapping support. Otherwise, we'll stick with keyboard ship control and fixed key bindings.
My input class supports input capture and replay; if we have time, I'd like to find a use for this (instant replays after goals, maybe a score board under the court that displays replays).

Gameplay:

Some gameplay features were discussed above. Basic SpaceWars-style gameplay a must. Most physics code already in place; need to test and debug the 2d concave polygon collision detection algorithm.

Once our modules are defined and stubbed, we'll be able to better solidify our gameplay feature list. Initially, we need to define the primary classes and how they will communicate with each other.

Graphics:

Basic mesh functionality already written. Progressive mesh support written. Other goals include:
- rendering ships, asteroids
- particle system
- misc effects
- user interface, font drawing

Networking:

DirectPlay: implement simple client/server model without lobby ('host' or 'join', entering IP addresses). If we have time to burn 6-7th week, we'd like to write a dedicated lobby/list server. Initial tasks are to design the packet formats, and decide how the networking module will be plugged into the framework.

Sound:

Week 2: DirectSound Class Defined (Documented, Stubs, Etc)
Week 3: Simple DS Functionality Working + DirectMusic Class Defined
Week 4: Integration of Sound Modules with Game Engine
Week 5: 3D DirectSound Functionality
Week 6: Simple DM Functionality (Static Music Playback)
Week 7: Interactive DM Functionality (Subject to Music Creation)
Week 8: Debugging
Week 9: Debugging
Week 10: Debugging