Super Sternkampher Assault

Technical Design Document Team Con Limon

Dan Panuska Joe Kimmes Anthony DiJulio Kevin Drew Corey Fellows Copyright DigiPen Institute of Technology GAM400 Moore

Table of Contents
Executive Summary Introduction Schedule Overview Technical Cost Overview Techincal Cost Technical Overview Target Platform Version Control External Code Game Engine GameManager Game Flow Control Weapon Specific Code Graphics Graphics GraphMesh GraphObject GraphModel Camera Particle System Physics Overview Collision Movement C++ Structures 21 21 22 23 14 15 16 17 18 19 7 10 11 6 6 6 4 4 5 5

Artificial Intelligence Overview Artificial Intelligence Class Enemy Struct Squad Class Boss Struct Smaller Structures Behavior Functions Files Level Editor Overview Visual Interface Functions Data Format Sound Overview SoundManager Appendix A Appendix B 32 32 33 34 29 29 29 31 24 24 25 26 26 27 27 28

Executive Summary
Introduction Super Sternkampher is a 3-D rail shooter, which employs unique camera changes throughout the game-play. The camera will change from different views depending on the level design. Views supported are Top-Down, Side, and Behind the Ship views. The player will be able to use different weapons to dispatch of their enemies. Ranging from a beginning Beam Gun, you collect new weapons and upgrades to old ones. Enemies will use simplistic pattern/movement AI, the boss battles however will be very intricate. These AI will have many more attacks and patterns to go through with unique movement not given to the other fodder fought throughout the level.

Technical Cost Overview Resources: Producer Kevin Drew Technical Director Anthony DiJulio Designer Joe Kimmes Product Manager Corey Fellows Lead Tester Dan Panuska Total Salary Computer Costs: Five PC Computers, $1200/ea. 3D Studio Max Total Computer Costs Total Cost: $414,500 Monthly Burn Rate Salary Computers Expenses

$70,000 $70,000 $70,000 $65,000 $65,000 $405,000 $6,000 $3,500 $9,500

$50,625 $1,438 $4,000

Total Monthly Cost

$54,063

Technical Overview
Target Platform Overview Super SternKampher will be released on the Windows NT platform. It will come out on CD-ROM. The minimum requirements should be a 1 gHz Pentium III or Athlon equivalent, 256 MB of RAM, 64 MB video card, and 150 MB of disk space.
Version Control

We will be utilizing TortoiseSVN to keep our individual versions updated of global changes. This should also help to keep the integrity of the functional code already embedded into the project. Our program is going to utilize multiple libraries and applications already in creation during our production process. Microsoft Windows 2000/XP Since these are our target platforms, various versions of Windows XP and Windows 2000 will be used for code development and testing. Microsoft Visual Studio .NET 2003 (v 7.1) We will be using MS Visual Studio .NET as our development workplace and debugging environment. Discrete 3D Studio Max 6.0 We will be using 3DS Max to create our 3D level files and we will be importing these files using an importer written by us. TortoiseSVN We will use TortoiseSVN as a method to keep our program in sync across programmers and avoid integration issues, as previously mentioned. DirectX 9.0 We will be utilizing DirectX libraries for our graphics engine, using this to display images to the screen. DirectInput DirectInput libraries will be our way of gathering joypad/keyboard input from the user and relaying messages to the application. FMOD We will be using FMOD for our audio engine, playing background music and sound effects.
External Code

Game Engine
GameManager Purpose: The GameManager controls all game related data. This includes all the objects in the game, levels, input, graphics, state transitions, sound, and user interface features. Functions: Update: Changes current game state to reflect the passage of time based upon input. Updates all the locations of objects, removing objects and added them as needed. Render: Displays the current scene. Object Purpose: Object will be a generalized class that all other drawable game object will derive from. Children: Interface Player Enemy Projectile LevelObstacle Level Power-Up Camera Scrap Boss Functions: Update: Changes the object appropriately to what the objects purpose in the game is. Either applying its AI, weapon behavior, or movement due to input. Render: Displays the object Kill: Removes object from the game. Certain objects will have behavior that happens on its death

Interface (Object) Purpose: Used for user menu interface and in-game head up display. Functions: Update: Applies the functionality of the button. Player (Object) Purpose: Stores all data relevant to the operation of the player object; locations, direction, speeds, health, points, lives, current weapon configuration. Functions: Check Collision: Determines is the player object is colliding with a power-up, projectile or LevelObstacle and handles the collision appropriately. Update: Applies movement to the object by taking into account player input, level contour and current game state. Enemy (Object) Purpose: Stores information about the enemies in the world; location, direction, type etc. Function: Check Collision: Determines if the enemies are colliding with the player or players projectile object and handles that collision. Update: Runs a enemy behavior depending on the current game state and perspective. Projectile (Object) Purpose: Stores information about the type, location, direction and list of targets of each projectile (if the types are appropriate). These projectiles will be stored in the GameManager as 2 separate lists, one for the players and one for the enemies. This will simplify the search for collisions. Update: Runs the update behavior depending on the specific type of the projectile. LevelObstacle (Object) Purpose: Stores information about the location and shape of the various obstacles the player will encounter in the level.

Level (Object) Purpose: Stores information about the contour of the level, location of the level obstacles, enemy spawn points, and transition points. Update: Determine if enemies need to be spawned of if transitions need to be started. Power-Up Purpose: Stores the type of power up, location, etc. Update: Changes position slightly depending on the perspective. Camera Purpose: Provides the direction and location of the players eye, so it is not as much a draw-able object as a conceptual one. It typically will be following the player at a set location relative to the player object; however will also need to automatically adjust its location during the transition states to prepare for the new perspective. This transition will take a specific amount of time to complete. Update: Moves the camera to keep on pace with the players ship, and transitions the camera. What it exactly does is dependant entirely on the current games state. Scrap Purpose: Scrap objects have no purpose in game-play, but provide a visual effect when another object is destroyed. Update: Simply apply gravity to the object and kill it after a fixed amount of time. Input Purpose: Poll input devices and keep the current state of buttons pressed. Functions: Update: Changes internal data to reflect current key press configuration. GetKey: Returns all information about the key. This information includes if the key is currently being pressed, not being pressed, was released between last input and now, was depressed between last input and now, duration of depression.

Game Flow Control: Main game states include the following: Menu: Player is currently browsing the menus prior to the game beginning, adjusting settings or otherwise. In Game: The in game state will have 4 different sub states. Objects will behave differently depending on these states. Rail Top Down Side Transition The transition state will need additional information. The goal for this state is to provide a seamless transition between any other game play state. It will need to know what state it started in and where it needs to finish. It also needs to know the duration of the transition and any information about dialog to be played. Post Game: Game is over by means of either victory or defeat. Players will be presented with an appropriate screen and asked to enter their name for high score. Main Game-play loop Check level for new events (enemy spawning, transitions) Check collision between all game objects Remove unused/destroyed objects Update all game objects Render scene

10

Weapon Specific Code Projectiles will all inherit from the following base class class Projectile { // Abstract Functions Types void Update(void); void CheckCollision(ENEMY); void Render(void); };

// Updates the positions of each projectile // collision between this and the enemies.

This way each different type of projectile can have its own different behavior, internal data representation and means of checking collisions with the enemies, but the game engine itself will not have to worry about what the specific type of projectile it is.

Beam: Beam Gun (Rank 1) The beam gun consists of a position in space and a direction. As long as the button is depressed, every 1/3rd of a seconds it will fire a shot directly towards the target. Collision will be tested over the begin location and the projected end location of the weapon. Beam Gatling (Rank 2) This weapon is identical to the regular beam gun, but shoots faster. Every 1/10th of a second it will shoot a beam towards the target, but this time with up to a 5 degree variance from the target destination. Hyper Beam Gatling (Rank 3) Again, similar to the base weapon, but shoots every 1/20th of a second and has a 10 degree variance

11

Beam Cannon Beam Rifle (Rank 1) One second after the fire button is triggered it will fire a beam represented by a line originated from the players ship and moving towards the target. The beam will follow the ship and will continue to do damage to anything that the line intersects until it dissipates after a few moments. Beam Cannon (Rank 2) Same as above, longer charge, longer dissipation time, more damage, and wider. Shotgun Charged Laser (Rank 3) Same again, everything is increased again. Spread Shot Spread Shot (Rank 1) Fires 3 shots in a narrow spread towards the target. These projectiles are similar to the Beam Gun in regard to the collision and movement. Spread Shotgun (Rank 2) Fires 5 shots in a slightly larger cone towards the target. Spreading Spread Shot (Rank 3) Weapon operates in the same manner as the Spread Shotgun, but whenever an enemy is destroyed by the shot it creates another instance of the spread shot starting at the location of impact. This wave continues if the new shots hit destroy other enemies. Missile Launcher Missile Launcher (Rank 1) Fires a slow moving rocket towards the target. On collision it creates a explosion that deals damage to enemies in the area of effect. Homing Missile Launcher (Rank 2) Selects the nearest enemy inside of a cone from the players ship to the target area. The missile will then turn itself to collide with the target. It will then explode and deal damage to all nearby enemies. Homing Missile Storm (Rank 3) Fires a series of homing missiles each selecting a different target and seeking them down.

12

Rail Gun Railgun (Rank 1) Fires a line from the player to the target area. Deals damage to all enemies that intersect with this line when it is initially created. After this point it does no more damage, but the visual effect will remain on the screen for a few moments. If the enemy is not destroyed outright it will knock them back a small distance Linear Launcher (Rank 2) Deals more damage than the regular rail gun. Rail Gatling (Rank 3) Requires a small charge period before firing 5 Linear Launcher shots in rapid succession. Flame Thrower Flame Launcher (Rank 1) While the fire button is depressed it will fire a few slow moving projectiles towards the target area. Enough are fired so that they can spread out gradually until they dissipate. Spiral Flame Launcher (Rank 2) Same as the flame launcher, but instead of shooting directly forward the target area rotates around the ship creating a shield effect that will deal damage to everything that enters the general area of the ship. Radiating Sword (Rank 3) The flame thrower will fire a more rigid stream of flame and will intelligent manner that attempts to slice through the enemies as they approach. Also will deflect shots as they approach.

13

Graphics
Overview The Graphics class will indirectly contain all graphical information used in the game. This class will look something like the following.
class Graphics { public: Graphics(); ~Graphics(); Display(); std::vector<SubDivision> private: std::vector<ParticleSystem> std::vector<GraphMesh > std::vector<GraphModel> }; Particles Meshes; MapObjects; Area;

Area A list of pre-calculated areas made by dividing the level into sub-regions. This division will be calculated in the level editor and loaded at the start of a level. SubDivision represents a class which contains a list of GraphModels which represent map objects within the game, and information used to determine whether a point in 3D space is contained within the sub-region. It will also contain a pointer to the next SubDivision for easy reference. Particles This is a list of ParticleSystems to be used for general purpose within the game. Environmental particle effects for example would be kept within this general purpose list rather than being linked to an object. Meshes This is THE list of meshes used within the game. Every GraphObject will point to a mesh contained within this list. This will eliminate the need to load a single mesh multiple times. MapObjects This contains the model information for all of the map objects (terrain, obstacles, etc) within the current level. Each member of the Area list of SubDivisions will point to this list of objects in a similar fashion as each GraphObject points to a GraphMesh within the Meshes member. The Graphics class will control the rendering of the scene to be currently displayed. While this process will surely contain a much more intricate structure to display objects, it has been simplified to a single Display() function for sake of brevity.

GraphMesh The GraphMesh class will contain all information relevant to display a Direct3D mesh. The class will look something like this:

14

class GraphMesh { public: GraphMesh(); ID3DXMesh* std::vector<D3DMATERIAL9> std::vector<IDirect3DTexture9*> std::string BoundingSphere }; Mesh; Materials; Textures; Name; Sphere;

Mesh A pointer to a Direct3D mesh Materials A list of materials needed to display the mesh (diffuse reflection, ambient reflection, specular reflection, color emission, and sharpness of specular highlights). Textures A list of textures used to texture map the mesh. Name The name of the mesh (stored as the name of the file the mesh was loaded from). Sphere The bounding sphere information of the mesh (Note that the center of the sphere is the center of the object to which the mesh belongs, and the radius of the sphere must be scaled by the scaling factor of the object).

15

GraphObject The GraphObject class will contain all of the graphical information of an object needed in the game and will look something like this:
class GraphObject { public: GraphObject(); bool LoadFromXFile(char *filename); void SetOrientation(float axis_x, float axis_y,float axis_z, float rotationAngle); void Turn(float axis_x, float axis_y, float axis_z, float rotation); void SetPosition(float x, float y, float z); void Move(float x, float y, float z); void SetLook(D3DXVECTOR3& lX, D3DXVECTOR3& lY, D3DXVECTOR3& lZ ); GraphMesh std::vector<ParticleSystem*> bool D3DXVECTOR3 D3DXVECTOR3 D3DXVECTOR3 D3DXVECTOR3 }; *MeshInfo; PSystems Free; LocalX; LocalY; LocalZ; Position;

MeshInfo A pointer to a GraphMesh object indicating the mesh to be displayed for the object. PSystems A list of particle systems that belong to the object. This will allow for particle systems to be easily associated with an objects position and orientation (see the ParticleSystem class for further detail on particle systems). Free This bool is used to indicate whether the object is free from is parent model. If this is the case, the objects translation information must be taking into consideration when displaying the object. If not, the object will just use the translation information provided by the model. All other members represent the orientation and position of the object in space with respect to the orientation and position of the model the to which the object belongs (see GraphModel for further detail). This information will be stored in calculated transformation matricies to allow for display of the mesh associated with the object within its proper location. Each GraphObject can be oriented and moved freely with the provided functions.

16

GraphModel The GraphModel class is a step up from the GraphObject class. This class will contain a list of GraphObjects that represent an entire model in the game. This allows for bosses with multiple sections, and enemy models that can blow apart into fragments of their complete model.
class GraphModel { public: GraphModel(); bool GetWorldMatrix(D3DXMATRIX *world); void SetOrientation(float axis_x, float axis_y,float axis_z, float rotationAngle); void SetScale(float Scale); void Turn(float axis_x, float axis_y,float axis_z, float rotation); void SetPosition(float x, float y, float z); void Move(float x, float y, float z); void SetLook(D3DXVECTOR3& lX, D3DXVECTOR3& lY, D3DXVECTOR3& lZ ); std::vector<GraphObject> Objects; D3DXVECTOR3 D3DXVECTOR3 D3DXVECTOR3 D3DXVECTOR3 D3DXMATRIX D3DXMATRIX D3DXMATRIX D3DXMATRIX D3DXVECTOR3 D3DXVECTOR3 D3DXVECTOR3 }; LocalX; LocalY; LocalZ; Position; Rotation; Translation; Scale; ObjWorld; WorldX; WorldY; WorldZ;

Objects A list of GraphObjects that make up the model. All other data members represent the translation information of the model and all of the objects contained within the model. The objects within the model will use this translation information as their own, unless otherwise specified in which case they will translate themselves with respect to the position and orientation of the model.

17

Camera The camera class will keep track of the position, orientation, and type of view currently being used.
class Camera { public: enum CameraType {TOPDOWN, SIDE, RAIL, TARGET}; Camera(); Camera(CameraType cameraType); ~Camera(); void TransitionMove(cameraType type1, cameraType type2); void GetPosition(D3DXVECTOR3& pos); void SetPosition(D3DXVECTOR3& pos); void SetOrientation(D3DXVECTOR3& up, D3DXVECTOR3& right, D3DXVECTOR3& look); private: CameraType CamType; D3DXVECTOR3 Right; D3DXVECTOR3 Up; D3DXVECTOR3 Look; D3DXVECTOR3 Position; };

As previously stated, the camera class will keep track of its position, orientation and camera type. The camera type is used to determine how the camera should be moving in relation to the track that the character is moving along. The three main camera types being top down, side view, and rail view. Transition functions will also be present to allow for smooth camera transitions between the various camera types.

Textures: Textures will be loaded by use of the DirectX library and may be of any common format, most likely BMP. Textures containing an alpha channel will be in DirectX DDS format.

18

ParticleSystem The particle system will be an intricate part of the graphics engine. A general particle class will be implemented to allow for easy derivation for construction of multiple particle systems with various graphical effects. The general class will look something like this:
class ParticleSystem { public: ParticleSystem (); virtual ~ ParticleSystem (); virtual bool Init(char* texture); virtual void Reset(); virtual void ResetParticle(Attribute* attribute) = 0; virtual void AddParticle(); virtual void Update(float time) = 0; virtual void Render(); protected: D3DXVECTOR3 float float IDirect3DTexture9* IDirect3DVertexBuffer9* std::list<Attribute> int DWORD DWORD DWORD }; Origin; Rate; Size Tex; VB; Particles; MaxParticles; VBSize; VBOffset VBBatchSize;

An Attribute represents all of the properties of a single particle (color, velocity, position, age, life time, etc.). The particle engine will use dynamic vertex buffers to store point sprites. Particles will be displayed in batches to allow for optimum use of the graphics card. All particle systems will be rendered consecutively to prevent multiple render state switches. All functions within the class are virtual functions. This means that each particle system derived from the base class will define their own functions to dictate the behavior of the particles contained within the system.

19

Area Sub-Division All map objects will be sorted into sub regions of the entire level. This will precalculated when saving files from the level editor. The objects contained within a given area will be computed by checking the angle and distance from an object as you move along the track. Each sub region will keep its own list of pointers to GraphModels contained within the main Graphics class. Only one to two of these sub-regions will be processed at any given time (determined by the location of the player). Conventions All enemy units will be displayed, because they will only exist when the ship is near them. Each Actor in the game will contain a pointer to a GraphModel with the Actors proper graphics information. While the graphics class is in charge of keeping the list of meshes, and map objects, each actor will have its own model information. Any Object with alpha values (transparency) will be contained in its own list of Objects and sorted by depth value, this will minimize the changing of render states and more importantly prevent graphical errors. All meshes will be in DirectX .X file format. A progressive mesh will be made of all loaded meshes to allow for decreasing level of detail (LOD) as the object moves farther from the camera position.

20

Physics
Overview: The physics system for SSKA handles the movement and collisions of the units or Actors in the game. There are essentially four types of actors that will be seen in the physics system; Units such as the SternKampher and minor enemies, Obstacles (the terrain in the levels), Projectiles and Bosses. During a loop of the game, a physics handler will be called to update the physics data of all the actors in the level. Collision The physics engine uses two types of collision modeling. First, for Units and Projectiles, spheres will be used to approximate the models collision. When the collision spheres of two actors overlap, they will be pushed back to a nonoverlapping state and their velocities/data adjusted for the collision.

Second, for the large objects like Obstacles and Bosses, there will be a collision sphere encompassing the entire actor to act as an initial test; if another actor is inside this, however, a more rigorous check of the units polygons is made to allow for oddly shaped Obstacles and Bosses. When a collision occurs, the physics engine will adjust the position of the colliding actors so that they are no longer colliding and will modify their physics variables to model the collision (described later). Note: Projectiles do not check for collision with other projectiles. Similarly, enemy projectiles do not check collision with enemies unless specifically noted, and the players projectiles do not check collision with the SternKampher.

21

Movement All actors will track their mass, velocity and acceleration to allow for a fully force-based physics system on collision, the appropriate physics calculations will be performed to determine the results of the collision. Additionally, units will move themselves by applying forces to themselves in the form of their thrusters. Due to the simple nature of the game, rotational motion due to collision/forces applied will not be accounted for; however, the physics engine will support the rotation of models for special effects like the SternKamphers Rolling Dash.

22

C++ Structures Physics - The generic physics object. All game objects will contain this object. .type enum denoting the type of object (Unit, Obstacle, Projectile, Boss) .collision contains units collision data (varying according to unit type) .velocity contains units velocity data .position contains units position data .accel contains units acceleration data Collision contains a units collision data .spherecount Number of spheres used in the units collision modelling .spheres pointer to an array of Spheres used in the units collision modeling .polycount Number of Polygons used in the units collision modelling .polys pointer to an array of Polygons used in the units collision modeling Velocity .x Velocity along the X axis .y - Velocity along the Y axis .z - Velocity along the Z axis Position .x Position on the X axis .y Position on the Y axis .z Position on the Z axis Acceleration .x Acceleration along the X axis .y Acceleration along the Y axis .z Acceleration along the Z axis Sphere .pos Spheres relative position to its units position .radius Spheres radius Polygon .pos Array of 3 Positions relative to the units position .normal A vector normal to the Polygon.

23

Artificial Intelligence
Overview The artificial intelligence (AI) section of the game will involve a large number of straightforward techniques. The overall idea is that in the game there will be multiple enemies that follow simple movement patterns. These various enemies will be generalized into one data structure which will be contained inside a squad structure that will handle these individual units. Bosses will be more complex and will warrant their own class to handle the various views and modes. Through this section I will take each structure and break it down into what it will need to have. Artificial Intelligence Class There will be one global instance of this class and it will be the overhead for anything dealing with AI in the game. class AI { public: AI(); ~AI(); SpawnSquad (int type); DeleteEnemy(Enemy enemy); Apply(); private: vector<Squad> SquadList; vector<Enemy_Type> TypeLookUpTable; }; AI() Constructor will create the TypeLookUpTable and any other initial needs. ~AI() Deallocate memory for any enemies not already destroyed when called. SpawnSquad(int type) Called when a new squad needs to be loaded into the level. Will take a parameter which is an ID number corresponding to a type. DeleteEnemy(Enemy enemy) Function that can be called any time an enemy should die which will deallocate memory for the enemy. Apply() Called every frame of the game, this will run through all the squads in SquadList and call their behavior function for all their units. It will also make checks to see if enemies have gone out of view and such. vector<Squad> SquadList Contains all squads currently in the game. vector<Enemy_Type> TypeLookUpTable A reference table used for creating squads.

24

Enemy Struct This is a struct that will hold all relevant information for an individual enemy. These will be used by every enemy in the game. struct Enemy { Physics mStructure; int mMovementSpeed; int mHitPoints; int mPointValue; enum mShipType; } Physics mStructure A structure created by the Physics that will contain all data needed to compute physics every frame. int mMovementSpeed The movement speed of the enemy. int mHitPoints How much life the enemy has. int mPointValue How many points to add to the total score if the enemy dies. ShipType mShipType This is an enum to tell what the ship looks like.

25

Squad Class The squad classs purpose to take a group of enemy structs and taking control of them by running through a behavior every frame when the Apply function is called in the AI class. class Squad { public: Squad(int TypeID); ~Squad(); ApplyAI(); private: vector<Enemy> EnemyList; (*Behavior) (Enemy e); }; Squad(int TypeID) Overloaded constructor that takes in a TypeID which will be used with the lookup table to find out how to build the squad. ApplyAI() Function that is called every frame which will run each enemy in the list through the behavior function. Vector<Enemy> EnemyList A vector list of all enemies contained in the squad. (*Behavior) (Enemy e) A pointer to a function that will handle the behavior of that particular squad. It takes in an enemy to apply the behavior to. Boss Classes Each boss poses a number of different attacks and camera angles. Because of this fact, each boss will be made into its own class which contain everything Class Boss_NameOfBoss { public: ApplyBossAI(); private: int CameraMode; int Parts; }; The idea behind the boss class is that since the fight is so specific and for lack of better terms hard-coded that the ApplyBossAI function will handle that specific fight sequence. This function will be public while all data such as the current camera mode and part hit points will all be stored as private data members.

26

Smaller Data Structures A few other structures are needed in the AI section. They are described here. struct Enemy_Type { int NumEnemies; Enemy Prototype; (*Behavior) (Enemy e); }; The Enemy_Type struct is used in the LookUpTable in the AI class. This is essentially a blueprint of how a squad should model it as. The data members include a pointer to a behavior function, an enemy struct to model off of, and how many enemies belonging to the group. The reason that squad creation is setup like this is because these enemy types will be defined in the level editor. This will make placement of enemies much easier. enum Ship_Type This enum will be used to tell what graphical image should be shown for the squad. This may be changed according to graphics class expectations at a later time.

Behavior Functions Each squad will apply a certain behavior function to each enemy in the list. These behavior functions will all take in an Enemy type and apply an intelligent action each frame. This will vary from heads toward the enemy to go around in an elliptical path. The attacks are specified in the GDD enemy section. BehaviorName(Enemy e); This is the prototype of the function with BehaviorName being a more intuitive description of the movement pattern such as Behavior_Kamikaze as an example.

27

Files For organizational purposes, multiple files will be created for the AI section of this game. They are outlined as follows: ai_main.cpp/.h contains declaration of the AI class and definitions of all the functions. Will include the ai_datatype.cpp/.h ai_datatype.cpp/.h this contains all structures and enums that are used by the classes such as Enemy, Enemy_Type, Ship_Type. ai_behavior.cpp/.h contains all the behavior function pointed to by squads. ai_boss.cpp/.h contains declarations of all Boss classes as well as definitions of their functions.

28

Level Editor
Overview The purpose of this tool is to allow us to design levels for our game. It will provide a way of placing objects in a 3-d world. And plotting out the rail pathway and enemy positions and camera change points. Visual Interface Normal windows interface with a menu. The graphical window of the tool has 2 viewports. One viewport is in top-down mode the other in side-view. In each given window it will show the level if loaded and a cube grid which is used to snap objects into positions. In the bottom right is information about current camera position and selected object position in the world. Functions Loading/Saving levels: Levels will not actually hold model data in their save files. But just save the name of the model that references a .x file with the position/orientation in the game world. The rail pathway is constructed of line segments, thus will be saved out as a list of points. Placing Objects: You will be able to select objects from a list of ones that you have included in the model folder of the editor, or you can search for them. Objects when selected will appear attached to your cursor. Depending on witch view you are in the object is placed accordingly. You will be able to copy/paste/delete selected objects in the world. Creating the rail pathway: The rail will be designed by placing points in the world to make up line segments which determine the path. This can be deleted a node at a time or the path entirely. Placing Enemies: Enemies are placed on the path at some specific time. This time will correlate to the overall length of the pathway. This includes not only position but grouping for enemies for instance what formation they are in what type of enemy they are. Defining Terrain: Terrain is represented as flat planes initially, but a height map can be added. Viewport/Camera: The main viewport can be toggled between top-down and side view. Each time the camera will change to the default setting. Inside a given viewport you can select different camera modes. Free-range this allows for free movement in 3-d space.

29

Target camera, this allows for rotational viewing on a selected object. And then default which is whatever that viewport has been specified top-down or side. Camera view changes: On the pathway you will be able to specify points where the camera should change to top-down to side or behind view in any combination of those. This interface will have the information of camera view which to switch and the vector of the direction it is looking. A camera change will be required at the beginning of the pathway because of this setup.

30

File format Objects: Name, position, orientation. Enemy: Name, grouping, orientation. Path: Position Camera view change: Position, camera type, vector in line of motion. The way it will be stored is through a area subdivision of sorts. Sections of the path will be broken up into cylinders of 20 unit lengths and the objects that lie within this volume will be saved under these section identifiers.

31

Sound
Overview Sound will be implemented using FMOD sound engine. The sound engine will be able to support Midi, Wav, Mp3 file formats. 3-d sound will also be included to use Doppler effects and such. SoundManager class SoundManager { public: SoundManager(); // Utility Functions void Create_Sound_Device(); void Play_Stream( const char *path, bool loop = false ); void Stop_Stream(); FSOUND_SAMPLE *Create_Sample( const char *path ); void Play_Sample( FSOUND_SAMPLE *samp ); void Stop_Sample( FSOUND_SAMPLE *samp ); void Play_Midi( const char *path, bool loop = false ); void Stop_Midi(); // Data FSOUND_SAMPLE *sfx[10]; FSOUND_STREAM *stream; FMUSIC_MODULE *midi; bool working; };

32

Appendix A
Coding Standards -Variable name should be as follows: int thisIsMyVariable; Underscores are to be avoided. - enums should follow the variable naming convention, but the names in the enum need to be all uppercase. -The predefined NULL should not be used. Initialize the variable with 0. -Commenting is a must, so others can understand your code, and so you can incase you forget, you can too. -Class should be prefix with their section type where applicable. i.e. aiFuzzyLogic -A classs private data should not be accessible outside of getter and setter functions. -Curly braces are to always be on their own line. Use only the indents given by MSVC7.1 -Constant global values are to be entirely uppercased. -The variables i, j, and k are reserved for for loops. When using iteration loops, use these variables. -The only functions that should be defined in .h files are getters and setters. Those functions should be inlined and no more than 1 to 3 lines of code.

33

Appendix B
Header Comment Blocks

File Header
/* Filename: Purpose: Data Created:

*/

Function Header
/* Function Name: Params & what they do: Function Purpose: Original Author: Creation Date: Date Edited: Edited By: What changed: Hours Spent: x1, x2, x3, ... , xn where each x is a week

*/

Single line commenting

Bad examples
int x = 0; //init x to zero //doing a for loop for(who ; care; :( )

Good examples
int x = 0; //making a variable to store the final result for returning //making a loop to go over every polygon to draw for( this; is; good )

34

35