Final Project Report:

Game Goals:
To create a 3d multiplayer artillery game that allows players to shoot each other inside a futuristic battlefield using a morphable weapon system.

Requirements List:

• Importing 3D Models: Accomplished. .3DS max files used for both landscape and player objects
• 3D Viewing and Transformations: Accomplished. Complex camera control of both first and third person styles which chases player objects around.
• User Interaction: Accomplished. Direct Input was used to allow user input via the keyboard and mouse (including scroll wheel).
  
• Lighting and texture mapping: Accomplished. OGL lighting effects, plus Cg per pixel and toon shading. Textures utilize multiple file types and can be transparent.
• Hierarchical Scene Graph: Not Accomplished. Unfortunatly, we could not get the quadtree completed in time for the project report. A preliminary structure exists, and future versions will have this feature.
• Sound: Sound effects courtesy FMod. capability to use 3D effects, streaming or whole sample loading. Can play .mp3 or .wav.
• Collision Detection / Response: Player to player collision, player to terrain collision, bullet to terrain collision, all in. Use of sphere to sphere and ray to triangle collision for "fast" moving objects.

Extra Features:

• Shaders: Custom made Toon Shading and regular per pixel lighting effects.
• Special Rendering Effects: Colored fog, and a particle engine provide addtional "environmental" rendering effects. The fog improves the clipping of the viewing frustrum to the landscape and the particle engine is used to give the player a visual cue as to the size of an explosion.
• Physical Simulations: All major objects in the game are affected by a custom built physics engine which provides sophisticated acceleration, velocity, and gravity effects.
• On Screen Control Panel: A dedicated and sophisticated gui utilizing direct input, buffered input, and state machines to accomplish proffesional style user interactions.
• Networking: A working multiuser game using the Rakkarsoft multiplayer API. Players can join or leave existing games, and rejoin. Upon rejoining, players will look for empty slots before adding themselves to the end of the list.

Member Responsibilites:

Shawn Pearson - Illuminus (Lead)
-website updates, reports
-core functionality
-networking
-sound
-camera input

Jason Powers - Groller (File and Scene Management)
-model loading
-scene graph management
-particle engine

Jeff Robinson - Decompile (Physical Simulations)
-physics
-collisions

Fernando - Kam (Graphical Representation)
-GUI
-Cg
-lighting
-fog

Main Technical Issues:

The number one issue was the failure to get a quad or octree into the project as originaly planned. This had a huge effect on the direction and pace of the game. Unfortunatly, we were forced to make a large number of concesions regarding the sophistication.

Much of the collision and physic code is under developed due to the fact that it was nearly impossible to impliment until a tree was made first. Because the tree was delayed, the collision was delayed.


Lessons Learned:

The blog was instrumental in keeping organized and documented. It was a conventient place to communicate between group members and post latest news and updates.

The CVS would sometimes corrupt non .cpp or .h files. So occaisionaly a model or texture would no longer load, or even inexplicitly crash the program. Back up, back up, back up!

We had a good start with a pretty good core engine and starting the networking code early enough, however, the one major component that wasnt almost completly fleshed out from the start was the octree. The octree was absolutly critical to our implimentation and the failure to get it completed right from the beginning slowly but surely crippled our project.

While we managed to come up with an alternative solution, the final decision to drop the tree came too late and we had precious little time to complete the fixes.

Week 6: Progress Report

The last full week of development before the final presentation was a hectic one. Of major concern was the lack of a quadtree, nor ANY method of parsing the geometry of the level for quick collision detection or frustrum culling. The decision was finaly made to skip this for now so we can get the rest of the required work in by next Wed. This is a painful decision to make but it could not be avoided as the person in charge simply could not figure it out.

Attempts to help him get it in by project time uncovered even more errors and shortcomings in the tree code which spelled doom for any further attempts. After the class, the plan is to completly remove and reimpeliment the quadtree.

In the meantime, we spent the week attempting to handle some of the tricky physics and collision with and without the tree code.

Things we accomplished:

• Kam worked with Groller on the quad-tree code. He added title / credits screen. He also began work on a particle engine.
• Decompile changed the physics code to comply with a no tree situation and began work on bullet code.
• Illuminus altered the tank model so that it would load correctly with our model loader. Added the code which correctly orientes the tank on turning.

Things we did not accomplish:

• As mentioned before, the tree code has been thrown out.
• Collision and Physic code as relating to the tertrain is still lagging behind, but will hopefuly catch up in time for the project presentation.