Overview:

Game Concept and Goals:

Galaxy Wars is a 3D space combat flight simulator game.  The player controls a spaceship and must destroy the evil AI-controlled teapots that are plotting to destroy to player.  The flow of the game consists of a set of levels that can be designed externally by a game designer and are loaded at the start of the game.  Each level consists of a specification of a number of teapots, their characteristics (max speed, weapon damage, etc) and their starting locations.  Once the level begins the player must destroy all the teapots before the teapots destroy him.  In the current version of the game, it takes two missiles from the user to destroy each teapot, but this can be easily changed or added as a level design feature.  If a player dies they must restart the level.  Once the player dies 3 times, the game is over.  Each teapot is given a point value assigned by the game designer in the level file.  Also points are awarded for the completion of each level and a bonus is given at the end of the game based upon how many lives the player has remaining.  The objective of the game is to achieve the highest score possible.

Game Features:

• 3D Space Simulator  --player can move spaceship around in space and fire missiles (movement includes yaw, roll, and pitch using mouse)
• First person cockpit view with targeting sight
• Game gets harder as it progresses depending on number and characteristics of enemy teapots
• Player can fight against multiple AI-controlled enemies at once
• On-screen indicators for user (health remaining, enemies alive, points scored, current velocity, and lives remaining)
• Sound effects and music

Technical Features:

• Level design and game flow customizable by game designer (through the use of a level design file)
• Game designer can specify certain characteristics about each enemy teapot including maximum velocity, starting position, points that the user receives for destroying the teapot, and damage incurred on the user by missiles shot by that teapot

• Computer controlled opponents use AI to determine destination location to go to and to determine when to fire missiles
• Quaternions are used to represent rotation (both for player and enemy spacecraft)
• Space skybox used to give impression of infinite space
• Sound
• Lit Environment
• When teapots are destroyed, they explode by generating a bunch of randomly sized polygons that break out in random directions at a random speed
• Randomly generated points in 3D space that look like stars are used to give the player an impression of movement (these points are culled based on the viewing frustum so that even when the player moves out of the main area, the points are still generated
• Collision detection between all objects in the game so that spaceships can not move through each other and it is obvious when missiles hit ships

User Controls:

• Player controls yaw and pitch of spaceship by moving mouse around (pitch is inverted so moving the mouse forward causes the ship to turn downwards)
• When right mouse button is held down, left/right movements of the mouse cause the ship to roll instead of yaw
• Acceleration is controlled by holding down spacebar
• Missiles fired by clicking left mouse button

Level Format:

Below is a short sample level file along with comments to explain how to design these files.  The number of levels a game designer can program in is unlimited as long as the format below is adhered to.

Development Summary:

Code:

These classes represent original code written by the game developer:

• Camera – Controls the camera
• Game – High level control for flow of game (initialization of classes, etc.)
• Input – Manages the user inputs (mouse button, keyboard presses, etc)
• Sound – Manages the sound effects and music used in the game
• Skybox – Creates and renders the skybox
• TextureMap – Manages all textures
• World – Keeps track of the state of the world (spaceship and missile locations, etc)
  • Spaceship – Represents any type of spaceship
    • PlayerShip – Inherits from Spaceship and is used to represent the ship controlled by the player
    • EnemyShip – Inherits from Spaceship and is used to represent the AI-controlled teapots (main AI algorithms are contained within this class)
  • Explosion – Models the explosion animation for enemy ships
  • Missiles – Keeps track of the location and rendering for all missiles currently active in the game
  • Spacejunk – Generates a bunch of random points in the current viewing frustum and generates them so that when the user moved, it is obvious that they are actually moving

The following external libraries were also used in the development of the code:

• Math3d - The 3D Computer Graphics Math Library (available at http://www.sourceforge.net)
  • Used for representing 3D math operations (vectors, quaternions, matrices, etc.)
• FMOD Sound Library
  • Used for playing sound and music

Content:

All content in the game (other than the level files) was borrowed from external sources.  This content includes:

• Space skybox textures from Asteroids game (available at http://www.sourceforge.net)
• Sound effects from Asteroids game
• Cockpit and target scope textures from Asteroids game

Key Technical Challenges:

Artificial Intelligence:

The most difficult technical challenge for Galaxy Wars was creating the AI for the enemy spaceships.  To actually implement this, I first came up with a simple path-finding algorithm where each enemy ship would select a target destination based on the location of the player and would adjust its pitch and yaw to go to this position.  Once I had this working properly, there were a lot of issues that required tweaking and this turned out to be the most difficult thing to implement.  For example, the enemy ships must be able to determine when they should fire at the player and they must change directions when they are about to run into the player.  Creating the code to do this required changing small things one at a time and refining them until the ships’ behavior seemed reasonable.

Rotation Modeling:

To represent rotations in 3D space, I decided to use quaternions because of the many advantages they provide over other methods of representation.  However, translating the user’s input into rotations that look smooth using quaternions turned out to be somewhat challenging.  However, after many attempts and testing, I was able to produce a modeling for the rotation that appears smooth and realistic.

Collision Detection:

Detecting collisions between two objects in 3D space is always a challenging task.  To implement this, I decided to create a bounding volume struct for each object.  Once this struct had been created, my collision detection algorithm could take to bounding volumes and determine whether or not the two intersect.  One thing that made this problem even more difficult was that the objects can move a good bit (especially for the missiles) between each update pass.  Therefore it was also necessary to check out if the two paths of the objects (from their locations on the last path) intersected.

Post Mortem:

Things that went right:

• The final product actually implements the majority of the important features listed in the original project proposal.
• A playable version of the game was produced early which allowed for early game testing and tweaking of playability.
• The AI, which was by far the biggest risk associated with the original proposal works fairly well (i.e. the enemies appear to behave somewhat intelligently and the game is challenging for the player

Things that went wrong:

• Several of the smaller features proposed in the original proposal were left out due to time constraints.  For example, the radar display was not implemented.  Also, the original plan was for the spaceship shapes to be more diverse and interesting than teapots. The code necessary to load models into the program was actually written and working, but I did not have time to go out and find the right models and integrate them into the game.
• There are some flaws in the AI.  For example, if the player stops moving, the enemy ships get real close and start rotating to face the player, but this rotation is not as intelligent as it could be.
• Because of the many other projects and exams I had at the end of the semester, I was not able to devote as much time to the development of the game over the final two weeks of the semester that I would have liked to.  As a consequence of this, the game is perhaps not as refined as it could be.

Lessons Learned: 

In general, I am pleased with the way this project went.  However, if I could change anything I would have budgeted my time a little better so that I could have actually implemented all the features listed in the original proposal and spent more time at the end taking care of a lot of the small issues to improve the overall gameplay of the game.