coding standards to be continued - digipen · web view7 development platform 7 tools 7 external...

FP-FSComputer Patrol!!!

Technical Design DocumentAbeosomnius Studios

GAM 400 Fall 2005 of 59All content © 2004 DigiPen ( USA ) Corporation, all rights reserved.

Game Summary...............................................................................................4Summary..........................................................................................................................4

Introduction..................................................................................................................4Key Features................................................................................................................4Target Platform............................................................................................................4Schedule Overview......................................................................................................5

Cost analysis:...................................................................................................................6Target Platform and OS...............................................................................................7Development Platform.................................................................................................7Tools............................................................................................................................7External Code..............................................................................................................7Version Control...........................................................................................................7

Core Gameplay................................................................................................8Control Loop....................................................................................................................8

Major Game Classes.......................................................................................9Individual Game Objects.............................................................................................9System Design Philosophy..........................................................................................9Base object class ( Entity ).........................................................................................10

Resource Manager ( Resource ).....................................................................................10Sound.............................................................................................................................11Memory Manager..........................................................................................................12Artificial Intelligence.....................................................................................................13

Virus AI.....................................................................................................................13Chase AI:...................................................................................................................17

Object Manager.............................................................................................................19Lists and objects:.......................................................................................................19Level Tree..................................................................................................................20File Loading...............................................................................................................23

Graphics.........................................................................................................................26Overview....................................................................................................................26Vertices......................................................................................................................26Graphics Loop...........................................................................................................27HUD...........................................................................................................................28Lists............................................................................................................................28Shaders.......................................................................................................................28

Level Generation Algorithm:.........................................................................................30Choose a level style...................................................................................................30Generate Viruses, File Objects, and Level Doors......................................................30Create the level layout...............................................................................................30Populating the Level’s Rooms...................................................................................31Compiling the Rooms................................................................................................31Sending the Data........................................................................................................31Notes:.........................................................................................................................31Level Generator Data Structures...............................................................................32The Room Class:........................................................................................................33Level Layout Interaction............................................................................................33


Level-Wide vs. Room Specific Object Placement....................................................33Between-Room Door Placement...............................................................................33Room Compilation Functions....................................................................................34Room Class Sample Code.........................................................................................35Rectangular Grid Level Style Layout Algorithm......................................................37Sample Derived Room Classes..................................................................................38

Physics...........................................................................................................................42Gameplay...................................................................................................................44

Math...............................................................................................................................45Interfaces.......................................................................................................46

System Interface........................................................................................................46Data Structures..............................................................................................47

Introduction................................................................................................................47Model.........................................................................................................................47AngleAxis..................................................................................................................47ParticleSystemSettings..............................................................................................48Room Draw Data.......................................................................................................49Room Physics Object.................................................................................................49Folder Data................................................................................................................49Folder Tree Node.......................................................................................................50File Object.................................................................................................................50

User Interface................................................................................................51Input...........................................................................................................................51Main Play Screen.......................................................................................................51GUI............................................................................................................................52

Media Files....................................................................................................53Art And Video...............................................................................................................53

Artist Instructions......................................................................................................53Game Engine.............................................................................................................53

Files and Directories......................................................................................................54Directory Structure....................................................................................................54File Naming Conventions..........................................................................................54

Coding Style Conventions.............................................................................................55Purpose......................................................................................................................55Naming Conventions.................................................................................................55Whitespace.................................................................................................................55Comments and Doxygen............................................................................................56Misc...........................................................................................................................57Use of asserts.............................................................................................................57Use of exceptions.......................................................................................................57Use of debug output...................................................................................................57General rules..............................................................................................................58

Team Signoff.................................................................................................59


Game Summary

Summary Introduction

FPFS is a first-person shooter that takes place inside your computer. You step into your own root directory to clean the viruses from your infected computer. Files in your computer will have a representation in the game, and the viruses will actively try to infect them and kill you. Once you have cleared a room (folder) of viruses, you will be tasked with cleaning up all of their damage by healing all infected files. Only after this is done can you proceed to the next room. The game is complete when your entire computer is clean.

Key Features Stages generated based on the players' computer's directory structure Files are objects in the world

o Image files as pictures in frameso Text documents as binders with some of the text file printed on the fronto Video files as flatscreen TVs that play back some of the videoo Sound files as jukeboxes that play sounds

FPS gameplay Variety of tools and weapons Hours and hours of play

Target Platform All of these are subject to change, but the game will not require more than this.

Windows XP. DirectX 9.0 2.6 Ghz processor 512 MB memory DirectX 9.0c compliant video card with 128 MB of video RAM DirectSound compatible sound card 1 GB free hard disk space


Schedule Overview

Engine Proof: Working graphics engine with geometric shapes. Room generation (if only in text or 2D). Architecture skeleton.

First Playable: Graphical representation of rooms. Player movement in world. Placeholder enemies with basic AI. The ability to shoot and kill enemies. Collision detection and resolution. Image file representation. Animated textures.

Alpha: Basic particle systems. More diverse file representation. Basic gun augmentations. All enemy types with simple AI. Functional HUD and UI.

Beta: FX Shaders, lights and shadows. Advanced AI for all enemies. As many file representations as we can. As many gun augmentations as we can. Menus and saved games. Customizable controls.

GoldDue 4/22/2005

Game fully implemented, balanced and bug free.


Cost analysis: Salary for employees: Mark Gabby $80,000Lance Dyson $80,000Daniel Kellogg $80,000Ken Scott $80,000

Total salary: $320,000

Cost of 4 development computers:$1,500 a piece: $6,000

Production costs:Packaging $100,000Advertising $300,000

Total cost of project: $726,000

Monthly burn rate:Computer costs $7500Production costs $20000Expenses $5000Total Monthly Expense: $32,500

MSRP: $25.00Profit for developers(35%): $8.75Break even: 82,971 units

Worst case sell through: 85,000 unitsWorst case profits: $17,750

Best case sell through: 200,000 unitsBest case profits: $1,024,000

Expected case sell through: 125,000 unitsExpected profits: $367,750


Target Platform and OS All of these are subject to change, but the game will not require more than this.

Windows NT family of OS es, specifically Windows 2000.DirectX 9.02.4 Ghz or faster Intel compatible processors256 MB or more system RAM128 MB of video RAMGeForce 4200 video card.DirectX 9.0 compliant sound card800x600 32-bit color monitor100 MB of HDD space

Development Platform GeForce 4200 128MB256 MB RAMOnboard SoundWindows 2000

Tools Microsoft Visual Studio .NET 2003Microsoft PaintThe GIMP3D Studio Max 6MilkShape3DMicrosoft WordMicrosoft ProjectRational Tools (Purify, PureCoverage)Inno Setup 4.0

External Code DirectX 9.0DirectInputFMOD

Version Control Tortoise SVN


Core Gameplay Control Loop

The main control loop will have two distinct states. The first state will be the one that the game is in most often, when the player is inside a room playing a game. This loop will run through all of the systems and call their update functions once per frame. The other state is invoked when physics tells the game loop that the room generator is now loading in another room. A separate thread will be spawned by the room generator, and the game loop will go into a state of loading wherein all that is called is the input, player and graphics.

Main Game Loop Example

void GameLoop(){

if (!Loading){

InputInterface.Run();if (PhysicsInterface.Run() == true){

Loading = true;RoomInterface.LoadRoom();

}AIInterface.Run();SoundInterface.Run();GraphicsInterface.Run();

} else{

InputInterface.Run();GraphicsInterface.Run();if (RoomInterface.Loaded())

Loading = false;}

}


Major Game Classes Individual Game Objects

Game objects will all inherit from the Entity class which contains some basic data members that are applicable to most objects. These include:

a string for the name of the objecta string for the info on the objecta point for its positiona vector for its orientationa float for its angle of rotation around its orientation vectora pointer to the model in object space it referencesa bounding volumean enumerated state of infection (Infected/Not Infected/Scrambled/etc)a vector for its velocity/movementa float counter for its animationan enumerated type (Virus/Door/File/etc)an enumerated subtype (what type of virus/door/file/etc)

The object manager will contain lists of these objects that will be populated by the room loading system and read by almost every other system in the game. To create a new object, you must make a new class that derives from the Entity class and add any extra variables that you want to make known to other systems. You will also need to override all of the virtual functions in the Entity class so that they are specific to your object.

System Design Philosophy Systems in FP-FS are global singleton classes, meaning that there is only one

instantiated at any given time. This will mean that every object can interact with every other object, but you don’t end up with 3 graphics system objects by accident. The systems will be able to communicate with each other, but most of the interaction will be through the Object Manager. Hopefully, this will mediate the number of functions that are specific getters and setters so that there is less “spaghetti code,” between systems. If you want to set or get info about an object in the game, just talk to the object manager.


Base object class ( Entity ) This will be the class that all other objects in the game will derive from, and as such

will contain information that is pertinent to most objects. When an object derives from Entity, it will be free to add any other information, but must override all virtual functions to ensure that the object will work with the current framework.

Private members:std::string Name;std::string Info;Point3D position;AngleAxis orientation;Model *my_model;// BOUNDING VOLUMEInfectState infected;Vector3 movement;float AnimCount;Type my_type;SType my_subtype;Matrix WorldTransform;Float Scale;

Public functions:Model *GetModel(); // returns pointer to 3D model for graphicsAngleAxis GetOrientation(); // returns orientation

Resource Manager ( Resource ) The resource manager will be responsible for keeping track of all of the art resources

loaded in (meaning only art made for the game, not the files loaded from the users computer for gameplay) as well as the data that is loaded in from the room generator. These will be divided up into different lists so we can keep track of what needs to be destroyed when you enter and leave a room. This includes any models, textures, room templates, shaders, and any other objects that the game needs that are loaded in by files.

Public functions:LoadModel() : Loads a modelGetModel() : Get a model by indexLoadTexture() : Loads a textureGetTexture() : Retrieve a textureLoadSound() : Loads a soundGetSound() : Retrieve a soundPurgeList() : Tells the resource manager to delete everything in its Graphics or

Sound lists.GetShader() : Retrieve a shader


Sound

Overview:Sound will use FMOD for playing the audio. There will be two types of sound to

play in FPFS; music and sound effect files. Sound effects will be loaded at start-up using any format supported by FMOD; but mostly will be .wav files. Also sound files will be part of the Sound File types, so when the player interacts with them the Sound system will play it. The Sound system will have the ability to do 3D sounds based on the positions and speeds of different objects in the game. Music files will be streaming .mp3 and .wav files and will come from the directory that the player specifies. The music that will be played will be set up by the player to either be in order or random.

Interface:The following is a list of public functions that will be available from the Sound

system.

LoadSFXList(): Will take a text file that will list all the sound effects to be loaded.PlayMusic(): Will start playing the music in the specified directory; either in order or random, and what track position.PlaySFX(): Will play the specified sound effect either 2D or 3D; 3D will need position and speed of object.IncreaseSFXVolume(): Increase the sound effect given.DecreaseSFXVolume(): Decrease the sound effect given.IncreaseMusicVolume(): Increase volume of music.DecreaseMusicVolume(): Decrease volume of music.StopMusic(): Will stop playing music.PauseMusic(): Will pause the current playing music.PauseSFX(): Will pause the specified sound effect.

Dependencies:The following is a list of other systems that Sound will depend on.

Resource Manager: The Resource Manager will help keep track of loaded sound effect files.


Memory Manager

Overview:FPFS will be using a Memory Manager in order to keep track of all heap allocated

memory. The Memory Manager will also help in speed problems that can arise from frequent allocation and deallocation by using new and delete. The manager will be a page based link-list system where whole pages will be allocated at a time. All classes in the game should have their operator new, operator new[], operator delete, and operator delete[] overloaded to call the Memory Manager to get memory off the heap. The Memory Manager will use some debugging stuff in order to help keep track of memory problems that can arise; such as trying to delete memory that already has been deleted, and trying to find location of forgotten memory deletion.

Interface:The following is a list of public functions that will be available from the Memory

Manager.

AllocateObject(): Gives block of memory for one given object.DeallocateObject(): Gives manager back a block of memory for given object.AllocateObjectArray(): Gives a continuous block of memory for given number of objects.DeallocateObjectArray(): The manager gives back a continuous block of memory for given objects.

Dependencies:The following is a list of other systems that the Memory Manager will depend on.

NONE!


Artificial Intelligence Overview:

The AI system will be in charge of making the viruses “think”. The basic setup for AI will be using finite state machines that will be attached to any object that needs AI. All states in a machine will need ‘enter’ and ‘exit’ functions, which say what to do upon entering or exiting the state. Also each state will have a run function that actually tells the entity what to do while in that particular state. Each state has a main goal that is the driving force behind what the virus will be trying to do while in this state. All virus types and sub-virus types will have their own set functions for all their possible states; all these will be in namespaces by virus type then sub-type.

Virus AI States and Main Goals of Viruses:

BugBear: WANDER:Walk around room ALERT: Get all other BugBear’s attention CHARGE: Get within a certain distance of the player ATTACK: Cause damage to the player. RUN: Go as far away from the player as possible REPLICATE: Copy itself when it’s time to

Melissa: WANDER: Walk around room ALERT: Get all other Melissa viruses’ attention SURROUND: Have all called Melissa in a circle around player ATTACK: Cause damage to the player RUN: Get as far away from player as possible REPLICATE: Copy itself when it’s time to

Blaster: FLYING: Fly around the room MOVE: Avoid a shot shard ATTACK: Shoot at the player

CodeRed: FLYING: Fly around the room HIDE: Find an object to go behind to avoid getting shot ATTACK: Shoot at the player

PKZIP: CRAWL: Crawl around the room SEARCHFILE: Goes to a close by file


INFECT: Infects a file its inside RUN: Get away from the player

Nimda: MOVE: Moves around the room INFECT: Infects a file its inside RUN: Get away from the player SNEAK: Try to get behind the player ATTACK: Cause damage to the player

State Machines:These are how all the state machines will be connected.

BugBear:

Melissa:


Blaster:

Code Red:


PSEUDOZIP:

Nimda:

Pathfinding:All viruses in the game will use pathfinding in order to avoid objects and walls in a

given room. Pathfinding will be done using a node based system; where when a room is first created and before the player enters the room all the viruses will set nodes at their starting positions and then start traveling around the room. Then as the viruses travel through the room they will set nodes after going a certain distance from the previous node and a connection occurs between these two nodes that tells the path any other viruses can take. This method of pathfinding will be used because the rooms are procedurally created and locations are not known until run-time. Also when a virus finds a wall or another obstacle it will create a special node that tells that this could be used as cover from the player. When a virus needs to get to the player in order to attack it can look for the node that’s closest to the player, and then follow the path of nodes to the


player. Nodes that are set at file objects and obstacles will also have to have height information; for how high the object is, so that the Worms know their above or below the top of the object. In order to make the network of nodes more complete when a virus comes across an already existing node it will travel in a direction that has not been traveled yet.

Chase AI: In the game there will be chase AI that will make the viruses go after a given target.

The chase AI will use the concept of the fastest way between two points is a straight line; therefore once a target has been set the virus will take the straightest path that is possible with out running into an object. Viruses will use the already built network of nodes from the path finding in order to determine the route to take to get to the target. Also the player will be able to use homing shards on their crossbow; so the homing shards will use the same chase AI except it will look ahead to see if an obstacle is coming up then it will calculate a new path in order to get around the object in fastest possible way. The new path will be a parametric curve which will be calculated by the following three points; one point in front of the object, another on the opposite side of the object, and the last point will be equal distance from the other two points but on the third side of the object. Below is an example of how the curve will look like.

Interface:The following is a list of public functions that will be available from AI.

Update(): This will update the AI for all viruses that currently exist.

Dependencies:The following is a list of other systems that AI will depend on to work.

Player: AI will need to know information about the player to manipulate the virusescorrectly.


Room: Information about the room will be needed to run AI in order to move around in the room correctly.

Object Manager: AI will need the object manager to get information about other AI entities in the room, to get shot shards, and to get file objects.

Sound: Sound system will be used in order to create sounds that the viruses may need to make.


Object Manager The object manager holds lists of all gameplay and menu objects. Room Generator

will fill the room objects and the files, as well as the initial virus list. Physics/Gameplay will create and destroy objects, when a virus is killed or replicates and when shots are fired and hit. Input and AI will modify the player object and virus objects, respectively.

Because of the vast number of files in some folders, the room will be broken down into sub-rooms, as described in the Room Generator system. The sub-room layout is stored in a graph in Object Manager as part of the Room Information object. At all times, the Object Manager stores the lists for the sub-room that the player is in, as well as all sub-rooms directly linked to that sub-room. Space allowing, more sub-rooms will be stored. If space is threatened, then the lists for sub-rooms more then one room away from the player are freed, as the room geometry and file placement are procedurally generated. The only lists that will be saved are the list of Viruses and Power-ups, because we don’t want dead viruses re-spawning or discarded shards disappearing.

The following lists are unique to each sub-room: Room Objects Files Viruses. Power-ups

The Object Manager also stores all menu objects, such as buttons, dialog boxes the cursor, and text windows. These will be created, stored and destroyed by Menu. In game menus, such as the pause and map screens will be handled using the same system.

Lists and objects: Each of list and object has a unique function that retrieves the list. Note, objects and

lists do not necessarily appear in the order are shown.

Room Information Object (Including sub-room graph.)

Game Graphics List Static Object List

o Room Object List Wall List Floor List Ceiling List Obstacle List

o File List Files per Section

Door List

Dynamic Character Listo Player Object


o Virus List Replocator List

Bugbear List Melissa List

Worm List Blaster List Code Red List

Trojan List PKZIP List Nimda List

Projectile Listo Shard List

Homing Shard List Arching Shard List

o Weapon Particle Listo Enemy Fire List

Power-up Listo Stuck Shard List

Shards in Viruses List Falling Shard List

o health recharges

Menu Graphics List Cursor Object Window List Button List Text Box List

Level Tree

Tree CreationThe folder tree is created when the player starts a new game. It’s accomplished with

a simple enumeration of the player’s file system using windows file system commands.The tree stores the structure of the file system and the names and paths of all the

folders. As described in the GDD, the tree never changes. If the player deletes folders in their file system, then those folders will merely be empty rooms in the game.

The tree is stored in the Object Manager.

Sample Code:// There are three major types of folder:// Critical Folders// Sub-Critical Folders// and Default Folders. They are described// in the GDD's Victory Conditions section.GAM 400 Fall 2005 of 59All content © 2004 DigiPen ( USA ) Corporation, all rights reserved.

enum eFolderType{

kCriticalFolder,kSubCriticalFolder,kDefaultFolder

};

// This is data on an individual folder// that concerns the game.struct FolderData{

// Just the folder's name.std::string name;// The folder's name and path.std::string fullPath;

// The type of folder this is.eFolderType type;

// True if the folder is infested.bool infested;

};

// This is a tree node for the folder// tree.struct FolderTreeNode{

// The index of this node's parent.int parent;

// This folder's data.FolderData data;

// The indices of this folder's// children.std::vector<int> children;

};

class GameMap{public:

// Default constructor that creates a map of the// computer's entire directory structure.GameMap();// Constructor that creates a map of the computer's// directory structure from some base location.GameMap( std::string root );

// Returns folder information on a specific node. FolderData GetNodeData( int NodeID );

// Returns the number of children of a node.int GetChildCount( int NodeID );

// Returns the index of a particular child of the// node.


int GetChild( int NodeID, int index );

private:std::vector<FolderTreeNode *> nodes;

};


File Loading The file loading system loads these types of files: Images Sound and Music Files Video Files Exe Files HTML Files Text Files Unrecognized Files Icon Files DLL Files

The files are loaded by calling a function of the file loading system that takes in the file path, and returns a “File” structure. This structure has data on what the file type is, statistics from the file system, and the file’s position, scale, and orientation.

All of the data that is loaded in by the file loading system will be given to the resource manager to keep track of in a different list than the game resources.

Each of these data transmissions is accompanied by an ID which tells the system which file is tied to that particular custom data. This ID is another piece of data that the file loader stores in the File structures.

Finally, when the File structures are added to the Object Manager, Graphics looks at the type of the file, and draws the type of model in the scale, position, and orientation that it specifies. Any custom data is accessed by looking at the File’s ID member, which is then applied to the file.

When the user uses a sound file, the sound system is sent the ID of the file accessed, and uses that to play the correct dynamic sound.

enum eFileType{

kImage,kSound,kVideo,kExe,kHTML,kText,kUnrecognized,kIcon,kDLL

};

struct File{

Point3D position;AngleAxis orientation;float scale;

// Used by systems to render the correct custom// models/file effects for the file with specific

// textures, sounds, and so on.


int ID;

std::string fileName;// The path to the file's directory.std::string location;// The string from the OS ( if available )// telling the file's type.std::string fileType;

unsigned int sizeInBytes;// The amount of disk space this file// actually takes up.unsigned int diskSizeInBytes;

Date creationDate;Date modifiedDate;Date accessedDate;

eFileType type;

bool readOnly;bool hidden;

};

The return types of all Get functions are lists of references to the types of object gotten.

FunctionsGet functions for all lists and objects listed below. Most functions will have a prefix

C as well, meaning the return type is a constant. If a system doesn’t plan to modify the data at that time, use the C function.

AddRoomGeometry();AddFileObject( File, int section, SubRoom )AddVirus( Virus, SubRoom)AddShardPojectile()AddWeaponProjectile()AddEnemyProjectile()AddShardPowerup()AddHeathPowerup()

DeleteVirus()DeleteShardProjectile()DeleteWeaponProjectile()DeleteEnemyProjectile()DeleteShardPowerup()DeleteHealthPowerup()

ClearRoomMemory()ClearSubRoomMemory()


AddWindow()AddButton()AddTextBox()ClearMenuMemory()

Dependencies:Memory Manager to allocate space for it as it adds and deletes objects.


Graphics

Overview The rendering will be accomplished entirely by shaders. Shaders will be loaded in

and used through Direct X’s .fx file interface. The shaders will be loaded into the resource manager and called upon by graphics whenever they are referenced by an object. FP-FS’s game object will call the update function for graphics every frame. In this call graphics will obtain the players properties and set up the camera. After that it will get a list of all objects and particle systems that need to be drawn in the world, and draw them based on what shader they are referencing. Then Graphics will get the list of polygons for the room itself and draw it.

Vertices There will be two types of vertices – those that are transformed already into screen

space and those that are in world space and need to be transformed, lit, and drawn onto the screen. They will look something like this:

Transformed :struct TRANSVERTEX{

D3DXVECTOR3 pos; // position in screen spacefloat rhw; // reciprocal of homogeneous w (should be 1.0)float u; // texture coord. ufloat v; // texture coord. v

};

Untransformed:struct UNTRANVERTEX{

float position[3]; // The 3-D position for the vertex.float normal[3]; // the 3-D normal to the vertexfloat u; // the u and v coords in texture spacefloat v;float color[4]; // color of vertexfloat spec[4]; // specular color of vertexfloat sCoef; // specular lighting coefficient

};

These structures will be placed inside of vertex buffers that will be used by the graphics system to draw the objects. Graphics will keep a master list of all of the vertex and index buffers, and each model will have associated with it an index into these listsex buffer. An index buffer contains a series of integer indices into the vertex buffer that specify triangles. This will allow graphics to easily get the buffer, tell Direct3D that this is the buffer that it wants to draw from and then draw it as a triangle list once the shader variables are set up.GAM 400 Fall 2005 of 59All content © 2004 DigiPen ( USA ) Corporation, all rights reserved.

The rooms will be gotten from the room generator as a reference or pointer to a set of buffers (vertex and index). This will facilitate easy rendering, because nothing needs to be passed through a call but a pointer. All rooms will be given to graphics in world coordinates because they don’t reorient themselves or translate at all.

For the shaders, there needs to be a declaration of a custom vertex type. This is achieved thusly:

// Set up the vertex format so Direct3D knows about itconst D3DVERTEXELEMENT9 dec[] ={{0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION,0}, // position{0, 12, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0}, // normal{0, 24, D3DDECLTYPE_FLOAT2, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 0},// texture{0, 32, D3DDECLTYPE_FLOAT4, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0}, // diffuse{0, 48, D3DDECLTYPE_FLOAT4, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 1}, // specular{0, 64, D3DDECLTYPE_FLOAT1, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 1},// coefD3DDECL_END()};

// Create the custom vertex declarationif (FAILED(pDevice->CreateVertexDeclaration(dec, &VDecl))){

throw("Error creating custom vertex declaration.");}

this states that each vertex will have the set number of bytes for each data member (3-float, 3-float, 2-float, 4-float, 4-float, 1-float). Direct3D requires this because we are passing in non-standard things (like the specular color) that are not covered by the usual flexible vertex format declarations.

Graphics Loop Every frame, the view matrix will be recomputed based on the players position

and normalized orientation vector. Graphics will create vectors specifying an eye point, a look at point, and an up vector, then use the Direct3D function D3DXMatrixLookAtLH to create the view matrix for the scene. The eye point will be defined as the position of the player, and the look at point will be the point at the end of the unit orientation vector starting at the eye point.

Each object’s world matrix is created in the Graphics class based upon its position, axis of orientation, and angle in radians around the axis. The axis of rotation is created using the cross product of the forward vector (0,0,1) and the desired axis of orientation, then applying Direct3D’s angleAxis rotation function with the dot product as the angle to rotate. Another rotation is applied, if necessary, to rotate the object around its axis of orientation.

For HUD objects, the vertex buffers will be filled with the transformed type. This will allow us to easily display them straight to the screen. This also means that they will not have to pass in any sort of ModelWorld matrix either.


HUD The HUD will be a collection of objects that need to be drawn on top of the game

screen. These include windows for the health, ammo, current weapon and tool, and location of the player. Rather than have the player tell the HUD what it needs, the HUD will ask the player about the information that is necessary, and then display it. The HUD will also need information from the Object Manager which room the player is in, and the surrounding rooms so that HUD can draw its mini map. When a player looks at an object (the game will calculate the closest intersection of a ray cast from the player’s eye point), the information box will appear and be filled with information about the object (name, size, type, etc.). The text writing will be done by having a series of letters in a giant texture that then gets mapped to the screen based on an input string.

Lists Graphics will contain a list of all of the active vertex buffers in the game, as well as a

list of all of the index buffers that make up the triangle meshes. This will make rendering faster because there will be no need to pass around data or buffers themselves, just an index to them, because the objects don’t need to care about these buffers.

Shaders Shaders will be created as .fx files and implemented using Direct3D’s fx file

framework. This will allow for easy addition of new shaders, and easy rendering for objects. We load the shader into the resource manager using the function D3DXCreateEffectFromFile(). After Graphics gets the object it is supposed to draw and which shader needs to do it, it will set all of the values, set the pass (multiple if necessary) and then render the object, and close the shader. All of the shader constants will be set using the supplied functions from Direct3D (GetValue() and SetValue()).

For lighting, we will be using a Phong-type model for diffuse and specular reflection, with multiple sources including falloff due to distance as well as normal and texture mapping. This is a proven method for lighting that will produce reliable results that are computationally fast.

For shadows, we plan to use the method of generating shadow volumes. This is processor intensive, so we may, if it is too slow, move to using a simple shadow map. Volumes entail preprocessing all models to add degenerate quads that can be extruded to infinite depths that will form volumes of shadows based on light position. The values for these are then put into a stencil buffer, and checked against when all of the other objects in the scene are processed. This creates superior shadows, but requires three passes of the shader and a lot more time than a shadow map does.

TEXTThe text in the game will be handled mostly by the HUD object. This object will

reside in graphics, and be called every frame to draw the 2D info to the screen. The text will be drawn by creating rectangles that have unique UV coordinates into a texture containing letters and numbers.


Needed by graphics:Entity –

Point GetPos(); // to get the position for the camera (where the player is)Vector3 GetOrientation; // get the view direction for camera

Resource Manager –Model *GetModel(std::string Name); // to get the model to draw in object spaceTexture *GetTexture(std::string Name); // to get a texture by nameEffects *GetShader(std::string Name); // to get a shader (.fx file) by name

Object Manager –std::vector<Entity> GetGraphicsList(); // get list of objects that need to be drawnstd::vector<ParticleSystem> GetParticleSystems(); // get list of p-systems to draw

Room Generator-IDirect3DVertexBuffer9 *GetRoom(); // list of polygons that make up

// the room

For other systems:void Update(); // does all of the rendering of the sceneIDirect3DTexture9 *LoadTexture(std::string FileName); // loads a

//texture from //a file

int CreateVertexBuffer(int NumVertices, Vertex Data[]); // creates // and fills a vertex //buffer, adds it to the //list, and returns the //index

int CreateIndexBuffer(int NumIndices, int Data[]); // same as Vertex //buffer, but with an //index buffer.


Level Generation Algorithm: The Level Generator creates a single level to represent each folder. Levels can

contain anywhere from a single room to dozens.The reason a level sometimes has multiple rooms is because sometimes a folder can

have too many files to correctly display or load in at one time.Each of the subtasks in this algorithm roughly corresponds to a function of the Level

Generator.

Choose a level style This is done based on the following information: Folder Name:

1. My Documents2. Windows

Folder Location1. Subfolders of special folder names

Folder Metrics1. File Types2. File/Subfolder Balance

Generate Viruses, File Objects, and Level Doors The second task that the Level Generator must do is to create all of the room objects.

These include the viruses, the level doors, and most importantly, the file objects.

Create the level layout Different functions create the level’s layout, one for each level style. More level

layouts will be added and more functions coded for the level layouts as time goes on, which will allow increased variety as the project proceeds.

Each of these functions will use this data about the folder to create a level layout: Number of subfolders Number of files Memory Size of Level Objects

o Pictureso Webo Texto Any other that uses texture memory

This level layout creation function outputs a data structure containing all of the rooms.

Rooms are classes, and they are initialized by the level layout creation with all information they need to create themselves, which includes: Room style ( Different from level style ) Position of all doors to other rooms Etc.


Populating the Level’s Rooms For each room in the room data structure, the Room Populator Function adds objects

to the rooms by calling the “Add” functions of the room class. Objects include: Viruses, files, level doors, and room doors.

Compiling the Rooms The “Compile” functions of the rooms will call different functions of the room class

to create the room’s geometry and physics data, depending on the room style set by the level layout function. As development proceeds, more room styles and functions to create room styles will be added, which will increase the variety of rooms within each level style.

The result of the compile functions will be added to a list of “Room Objects” in the Level Generator class.

Sending the Data The last task that the Level Generator needs to do is to send the data on the rooms

and objects in the rooms to the Object Manager.It goes through all of the rooms, sending the Room Object, all of the viruses, file

objects, level doors, and room doors for each room.

Notes: The Level Generator checks at various places in the algorithm to see if it’s been

called a second time, to load another room. If so, it deallocates everything allocated so far and starts again with the new folder.

The Level Generator will do as much as it can with the next room, in light of available memory space. If memory space runs out, the Level Generator will pause until more memory has been freed.


Level Generator Data Structures The following source code shows the Room Graph data structure, which is used by

the Level Generator to set up the layout of a level’s room grid. This information is used by the Object Manager and Graphics to display the correct room in a level based on the player’s position and any doors open into adjacent rooms in a level.

// Represents a room’s node in the Room Graph. struct RoomNode{

// This is a std::vector of RoomIDs of rooms adjacent// to this one.// RoomIDs are also indices into the RoomNodez// std::vector in the RoomGraph class.std::vector<int> AdjacentRooms;

};

// Represents a single level’s room structure. The graph// nature alludes to the fact that a single level might// have more than one room.class RoomGraph{public:

RoomGraph();

// Returns the number of rooms that are adjacent// to the specified room.int GetAdjacentCount( int RoomNodeID );// Returns the ID of a room adjacent to this one.int GetAdjacentNode( int RoomNodeID, int Index );

// This returns the ID of the room that the// graph begins at.int GetStartRoom();

// These functions are used to keep track of the// room the player is currently in.int GetCurrentRoomID();void SetCurrentRoom( int RoomID );

private:// These are the RoomNodez.std::vector<RoomNode *> RoomNodez;

int startRoom;int curRoom;

};


The Room Class: Overview

The purpose of the room generation system is to take information about the folder that the user is going to and create a level from it, with geometry data for graphics system, collision data for the physics system, placing objects into the object system which will be displayed in the world, and sending data on the room to the AI system.

Level Layout Interaction The Level Layout functions have to interact with room objects on a more type-driven

level, that is to say, the specific type of a room class is important to the Level Layout functions.

There are two main types of functions that the Level Layout has to use to interact with a specific room type: Metrics query functions and metrics setup functions.

Metrics query functions are functions that tell the Level Layout functions what size the room is physically at a particular number of doors and file objects, and functions that help the Level Layout functions to decide how big each of the rooms should be.

Metrics setup functions are the functions that actually set the size, location, orientation, and any other room-type specific data values.

Level-Wide vs. Room Specific Object Placement The idea behind the room class is to separate the individual room generation into two

distinct parts: Overall level-wide requirements for each room, and individual room setup.For example, doorways between rooms must be set up when the level is laid out. File

Object placement and Level Door placement may need to be set up when the level layout is created, depending on the type of layout. Some layouts, for example, sort particular files into specific rooms, placing all images in one, all sounds in another, and so on. Others sort subfolders by name and place doors to them that way in rooms.

This separation is accomplished by use of the Get Current <Room Object> Capacity () and Place <Room Object> functions. Both the Level Layout and the Populate Level functions can call these functions on the rooms, so the placement can be left completely to the Populate Level functions, be done partially by the Level Layout and finished by the Populate Level function, or be done completely by the Level Layout function.

Because the Room Class depends on the room style, which is always set by the Level Layout function, it is divided into a base Room class with common functionality and derived classes for each room style.

Between-Room Door Placement As previously stated, there are multiple Level Layout functions. There is only one

Populate Level function, however.The Level Layout function keeps track of the specific derived type of a room class,

while the Populate Level function only has pointers to the base.The Level Layout function needs room-type specific interface, for the main reason of

being able to place between-room doors. Additional room-type specific interface will be


added as needed. Different derived room classes deal with between-room door placement differently, because the exact placement depends on their particular shape.

Because there’s more than one Level Layout function, each one only has to deal with the room types in the particular level layout that it creates.

Room Compilation Functions The room compilation function creates all data that is used by the two main game

systems: Physics, to resolve collisions with the room's geometry, and Graphics, to draw the room. All rooms represent this data with the same data structure, so the compile function is a virtual function in the base class.

Additionally, all objects added to the room are not guaranteed to have their positions correctly set until after the compile room function has been called. After the compile function for a room has been called, adding additional objects to the room has undefined behavior.


Room Class Sample Code Base Room Class/*

The virtual interface class that containsfunctionality common to all rooms.

*/class Room{public:

// Query Current Capacity Functionsvirtual int GetFileCurrentCapacity() = 0;virtual int GetLevelDoorCurrentCapacity() = 0;virtual int GetVirusCurrentCapacity() = 0;

// Add Object Functionsvirtual void AddFile( int FileID, File & CurFile ) = 0;virtual void AddLevelDoor( int LevelDoorID,

LevelDoor & CurLevelDoor ) = 0;virtual void AddVirus( int VirusID, Virus & CurVirus ) = 0;

// Get Object Count Functionsvirtual int GetFileCount() = 0;virtual int GetLevelDoorCount() = 0;virtual int GetVirusCount() = 0;virtual int GetRoomDoorCount() = 0;

// Get Object Functionsvirtual File * GetFile( int index ) = 0;virtual LevelDoor * GetLevelDoor( int index ) = 0;virtual Virus * GetVirus( int index ) = 0;virtual RoomDoor * GetRoomDoor( int index ) = 0;

// Compile Room Functionvirtual void Compile() = 0;

// Get Compilation Resultvirtual RoomObject & GetRoomObject() = 0;

protected:// The Room's Objectsstd::vector<File *> Files;std::vector<Virus *> Viruses;std::vector<LevelDoor *> LevelDoors;// ...

};


Sample Derived Room Class: Box-Type Room/*

A specific room class, derived fromthe virtual interface, that containsfunctionality for this specific typeof room.

*/class BoxRoom : public Room{public:

/* --- Base Room Interface Functions --- */

// Query Current Capacity Functionsint GetFileCurrentCapacity();int GetLevelDoorCurrentCapacity();int GetVirusCurrentCapacity();

// Place Object Functionsvoid PlaceFile( int FileID, File & CurFile );void PlaceLevelDoor( int LevelDoorID, LevelDoor & CurLevelDoor );void PlaceVirus( int VirusID, Virus & CurVirus );

// Compile Room Functionvoid Compile();

// Get Compilation ResultRoomObject & GetRoomObject();

/* --- Level Layout Functions --- */

// Metrics Query Functions:std::vector<Point2D> GetPossibleDimensions( float FileDoorRatio,

int FileCount, int LevelDoorCount, int RoomDoorCount );

// ...

// Metrics Setup Functions:void SetSize( int WidthUnits, int HeightUnits );// ...

// Level Layout Object Placement Functions// ( eDirection would be kNorth, kSouth, kEast, kWest )void PlaceRoomDoor( enum eDirection );

private:std::vector<Obstacle *> Obstacles;// ...

};


Rectangular Grid Level Style Layout Algorithm Factors:

o Number of subfolders ( doors )o Number of fileso Max number of files per roomo Max number of doors per room

To decide how big a level should be and how many rooms should be used to represent it, the algorithm is to find the number of subfolders and the number of files in a folder, and find out which is larger.

The larger of the two numbers is used to find out how many rooms should be used in the level. If this number is less than the max number of files or doors that a single room of the current type that’s been chosen, then there will only be one room. In the one room case, a room dimension is chosen that most closely approximates the number of files/doors in the room. If there’s more than one dimension that will work, then one is pseudo-randomly chosen, based on the previously seeded random number generator.

In the case that the larger of the two numbers is more than the max of the doors or files allowed in the room, the room generator has to create multiple sub-rooms for the folder.

Room Structure

Since the rooms fit together in a regular arrangement, as in the above diagram, each sub-room is identical in physical dimensions to every other one. Room dimensions are chosen so that the max number of either doors or files is divided most evenly by the


individual room capacities, weighted towards bigger rooms, with dimensions pseudo-randomly chosen if the rooms are the same capacity.

Once the layout is created as above, the between-room doors are added to each room. This layout function provides all the data needed by the next function, the Level Generator Populator function, which will add all additional objects to the rooms.

Sample Derived Room Classes ( Not to scale )

Rectangular Prism

Octagonal


Pentagonal

Room Scale and SizeThe basic unit of these three types of rooms is the “File Placement Zone” which is

shown as the blue boxes in the floor plan pictures above. The size of this zone is eight player heights (PH) on a side, or sixty-four PH2.

The buffer zones along the edge of the File Placement Zone are always at least ½ PH. For the basic rectangular prism room, they are exactly ½ PH.

The other main unit of a room is the width of an “Obstacle Placement Zone,” which is 1 PH.

These three rooms have default ceiling heights of 2 PH.

Room Obstacle PlacementThe room compile function goes through each file placement zone individually

and places one of these combinations of obstacles per zone: 1-3 small obstacles 1 medium and 1-2 smalls 1-2 mediums 1 largeObstacles are placed flush with the floor, ceiling, and/or walls depending on what

type they are.

Room Door PlacementDoors are placed on the walls of the folder. Certain door positions, notably the

diagonals on pentagonal rooms and the center of the longest side, and the four doors in the center of each side for rectangular prism and octagonal rooms are the only places intra-folder doors can be placed, for the purposes of a logical structure for rooms consisting of multiple subrooms. These between-room doors are placed by the Level Layout functions.

Doors to other folders can be placed in other places along the walls. Unless otherwise noted in an individual room style’s description, one door will be placed per file placement zone length along a wall, in the center of that wall.

Room Decoration PlacementRoom decorations are placed on wall decoration zones. If a door is placed on a wall,

only the top wall decoration zone is used.

Example Room Wall ( with two wall decoration zones )


The different arrangements of wall decorations are similar to the obstacle arrangments:

1-3 small decorations 1 medium and 1 small 1-2 mediums 1 largeAgain, like obstacles, room wall decorations are placed flush with the wall and then

knit into the geometry.

Room Geometry GenerationOnce the objects are placed in the room, the basic room geometry is knitted

together by creating triangles that go between the room corners and objects in the room, like obstacles and decorations. This is the next-to-last step in the room compile function.

Intra-folder doors are the exception. They aren’t knitted together in the same way, a ‘hole’ is placed in the wall and the door is simply placed so that it overlaps the hole, hiding the edges. This way, sub-rooms can be independent of one another geometry-wise.

Room Triangulation Example

The above diagram is an example of how a room’s geometry would be created after doors and decorations are placed.

This basic “box type” room starts out as eight vertices on the corners, which are then scaled based on how many objects should be in the room. Once they’re correctly scaled, the objects, including files, obstacles, and decorations, are placed. The placement zones are used as a guide in this process.

Finally, the decorations and doors are “knit” into the level by creating triangles around the vertices.

Room Physics Data GenerationPhysics data is calculated by the room compile function.

Room File Object PositioningFiles are positioned in the room compile function.


The Level Generator’s Populate function evenly distributes the files in individual rooms.

Depending on the room style, files can be sorted by type, size, or name when placed in file zones.

The files are placed in one of several file placement patterns within the individual zones. This is done by setting their location variables in the file structures. These patterns include:

Top View, Example File Placement Patterns

Thanks to the simplicity of the patterns, these examples are just a starting point. The game code can easily use many more than these six patterns.

Room type can also influence file placement. In particular, rooms with a random file distribution will have randomly placed files, not conforming to any of these patterns.

Room Virus PlacementVirus count is determined by a combination of the folder’s depth and also by any

objective tagging the folder might have. In general, the deeper the folder is, the greater the number and difficulty of viruses will be.

Trojans tend to be placed in file placement zones farther away from where the player starts. Worms are placed in intermediately close zones normally, and replicators are generally placed close. There are random variations within these default patterns.

Unlike the other random placement, the random virus placement random numbers are generated based on the current time, so virus location is not necessarily always the same with the same folder name and file types in the folder.


Virus Development – DepthEvery 2 levels away from the root is a stage.

Virus Starting Depth Starting Viruses Viruses per StageBugbear 0 4 4Blaster 2 1 1

PSEUDOZIP 4 1 1Melissa 8 4 4

Code Red 10 2 1Nimda 8 2 1

Virus Development – ProgressEvery 10 rooms cleared the viruses become stronger. Appearance is the number

of cleared rooms until that virus will appear at a depth of 0. From then on, the depth will be just as if they had started at depth 0.

Virus Health Damage Speed Max Speed AppearanceBugbear 2 1 0.05 ps 2 ps 0Blaster 3 1 0.1 ps 1.5 ps 5

PSEUDOZIP 1 N/A 0.05 ps 2 ps 10Melissa 3 1 0.1 ps 2 ps 30

Code Red 3 1 0.05 ps 1.75 ps 50Nimda 2 2 0.05 ps 1.75 ps 40

Functions ( Interface ) // This function spawns a thread that loads the room.

void LoadRoom( bool & Status ) void PreFetchRoom( int RoomID ) // May not be necessary.

AIdata * GetAIdata();Functions Needed

From Object Managero AddPhysicsObject( int SubRoomID, std::string type, float

width, float length, float height )o AddFile( FileStructure fileData )

From Graphicso CreateBuffers( int IndexCount, int iData[], int VertexCount,

UTRANVERTEX VertexData[] );

Physics Because there are no true forces being used in the game that need to be simulated,

the physics for FPFS will primarily be movement and collision detection. The process for collision detection and resolution involves projecting the moving objects to where they will be based on their movement vector, then checking for collisions against all objects it could collide with.


There are two types of moving objects in FPFS: characters and projectiles. Each are handled a little differently. Characters are the player and viruses while projectiles are shards, enemy fire and any other weapons.

With characters, we are only concerned with their movement along the floor plane. Therefore, all collision checks are against the footprints of objects on this plane. This is computationally simpler and faster and will get the behavior that is desired. Also, since the player and viruses don’t move much from frame to frame, the physics system only compares the projected placement of the character. If the character isn’t moving, it will not be checked against anything, but other characters will be checked against it. Characters will only be compared against files, room geometry and other characters.

With projectiles, because they move fast enough to potentially skip a collision, their are extruded to their projected location. This creates the bounding box that is used for fine collision. Because this is potentially a very long thin box, the gross collision will use a sphere around this box for its check. This will catch more objects then needed explicitly, but should still be faster then doing a fine check against everything. Projectiles will only be compared against files, room geometry and characters.

After the movements of the player and all the viruses, the positions of the stuck shards in viruses are updated. The information about the stuck shards is saved as a vector from the virus’s center point. Shards stuck in static objects, such as files and walls, don’t need updating since the shouldn’t move.

There are three kinds of Physics bounding objects. Planes, gross spheres and cylinders and fine bounding polygons.

Planes are used for room geometry. Specifically, the walls, ceilings and floors. Because these planes tend to be very large, there is no reason to use a circular based gross collision check, and all objects are checked against them anyway. For dynamic characters, they only check against the walls and the floors they are not currently recorded as standing on. The purpose of this is to check against sloped floors on multi story rooms. If there is only one floor, this check isn’t performed. Projectiles are compared against all wall geometries.

For gross collision detection, static and dynamic objects use either spheres about their center point or cylinders perpendicular to the floor plane. These use the center point of the object and a radius for spheres, or a radius and height for cylinders. For character movement, both player and viruses, this is all that will be done for some files. It may look a little strange, the player not being able to walk directly next to the side of a files, but the effect shouldn’t be noticeable. Some files, particularly thin ones like video flat screens, will use fine collision. Projectiles will always use fine collision except when colliding with plane geometry. All gross collision bounding shapes completely contain their fine bounding shapes. Characters will only collide with gross collision shapes when they move. Projectiles will check gross collision first, and only perform fine collision against the objects it collides with in the gross collision.

Fine collision bounding boxes are basic geometric shapes, such as spheres, cylinders, boxes, prisms and pyramids. Spheres are the same as the gross collision, but the algorithm tries to find the time and location of intersection. Cylinders are similar, but use the orientation vector and quaternion. Cylinders that are rotated will use a sphere as their gross bounding shape. All other bounding shapes are made of points and plane normals. These shapes are scaled about the object’s center point by it’s height, width and length. Polygonal shapes also use the orientation vector. No collision boxes will be sheared.


Interfaceint Update(); //Called by GameLoop

DependenciesObject Manager for all game object lists.Input for updating the player

Gameplay This is the section of the system deals with all the special case exceptions to standard

movements and collisions. This includes the creation/deletion of objects, from shots being fired or enemies being killed. This is also where the interactions between objects is resolved.

Most of what Gameplay is concerned about is updating animation counters. Most objects in the game, from the player to viruses to files, have an animation mode and an animation counter. These animations are special behaviors that take several frames to achieve, or will create projectiles.

There are 3 ways a behavior is set. Input changes the animation state of the player object, such as using the equipped weapon or tool and switching between weapons. AI sets the animation state of the viruses to set a behavior, such as shooting, replicating, infecting a file or even some idle animation. The final way is through interaction with an object. Viruses reeling after being shot, files activating after being hit by a tool, files being infected, etc… This makes the animation state act like a massager data between Input, AI, Gamplay and Graphics.

For example, if the player is equiped with the regular crossbow and the player fires. The player's animation state is set to Firing. While in this state, the player can still move, but he won't be able to fire or switch weapons. According to the GDD, it takes 0.5 seconds for the crossbow to fire after the button is pressed, for the animation. Gameplay will update the player object's animation timer, which was reset to 0 when the animation state was changed. Once the animation timer 0.5, Gameplay creates a shard at approximately 3/4 the players height in the direction the player is facing. The crossbow has a reload time of 1 second, so Gameplay keeps updating the counter while the animation state remains Firing. When 1.5 seconds have passed and the animation is complete, Gameplay sets the player animation state to neutral again.

Player Animation States Firing Switching to Tool Switching to Weapons

(Note, the actions and times for all the above states are dependent on what the player has equipped at the moment.)

Hit/Stagger

Replicator Animation States Firing Replicating Idle


Sighted Player Run away Hit

Worm Firing Hit

Trojan Moving Infecting file Hit

Files Being infected Being healed Multi-tool Descrambler Disinfector

Doors Open Close

Another function of Gameplay is to detect what object the player is looking at. The HUD displays the name and statistics of this object and all tools directly access this object when their animation states reach its activation time. To do this, Gameplays projects the ray from the player’s orientation vector and finds the object that first intersects it. Since the tools have a limited range, it will only store object that it intersects within the specified distance, about three player heights. Only files, doors, viruses and power-ups are checked in this manner.

Math Math isn’t so much a game system as a utility library, with normal math operations.

It will include points, vectors, and other structures, and will be added to as the need arises.

Functions include:Vector operations (dot products, cross products, addition, multiplication, etc.)Point operations (adding with vectors, etc.)Matrix operations (3 and 4 dimension, multiplication, inversion, transposition, etc.)


Interfaces System Interface

Each system will have an interface class that is included by all other systems that want access to it. Each system will only be instantiated once via an Instance() function. This function will return a reference to the system, and if one have not been created, will instantiate one. The interface class will call this in its .cpp files, but will not include the header for the system, so that if other systems want to talk to graphics, for example, they don’t need to include all of Direct3d.

The interfaces will include all of the functionality needed by the outside world, but will not have any of the inner workings of the system in it. With this system, we can talk to all of the systems, and

Sample input interface:class InputInterface{

public:InputInterface();void InitializeInput(); MouseState GetMouseState();KeyboardState GetKeyboardState();

private:};

With this interface, anything that wants to talk to input (like the main game loop) will not have to include Input.h, meaning they won’t have to drag in all of DirectInput.


Data Structures Introduction

This section describes the major data structures used in FP-FS. These structures will make it easier for some systems to talk to each other

Model This data structure will hold all of the information of a model loaded in from a

3D modeling package. It will contain a reference to a texture, an index into the graphics list of Direct3D vertex buffers, an index into graphic’s Direct3D Index buffers, and a reference to a normal or bump map. These will be loaded into the resource manager and stored there to be called by graphics whenever it needs to display them. Each object that needs to be drawn in 3D (i.e. not HUD objects) will have a reference to one of these model structures. The object will also need a position for the center of the model, an orientation vector, and a matrix to transform the model from object to world space.

Example:struct Model{

int BUFindex;int INDindex;int numTriangles;int TEXindex;int NORMindex;

}

AngleAxis Structure to hold the angle axis representation for orientation of objects in

3D. This is just a set of a Vector3 and a float representing the angle of rotation around that axis in radians.

struct AngleAxis{

Vector3 axis;float angle;

}


ParticleSystemSettings A structure describing to the Graphics engine how to draw a particle system.

// Linear interpolates the particle system between these values.unsigned int startColorunsigned int endColor// The “cone” of the particle system, in radians. “Angle of dispersion.”float angle// The speed of the particle system particles.float magnitude // The direction of the particle system. Only really applies if the cone is less than a // full circle.Vector<float> direction// The number of particles in the system per second it exists.unsigned int density// The time the system lasts, in seconds.float time // The image the particle system uses. eGraphics Graphic

GAM 400-A Fall 2005 of 59All content © 2005 DigiPen ( USA ) Corporation, all rights reserved.

Room Draw Data // Data on how to draw a single room. Doesn’t include// data on adjacent rooms belonging to the same folder.// A std::vector of these are stored in the Object Manager.struct RoomDrawData{

// Indicez of the vertex/index bufferz that this room// uses. The actual data is stored in Graphics.std::vector<int> BufferIndex;

// These texturez are mapped to the buffer IDz.std::vector<int> texturez;std::vector<int> normalMapz;

};

Room Physics Object // Physics data on a single object in a room.// This will be sent to the object manager, which// can then separate this data into multiple lists.struct RoomPhysicsObject{

std::vector<Wall *> wallz;std::vector<Sphere *> spherez;std::vector<Box *> boxez;std::vector<Cylinder *> cylinderz;

};

Folder Data // This is data on an individual folder// that concerns the game.struct FolderData{

// Just the folder's name.std::string name;// The folder's name and path.std::string fullPath;

// The type of folder this is.eFolderType type;

// True if the folder is infested.bool infested;

};


Folder Tree Node // This is a tree node for the folder// tree.struct FolderTreeNode{

// The index of this node's parent.int parent;

// This folder's data.FolderData data;

// The indices of this folder's// children.std::vector<int> children;

};

File Object struct File{

Point3D position;AngleAxis orientation;float scale;

// Used by systems to render the correct custom// models/file effects for the file with specific// textures, sounds, and so on.int ID;

std::string fileName;// The path to the file's directory.std::string location;// The string from the OS ( if available )// telling the file's type.std::string fileType;

unsigned int sizeInBytes;// The amount of disk space this file// actually takes up.unsigned int diskSizeInBytes;

Date creationDate;Date modifiedDate;Date accessedDate;

eFileType type;

bool readOnly;bool hidden;

};


User Interface Input

The input system is a wrapper around DirectInput8. When called, it takes instantaneous keyboard input and buffered mouse input. The input object will directly modify components of the relevant objects that need it. There will be two versions of the update function for input: one that modifies the player object, and one that modifies parts of GUI. The player will only care about a few buttons and the mouse position. It will need to know where the mouse is now, and whether the user has pushed the forward, backward, left, right, fire, or weapon select buttons. The GUI will need to have the cursor position and one mouse button for the most part.

Main Play Screen The HUD object will live in the Graphics file because graphics is the only system that cares about the HUD. It will gather all of the information it needs from the player and the resource manager. The main points that need to be drawn are the players health, the current room you are in, the current weapon or tool, and the ammo for your selected shard. Most of this information will come from the player directly and will be written on top of bitmaps that are created with the transformed vertices so that they are referencing screen-space and do not need to be transformed. The hardest part will be drawing the mini map on the bottom of the screen that tells the relative location of the player and some of the surrounding folders and their names. This information is held in the tree that was created when the player started the game, and will be queried from the resource manager. Other than that, the main play screen will just consist of what the player can see, and the weapon or tool that he/she is currently using. The HUD will also handle all of the text in the game. This will be drawn using a font bitmap rather than using Direct3Ds font class.


GUI The GUI handles all of the menu objects that are created and used outside of the

main game. This include splash screens, and the menus that make up the frontend. This will be a fairly simple job because the only menus we have are the main menu screen, the load game screen, and the options menu. It will have its own loop that calls a modified version of the input wrapper and graphics.

In the main menu screen, the only options are “New Game,” “Load Game,” “Options,” “Credits,” and “Quit,” which are all represented by buttons. If you choose a new game, there will just be a loading screen while the game loads up the tree for your computer and then starts the game. If you choose to quit, the game will just go away.

In the Options screen, there will be a selector for the resolution of the game, and the volume for the sound and music. These options can be selected by buttons that point to the left and right and cycle through the appropriate possibilities for the option. There is also a button for key configuration that takes you to another menu that has the possible actions and the keys currently associated with them. To change one, you click on the action and then press the desired button you want to map to it.

For the Credits menu, a screen will show up with the names of all of the team members and what they did in the game. There will be a button to go back to the main menu screen.

If you choose to load a game, you will be taken to a menu with all of the available saved games, and you can click on which one you want to load and it will then ask for confirmation and then load the game where you saved last.


Media Files Art And Video Artist Instructions

If you want to make a model and get it drawn in the game, you will create it in MilkShape3D and export it using the FP-FS.ffMdl plugin. Then, you will change the MDL.ini file to add this model into the game. When the list is created by the resource manager, every model will have an index and a filename associated with it.

Game Engine Every frame, the game loop will call the graphics interface update function to ask the

graphics engine to draw the current scene. In this loop, the graphics engine will call the object manager for the list of all objects that have graphical representations. All of these objects will have a reference to what model they are to have drawn and which shader they want to be drawn with. Graphics will get the pointer to this Model and shader and draw the objecs in a loop until they are all drawn. The viewport is obtained by asking the player where his position and orientation are. Since this is a first-person game, the camera will just be looking wherever the player is oriented.

Sound and MusicSounds will be loaded into the Resource Manager much like the textures. If you

need to have a sound added, add it to the list in the sound.ini file and resource manager will load it in the game. All you need to do is keep track of which one it is in the list, and refer to that when you send an index to get it.


AppendicesFiles and Directories Directory Structure

FPFS\ Docs\

o TDD and GDD, and other design documents Src\

o .cpp and .h files.o Proj\

Project Files Any Windows resource files

Obj\o Debug\

Debug object fileso Release\

Release object files Bin\

o .exe for game and any toolso Media\

Textures\ Any bitmap art

Models Any models that are to be drawn

Sounds\ Any sounds for the game

Music\ Any music for the game

Levels\ Level files

Objects\ Object files

Tst\o Debug .exe for the gameo Release notes describing current state of gameo Files\

Any testing-specific files

File Naming Conventions FP-FS’s file naming conventions are as follows-


System files are named directly after the system. IE- Graphics.cpp for the graphics system implementation file. Header files for the systems have the same name with a .h extension instead.

Implementation for templated classes will be in a file named Whatever_I.h Sound files will be named SoundTypeSoundName.wav

Coding Style Conventions Purpose

This guide is to keep the style consistent throughout the code base.

Naming Conventions Variables

o First word lowercase, all other words capitalized, no underscores.

o Prefixes-

Pointer variables shall start with a lowercase “p”

Functions

o First word capitalized, all other words capitalized, no underscores.

o Non-member functions must have the prefix “n”

Constants

o All caps, with underscores separating each word.

Definitions

o Type definitions using typedef shall begin with a lower-case “t”. (probably

won’t even be used)

o Enum data types names shall have a lowercase “e” prefix, and each item in

an enum shall have a lowercase “k” prefix.

Whitespace Any expression in parenthesis will be bordered by whitespace as well as

parenthesis, with no whitespace before the parenthesis or after them.

o IE- ( expression ), not (expression).

There shall never be a space between a unary operator and its operand.

An open curly brace shall always go on a new line, and indented the same amount

as the previous line.


Indentation is one tab. Tab length is 4 characters.

Class sections “public,” “private,” and “protected”; and all things in switch

statements, shall be indented according to the defaults of the VC++ .NET IDE.

There shall be two blank lines between function definitions.

Comments and Doxygen File header comments and function header comments must use doxygen-style

comment blocks. All other comments must be C++ style (“// comment”).

All files must have file header comments, all functions must have at LEAST a \

brief tag. Anything with non-trivial returns or variables should have more than a \

brief tag.

Function comments should be located in the .cpp files.

For doxygen comments, use the notation “/*!” and “//!” only.

The proper format is

Required doxygen tags include:

For file headers-

“\file”, “\author”, “\date”, “\brief”,

For function headers

“\brief”, “\param”, “\return”, and “\exception”. ( All that apply )

Put these function blocks above all functions, using the

/*! */ syntax.

Do the same thing for structs and classes.

Try to use doxygen to keep track of “to do” items and known bugs, using the “\

todo” and “\bug” tags.GAM 400-A Fall 2005 of 59All content © 2005 DigiPen ( USA ) Corporation, all rights reserved.

/*!\briefDescription of what the function does.\param param1What this parameter is\param param2What this parameter is\returnsWhat this function returns.

*/int Sum( int param1, int param2 ){

return param1 + param2;}

Headers in each code file that include the primary coders name, the purpose of the

file, and the DigiPen copyright.

Misc No global variables permitted.

Only C++ style casts are allowed. This is how to do a normal C++ style cast-

o reinterpret_cast<int> ( float_var );

In constructor functions, initialization lists shall be used to initialize all member

variables.

All switch statements shall have a default case.

#defines are only allowed for header file inclusion, which shall be in the format

“#define FILENAME_H”.

All compile-time warnings and errors shall be removed from the code before

being committed.

std::string shall be used instead of null-terminated character arrays wherever

possible.

No extra parenthesis shall be used after the return operator.

Never use NULL. Instead, use 0.

Header files shall not contain any ‘#include’s that they don’t need.

Use of asserts General- check for preconditions of functions or algorithms

Use of exceptions Deal with exceptions that appear from any APIs- do not use them ourselves.

Use of debug output Singleton class that doesn’t exist unless you enable it- has string, number, and image output (if not too complicated).Maybe separate output formats- constant like FPS, or scrolling. Also different output ‘threads.’A separate window that you output to. Output to screen or to a file. No image output if to a file.Put in calls to the debug manager when debugging.

General rules Daily debug and release builds


Daily testing of profiler and other rational toolsTry to code in pairs- to help with code quality and readability.


Team Signoff J. Lance Dyson, Tech Director ________________________________

Mark W. Gabby, Designer ________________________________

Kenneth Scott, Producer ________________________________

Daniel Kellogg, Art Director ________________________________
