Week 0: Progress Report

This week we had our initial game presentation for the rest of the class. We focused on describing the feel for the type of game we are hoping to make, as well as the technical specifications that we have already laid out.

Things We Accomplished:

• It was decided that we WILL be using our own CVS repository, as well as periodic backups onto the class CVS machine. We spent a large portion of the team meeting discussing how CVS works, and how to back up work on our personel machines.
• Kam has rough sketches of the GUI and actual vectored art for several of the "readouts". As soon as he works out a good transparency file format and input, we should have them added to the gui class.
• Groller is still working on getting static 3ds models to import WITH textures. After that, his next step will be to get some form of animation sequences for them into a class structure.
• Illuminus has been working on getting the Rakkarsoft networking code intergrated, with advancements made after stamping out an ugly bug involving global #defines. The DNO code is now included and objects are being instantiated without compile errors.
• Decompile is researching good physics engine implimentations, and has begun work on the simple collison tests: sphere to sphere.
• Our 3D artist has already begun work on initial tank design, and as soon as he has something to show it will go into the screen shot archive. Early reports point to some kick ass designs taking shape!
  

Things We did Not accomplish:

• We have not yet intergrated our code due to not having a CVS repository setup, and getting all members comfortable with the process. We should have a unified code set on the server by this weekend however.
• All other goals have been met for this week. The project is still technicaly in the design phase, but should move into full scale implimentation by next week, which is ahead of scedhual.
  

Initial Concept: Technical Specs

The program will be broken down into the core engine and series of major systems. In addition there will be some helper functions such as a vector class, math libraries, helper functions, etc.

Below is a list of what each system must have in order to produce a functioning game. At the end of the list is a ranking of additonal fucntionalities we would like added if time allows.

Must Haves:

Core Engine

• runs base window and OGL handleing code
• game loop

Camera System

• 3rd and 1st person views, multiple cameras
  
• arcball rotaion and keyboard input, follow object support
  

Model Loading System

• loaded model terrain
• loaded animated player models
• textured, colored, 3ds

GUI System

• text output, graphic overlays, mini map

Particle System

• explosions, smoke, vapor trails
• hardware facers, or some other 'quick' method

Collision System

• handles player to terrain, player to player,bullet to player, bullet to terrain collisions
• sphere to sphere, sphere to triangle, point near triangle tests

Physics System

• handles player, bullet, terrain interactions
• velocity, acceleration, wind, bounce

Quadtree/Octree System

• static terrain, but effecient object referencing
• holds display lists of triangles for drawing
• used for collision detection as well

Input System

• Direct input
• keyboard, mouse, scroll wheel
• key mapping from text file
  

Sound System

• Aopen API
• 3D sounds
• music
  

Multiplayer System

• Rakkarsoft API
• track each player info, bullet info, game stats
• some interpolation, client/server approach
  

Extra (would be nice):

1. Cel shading or light maps
2. Nice connection interface, menues, etc
3. Chat
4. Large (8+) multiplayer support
5. CG particle system
6. Alterable tank specs (speed, mass, size, hit points, etc)
7. Very precise physics (friction, mass, momentum, 'spin', etc)