“VEKTOR SPACE” - DigiPen: A Leader in Game ... · Web viewWord Processor: Microsoft’s Word...

“VEKTOR SPACE”TECHNICAL DESIGN

DOCUMENTGAM450 Class

“DigiPen Institute Of Technology”January 28th, 2003

Team Members:Producer: Jhon Restrepo.

Technical Director: Ricardo Villarreal.Designer: Mark Thrall.

Art Director/ Product Manager: Nathan Feldman.Lead Tester: John Enney.

Über Programmer: Steven Johnson.

INDEX

Introduction_____________________________________________________________2

Platform/OS_____________________________________________________________2

External Code___________________________________________________________3

Code Objects_____________________________________________________________3

Control Loop____________________________________________________________4

Game Object Data________________________________________________________6

Data Flow______________________________________________________________12

Game Physics / Stats_____________________________________________________13

Artificial Intelligence_____________________________________________________17

Graphics Engine________________________________________________________19

User Interface__________________________________________________________38

Multiplayer_____________________________________________________________48

Input__________________________________________________________________61

Sound_________________________________________________________________67

Optimization____________________________________________________________70

Install_________________________________________________________________70

Copy protection_________________________________________________________71

Tools__________________________________________________________________71

Schedule_______________________________________________________________73

“Vektor Space” Technical Design Document 1-28-2003 1

Introduction

Vektor Space will be a 3D vehicle simulation game supporting Windows only. The programming language we will be using is C++ as well as the WIN32 APIs, DirectX 8.1 and Winsock. For more information about the design please refer to the Game Design Document. We expect to have a simplified version of the single-player game mode by the end of the first semester, and a more elaborate version with multiplayer support on the second semester.

Platform/OSTarget

Vektor Space runs only in the Windows PC platform with the following minimum requirements:

OS: Windows 2000, XP, ME and 98. CPU: 1.6 ghz Pentium 4. DirectX: DirectX 8.1 or higher. Network: TCP/IP protocol should be installed. Memory: 256mb of RAM. Disk Space: 50mb of free space are needed to install the game. Input Devices: Windows compatible mouse and keyboard. Video Card: 32mb of memory and 3D acceleration in hardware. Multiplayer Requirements:

o A working LAN with unique IP addresses for each machine. o An Internet connection is needed to access the online database of servers.

Developer

The same requirements from the target apply to the developers, but we also require the following:

Compiler: Microsoft’s Visual C++ 6.0. Code versioning system: Microsoft’s Visual Source Safe 6.0a. SDK: Microsoft’s DirectX 8.1 SDK. Word Processor: Microsoft’s Word 2000.


External CodeVektor Space uses the following external libraries and applications: DirectX 8.1 libraries and utilities created by Microsoft

http://msdn.microsoft.com/directx that enable us to have a more direct access to the hardware from the video card, input devices, etc.

FMOD sound library http://www.fmod.org created by Firelight Technologies, that let us play compressed audio formats.

The Installer will be created using an external compiler called InnoSetup from Jordan Russell’s Software http://www.jrsoftware.org this will allow us to create an executable file that contains the installer and the game compressed in it. This is particularly helpful when downloading the game from the Internet.

ISTool http://www.bhenden.org/istool/ uses a GUI to helps create scripts for InnoSetup.

Code ObjectsThe following are statically linked libraries into the game .exe file (they are part of Windows and DirectX):WS2_32.LIB, Dxerr8.lib, D3d8.lib, D3dx8.lib, dinput8.lib, dxguid.lib, kernel32.lib, user32.lib, gdi32.lib, winspool.lib, comdlg32.lib, advapi32.lib, shell32.lib, ole32.lib, oleaut32.lib, uuid.lib, odbc32.lib, odbccp32.lib

These libraries were created by our team. Graphics.lib Input.lib Sound.lib Math.lib Network.lib Timer.lib

Other files are linked dynamically, including the directx dlls


http://www.bhenden.org/istool/

http://www.jrsoftware.org/

http://www.fmod.org/

http://msdn.microsoft.com/directx

Control Loop

The Game Control class is handling the control loop. The variables used for the class are shown below:

Ctimer mGameTimer; //timer for game framesCtimer mRenderTimer; //timer for rendered frames

u32 mGameFramesCurrent; //current game frames for the secondu32 mRenderFramesCurrent; //current render frames for the

second

Ctimer mFPSTracker; //tracks to make sure FPS is correct

u32 mGameFPS; //current game FPSu32 mRenderFPS; //current render FPS

Cstring * mGameFPSString; //string for outputting game fpsCstring * mRenderFPSString; //string for outputting render

fps

u32 mDisplayFPS; //BOOL for showing FPS or not

Cd3dMain * mGraphics; //object storing all D3D functionss32func mGameFunc; //current game function

//used only when the client is also the servers32func mServerFunc; //current game functions32 mServerActive; //TRUE or FALSE as to use the server

func or not

CmenuChain mChain,mChain2; // Menu chain used for the main game menus

s32 mQuit; //set to TRUE when program should terminate

Game flow is controlled on a frame basis. The frame rate is based upon the number of frames desired per second (set in time.h). After a time has passed equal to 1000ms / frame rate, then the function pointed to by the mGameFunc function pointer is called. If there is a server running, then the server is also called at this time. Rendering is controlled in the exact same manner as the actual game loop, with the only exception being it uses its own frame rate.

By handling frame rate as two independent parts (one for game frames and one for rendered frames), the game can maintain a steady frame rate, without slow-down. This is because the rendered frame rate can lower according to the performance of the machine running the game. The goal is to keep the game frame rate constant, while adjusting the rendered frame rate in real-time. This keeps the game flow moving at a constant rate regardless of how fast the game outputs to the screen. In multiplayer environments this technique is essential to prevent CPU caused lag.


Pseudo code of how the game control class works is as follows://call process game to check frame counts

//check for time to do a game frame//increment frame count//we need to update our total frames passed//check to see if we should run the server or not

//if so, run the server function//call current game function

//check for time to draw//increment render count//call render function


Game Object Data// Contains data relevant to the current game in progress. class CgameObject public:

////////////////Simple Access Functions///////////////////////////////Flag Functions//////////////////////////////////////////////Constructor/Destructor//////////////////////////////////Update Functions//////////////////////////

private:u32 mGameStatus; //holds server/client information

vector<Cplayer*>mPlayers; //our player lists32 mClientID; //ID of the client's players32 mClientIndex; //index into player vector of client

s32 mClientConnected; //true or false depending if client is connected to server

u32 mMatchTime; //current number of frames since match started

u32 mFlags; //type of game (time based, etc), and other flags

vector<Sspawn> mSpawnPoints; //spawn points are stored in the server only

vector<C3dObject*> mLevelObjs; //contains pointers to all 3d objects so we can

//destroy them at the end of the levelCgrid mGrid; // Storage for the grid, its cells,

plus any embedded// representations of objects within cells

CneonBatch mBatch; // Batch used to generate neon trails, and to provide

// neon streams to each of the characters

u32 mQuadBatch; // Handle to quad batch used to render our game quads

list<SneonInfo> mNeons; // List of neons to maintain

SneonQuad * mQuadsToDraw; // Container of neon quads to render out

friend s32 EmptyPlayers(CgameObject * gObj); //allow our friend to clear our players

friend s32 InitRandomPlayers(CgameObject * obj, u32 players); //so we can call NEW on players

friend s32 ClientCreatePlayerList(PserverJoin * sJ); // so we can call new

friend void ServerSendPlayerList(PplayerJoin * pPJ); // so we can call new


friend s32 LoadLevel(CgameObject * gObj, char * file); //so we can load the level

//Chassis infostruct Schassis

u32 mLevel; //chassis’ levelchar mName[MAX_STRING]; //name of chassischar mDescription[LONG_STRING]; //chassis descriptionu32 mArmor; //amount of armor on chassisu32 mTurnAngle; //turn angle of chassisu32 mShieldSlots; //number of shield slotsu32 mEngineSlots; //number of engine slotsu32 mFluxDriveSlots; //number of flux drive slotsu32 mNeonSlots; //number of neon slotsu32 mID; //id of chassischar mModel[MAX_STRING]; //model to use with chassis

//Shield infostruct Sshield

u32 mLevel; //shield’s levelchar mName[MAX_STRING]; //name of shieldu32 mSlots; //slots required to use shieldu32 mMaxCharge; //maximum shield amountf32 mChargeRate; //charge rate of shieldu32 mID; //id of the shield

//Engine Infostruct Sengine

u32 mLevel; //engine’s levelchar mName[MAX_STRING]; //name of engineu32 mSlots; //number of slots required to

use engineu32 mSpeed; //speed the engine gives

u32 mID; //id of engine

//Flux Drive infostruct SfluxDrive

u32 mLevel; //flux drive’s enginechar mName[MAX_STRING]; //name of flux driveu32 mSlots; //number of slots required to

use driveu32 mMaxCharge; //maximum boost amountu32 mUsageCost; //boost usage costf32 mDrainRate; //drain rate of boostf32 mChargeRate; //charge rate of boostu32 mSpeedBoost; //amount to inc speed when boostingu32 mID; //id of flux drive

//Neon infostruct Sneon

u32 mLevel; //neon’s levelchar mName[MAX_STRING]; //name of neonu32 mSlots; //slots required for neonu32 mDamage; //damage the neon does on

collision


u32 mDuration; //duration the neon train exists

u32 mID; //id of neon

//Stores all data relevant to the upgradeable componentsclass Ccomponentsprivate:

vector<Schassis> mChassisVector; //stores the list of chassis types

vector<Sshield> mShieldVector; //stores the list of shield types

vector<Sengine> mEngineVector; //stores the list of engine types

vector<SfluxDrive> mFluxDriveVector; //stores the list of flux drive types

vector<Sneon> mNeonVector; //stores the list of neon types

//Stores all data relevant to the character datastruct Scharacter

char mName[MAX_STRING]; //player's namechar mDescription[LONG_STRING]; //description of playeru32 mChassisID; //chassis to useu32 mShieldID; //shield to useu32 mEngineID; //engine to useu32 mFluxDriveID; //flux drive to useu32 mNeonID; //neon to useSu8Color mColor; //color of trails32 mID; //character's IDs32 mCustom; //is it a custom

character

//level datastruct Slevel

char mName[MAX_STRING]; //name of the levelchar mDescription[LONG_STRING]; //level descriptionchar mObstacles[MAX_STRING]; //name of file that

contains obstacle listchar mDataFile[MAX_STRING]; //name of file

containing model list

//stores all of the level informationclass Clevels

vector<Slevel> mLevels; //contains list of all levels

//holds data on given game typestruct SgameProperties

//////////If using a server, we fill the following out////////////char mLevelName[MAX_STRING]; //name of level to loadu32 mMaxPlayers; //maximum amount of players for the rounds32 mAIs; //true to always keep max with AIs.. false

to not include AIs32 mTimeLimit; //amount of seconds a round should take ..

-1 for infinite


//////////If the following is in regard to the client//////////////

u32 mCharacterID; //which character in the character list was chosen

//Contains all player specific informationclass Cplayerpublic://///////////////Simple Access Functions////////////////////////////////Flag Functions///////////////////////////////////////////////Update Functions//////////////////////////protected:

u32 mPlayerStatus; // (dead, link dead, etc)f32 mSpeed; //Holds the unaltered speed of the player

in m/sf32 mBoostSpeedBonus; //Holds the unaltered boost bonus of

the playerf32 mSpeedPerFrame; //distance to travel per framef32 mBoostPerFrame; //distance to travel per framef32 mArmor; //Holds current armor amount on vektoru32 mArmorMax; //Max amount of armor you can haveu32 mShieldMax; //Holds the maximum amount shields

can charge tof32 mShield; //Holds current charge of shieldf32 mShieldRecharge; //charge per frame of shieldsu32 mBoostMax; //Holds the maximum amount of boost

that can be rechargedf32 mBoost; //Current amount of boost availableu32 mBoostUsageCost; //Amount required to boostf32 mBoostRecharge; //recharge per frame on boostf32 mBoostDrain; //drain per frame on boostf32 mNeonDamage; //damage the neon causesf32 mNeonDuration; //duration of the neonf32 mTurnRadius; //per frame in radians (set using degrees)f32 mTurnRadiusActual; //actual turn radius in radiansf32 mBoostTurnRadius; //amount to turn on a boostf32 mBoostTurnRadiusActual; //actual amount that the turn is

(not per frame)D3DXVECTOR3 mLocation; //stores the current location of the

vektorD3DXVECTOR3 mDirection; //stores the current direction of the

vektorf32 mYInc; //amount of displacement in the y to

travel/framef32 mYDest; //destination of movements32 mPlayerID; //server ID given to players32 mCharacterID; //which character is playing..Su8Color mColor; //stores the color of the vektoru32 mFlags; //stores player flags (player boosting,

turning, etc)//Tail RefC3dObject * m3dObj; //3d object associated with the

playerCneonStream mStream; // Means by which player emits neons


Server General

The server is created when the game is in single player mode or when the a multiplayer mode is created. It must be activated using the mServerActive variable inside of the game control object. Once the server is flagged as active, the function pointed to by mServerFunc is called every game loop. This function must be called before the client update so that all incoming packets can be processed.

SeverInit() is always the first function used by the mServerFunc. This function must open that socket that all clients (including the host) will connect on. Then, the function must setup the game in accordance with the game mode selected. The primary functionality needed is to ensure that AI players don’t start before the host player in a single player game. This is unimportant during multiplayer games.

The server handles the game using the game object. The player class automatically updates location, direction, and base statistics, so the server is only necessary as a means to send state changes in a player. A state change occurs when the player changes direction and when a player boosts.

Client General

The client connects to the server, receives player data, and updates the local player’s information on the server. That is its primary function. It does not take into account the game mode selected outside of choosing the IP address it connects with. Once a client receives all necessary game data (level, players, etc), it simply lets the players update themselves using their internal methods. When the client receives an update from the server, it simply changes player data to match what the server sent it.

Game Modes

Varying game moves are handled by simple calls initialization functions from the menu system. Since the game runs on a client/server model in single player and in multiplayer, the only difference between the different game modes is in their setup. For instance, Instant Action initializes the game to run on a time with a certain amount of AI opponents. It also sets the server to call a statistics screen upon completion of the game based upon the mode selected. The in game processes do not change at all.

The way initialization works is by changing the mGameFunc pointer inside of the game control object to point to the correct initialization function (using the standard of InitGAMEMODE()). The game mode function should then setup the AI players, if there are any, load the level, and let the game control function know there is a server running. In the case where a client connects to a remote host, then the client receives the level and AI information from the server. The initialize routine in this case simply starts the client using ClientInit().

InitInstantAction() - Instantiate the number of AIs as specified by menu- Set game clock to time specified by menu- Load in level specified by menu


InitCircuit() - Select seven of total characters available to compete- Select the arena order for competition- Load in first level

InitDeathMatch() - Instantiate number of AIs as specified by menu- Set game clock to time specified by menu- Load in level specified by menu

The server uses a switch() statement to determine which mode is selected. The end of round function is determine by this switch() statement.

Movement

Movement in the game is handled on a frame-to-frame basis. The speed a vehicle is given in a data file. The speed is then divided by the number of frames per second that the game runs at. A unit vector that represents the direction of the player is multiplied by the speed per frame. The result of this multiplication is then added to the current position of the player to give a new location.

Turning works in much of the same fashion as movement. A turn radius is read in from a data file. The turn radius is divided by the frames per second of the game. This new value represents the amount of degrees to increment the vehicle per frame during a turn. When turning, the current direction of the vector gets is added to the amount to turn per frame, resulting in a new direction vector.


Data Flowa. CD - vs complete installThe game will do a full install from the CD, the CD will not be needed after the game is installed, if it is inserted again, it will show a screen saying play instead of install in the autorun program.

b. save games save/loadA memory manager will be used to improve the speed of the game, as well as to help us find memory leaks.

c. memory managementA file will be saved on the hard drive, this will allow the player to load the features that were unlocked in his previous games, and save the new ones.

d. data storageA file called setup.exe will be created with Inno Setup, this file will be an executable file that will contain the game within the file in a compressed format.The installer will then try to install the game in the following path: “Drive\Program Files\Vektor Space”, and then create icons to access it from the programs menu.


Game Physics / StatsGrid

In the course of a given game, there will be many vehicles, neons, obstacles, and particles in the game world. Most of these objects are able to interact with one another, e.g. in collisions. As their numbers grow large, it becomes impractical to check every object against every other object.

The grid allows the game world to be partitioned into discrete cells. Generally, each cell of the grid will be large enough so that, if a game object is not touching its edges, it will be wholly contained within the cell. In this way, an object will occupy at most four cells at any one time, and for most inter-object interaction need only concern itself with objects in these cells.

In many circumstances, the user figures out which cells they wish to operate on and processes these one by one. An example of this would be figuring out which cells a bounding sphere occupies and testing for collisions against obstacles in each one.

The user may also want to traverse the cells from one point to another in a linear manner, performing some user-defined operation at each step, such as adding and removing collision lines for obstacles. The algorithm for traversal goes as follows:

- Figure out which cell the traversal starts in- Figure out which cell the traversal ends in- If the path is a horizontal or vertical line, iterate across it and quit- Figure out which quadrant the traversal moves through- For each column from the first to just before the last column:

Compute the last row the traversal covers in this column Walk through all the rows in the column Set the last row as the starting row for the next column

- For the last column, walk from the first row to the final cell

Neons

Each vektor has a neon stream associated with it, which manages the details of updating and emitting the neons as the vektor moves. A central batch is responsible for distributing neons out to each stream.

Each stream has several parameters associated with it: neon capacity, stiffness, energy loss, and emit rate. A stream is built up out of several links, each of which contains a position, a velocity, and distances between the previous and next links in the stream.


When a vektor moves, it gives its new position to the stream. The first link in the stream changes according to this position. For each of the following links up to the capacity of the stream, forces between the links are computed. These forces are based on spring mechanics, and utilize the stream stiffness and the displacements between links in their computation.

Once a link’s forces are computed, they are applied to the link’s velocity, which is then dampened by energy loss. The velocity, in turn, is applied to the link’s position. The end result is that the stream behaves like a string, curving as it follows a vektor’s movement.

Links are added to the stream at regular intervals, and once the stream is full, a neon will be emitted each time a link is added. A link begins with zero velocity and coincident with the position of the first link in the stream, and gradually widens out as the vektor moves. No force is applied on, or received from, this first link.

When the stream has exceeded capacity, the position of the final link becomes fixed, and forces are neither applied to nor received from the link. When one more link is added to the stream, the final link is discharged from the stream, and its position and that of the link before it (which is now fixed), are used to build a neon in its place. These positions are used to traverse the grid, both to add the neon to and remove the neon from cells for collision.

Collision

Vektor-vektor

Each vektor has three collision spheres used to approximate the shape of its model, which are generated at load time by the graphics engine. In wide vektors, all three of these will be front spheres, whereas longer vektors will have one front sphere and two back spheres.

Because these spheres are of uniform radius and the centers are collinear, an enclosing sphere can be generated with a center matching that of the middle sphere, and a radius three times that of the known radii. Similarly, the same may be done with the other vektors. In this way, it is possible to trivially reject collisions between two vektors whose enclosing spheres do not intersect.

If two vektors pass this rejection test, actual collision testing must be done on the vektors. This involves a brute-force test of each vektor’s sphere against each sphere of the other vektor, amounting to nine total tests. If any of these tests succeed, the vektors are considered to have collided. If this is so,


damage is distributed between the vektors in such a way that at least one vektor is destroyed.

Vektor-neon / vektor-obstacle

For purposes of collision, neons and obstacles may both be treated identically. Both are stored as lines across one or more cells in the grid, and to test for collision, the user must test for intersection between this line segment and the vektor’s front sphere or spheres. Non-front spheres are not considered, as the vektor will only collide with neons or obstacles if it is moving forward toward them.

If a vektor collides with an obstacle, it is instantly destroyed. If it collides with a neon, it takes damage proportional to the lifetime of the neon, where the neon has a base damage assigned to it; a neon with more time remaining will deal more damage. When a neon is collided with, it is destroyed immediately.

Particles

Particles are used extensively in the game. A particle is essentially a triangle or quad, of either a textured or diffuse flavor, that behaves in a way consistent with similar particles with which it is clustered, and which can typically be rendered as a batch as a result.

The graphics system contains caches that can be used to cluster particles into a batch and render them out. However, many particles contain transparency information, and thus the graphics system cannot rely on depth information to display particles in the proper order. As a result, only the display mechanics of particles is handled by the graphics system; the remainder of the work must be processed beforehand.

In order to facilitate proper ordering, some constraints must be imposed on the particles. Neons are a good example of this. Neons are always perpendicular to the XZ-plane, so they never tilt. Also, since neons are destroyed when vektors crash through them, there will never be instances where neons overlap. As a result, neons may be definitely sorted for a given camera view, and then passed from front to back to a particle cache. An example of the characteristic for a neon-sorting algorithm, given a camera orientation and a set of culled neons, is:

- Project orientation onto XZ-plane (ignore y component)- Project first neon onto XZ-plane (becomes y-less line segment)- Project second neon onto XZ-plane (becomes y-less line segment)


- For both endpoints of the first segment, cast a ray (using the projected orientation) and check whether it hits the second segment at a time > 0; if so, the first segment is in front of the second segment

- Do the same process with the second segment, only cast the ray backwards toward the first segment; if it hits at a time > 0, the first segment is behind the second segment

- Otherwise, the segments are “equal” (note that this does not mean parallel, but only that one segment, and thus neon quad, does not occlude the other)

In addition to neons, particles are used for special effects, including breaking neons, sparks emitted by a vektor’s stream, and some shadows. Each particle type is handled similarly to neons: motion, placement, and sorting occurs in the game logic, and then they are passed in sorted order to a particle cache, from which the graphics engine will render them at the appropriate time.


Artificial IntelligenceThe AI system is set up so that every AI character is an independent Bot. This

makes it easier on the player, who doesn’t have to work against all the AI at once, and it also makes it better for multiplayer if the design calls for an AI character to be inserted into a game already in play. The Bots are also made to resemble a regular player. The only difference between a game player and a Bot is that player input is from a keyboard, while AI input comes from an algorithm run by the server.

The main problem the AI will encounter is safely maneuvering a vehicle from one side of the arena to another, avoiding walls, vektors, and neon trails. The next hardest task will be getting the bots to intelligently pick a location to move. Hopefully the decision process will be different for each bot, giving the impression of unique personalities to the user. The last major part of the AI will deal with reactionary and emergency measures. Chances are good that the bots will often encounter dead ends they were not expecting, and they should have a somewhat reasonable response to these situations.

Pathing

For perfect pathing, the AI would be able to search through every possible route the bot could take and choose the best one to get to its target. Unfortunately, the size, complexity and the dynamic nature of the neon trails, makes this method slow and involved. So instead of searching through a list of choices, the AI will respond to nearby objects. There are mainly three different types of objects in the game the AI needs to deal with, other players, neon trails, and wall.

Each kind of object will get its own weighting scheme, and the AI will choose the most urgent object for pathing. Urgency is determined by distance, and the weights change the distance by a given factor. Therefore, to make an AI character avoid walls at all costs, its wall weight would be make less than zero, thus scaling the distance down and making the close wall more urgent.

The weights also mean that each AI character can have its own weighting scheme, and thus have each AI can have different reactions even though they all use the same algorithm.

Destination Selection

Each Bot will have four weights associated with it:

- Wall Weight- Vektor Weight


- Neon Weight- Neon Strength Weight

As mentioned above, weights alter the distance of an object, and therefore the urgency to respond to it. Wall Weight and Vektor Weight are very straight forward, the distance of a wall or vektor is multiplied by their respective weight to determine urgency. Neons work a little bit differently because they cause less damage than the other objects, and they can vary greatly in the amount of damage they do.

Neon Strength Weight will determine the minimum strength of the neon that the AI will check. This will let an AI with high amounts of shielding to ignore some neons while letting a Bot avoid all walls if needed. Neon Weight will be combined with distance and also the strength of the neon being checked to determine its urgency. Neon Strength Weight will be also be scaled by the current shielding of the Bot, so it will be more careful when it is hurt.

If a weight is negative, distance will become negative and the AI system will interpret this to mean it is dealing with an attractive rather than a repulsive object. The Bot will aim for a small distance in front of the given object. With a Vektor, this means the front of the object is determined by its direction. For a neon or a wall, the front is determined by the direction of the Bot, and the farthest endpoint of the line segment that is being checked. Negative weights for walls and neons will probably result in unwanted behavior from a Bot so these are not recommended.

Emergency Response

It is extremely likely that the AI will find itself suddenly cutoff by one of its opponents or will suddenly find a wall in its path. The way out of this is to have the AI boost when an object is too close. The closeness is determined by the speed of the Bot and its bounding spheres. Since distance is already being scaled by the weights, the distance from which a Bot feels the need to boost is already being scaled appropriately.

A Bot could theoretically turn and boost out of all problems and be no fun to play against. To stop the AI from being incredibly hard and very inhuman, certain stoppers will be placed on its reaction time. There will be waiting period placed on how often it can turn, how often it can boost, and how long it should do each. Right now, these amounts are universal, but may go to a Bot-by-Bot basis to increase dissimilarity and further conform to the design of a given Bot.


Graphics EngineMain Graphics Object:Description: Our main Graphics Object, Contains all the Information, Model, Objects, textures. On which the game graphics engine requires to run. It also manages the game textures, models, and rendering.

- ClassMember Variables:mHinstance; //Handle to a window instancemWindow; //Handle of application windowmWindowRect; //Window Rect calculated by windows so the

borders dont //cover our viewmWindowStyle; //Window Style depending on window or fullscreen modemWindowStyleEx; //Window extended stylesmNumBackBuffers; //Number of back buffers used in applicationmFullScreen; //full screen or windowed modemDeviceContext; //Handle to device context of applicationmD3dObject; //Main D3D COM ObjectmD3dDevice; //Main D3D DevicemAdapterName //Name of adapter installed in pcmAdapterCaps; //Capabilities of our video cardmFlags; //Main D3d Object flagsmOffscreenHeight; //Height of our offscreen surfacemOffscreenWidth; //Width of our offscreen surfacemOffscreenTexture; //Offscreen texture used for rendering our

entire scene to a //texturemOffscreenSurf //Pointer to a offscreen surfacemOffscreenRenderToSurf;mQuadBuffer; // Vertex buffer used to store quad verticesmNumFacesDrawn;mCurrentFullScreenDisplayMode; //Display Mode currently being

used when //in full screen modemCurrentWindowedDisplayMode; //Display Mode currently being used

when //in windowed modemDesktopDisplayMode; //Desktops display modemDisplayModes //Available Display ModesmValidFullScreenModes;mValidWindowedModes;mTotalTexturesLoaded; //number of textures loaded at one given pointmTextures; //Game Texturesm2dGraphics;

m3dBkg;s32 mTotalModelsLoaded; //number of models loaded at a given pointm3dModels; //Game 3d Modelsm3dObjects; //List of 3d Object in our gamemQuads;mQuadStore; // Storage for reusable quads mNumQuadBatches, mNumFreeQuadBatches;


mCursor;mGameFont; //Game FontScapsInfo mCaps;mCanBumpMap;mWantToBumpMap;mCameraScripts; //List of Camera ScriptsmCameras;

- Functions:INTIALIZATION AND TERMINATION FUNCTIONS: Init: Creates our D3D Main object, reading from a file called Graphics.cfg in which we can add more options later on:

///////////////////////////// GRAPHICS.CFG ////////////////////////////////////////// SUGGESTED RESOLUTIONS ///////////Res0Width = 640Res0Height = 480

Res1Width = 800Res1Height = 600 Res2Width = 1024Res2Height = 768

Res3Width = 1280Res3Height = 960

///////// REFRESH RATE & FORMAT FOR FULL SCREEN ////////////RefreshRate = 60ColorDepth = 32

//////// OTHER INITIALIZATION PARAMS //////////FullScreen = 0CurrentFullScreen = 1CurrentWindowed = 0NumbackBuffers = 0

////////////////////////////// END OF GRAPHICS.CFG //////////////////////////

//Name :InitD3D//Input :Handle to our app instance, and the window procedure//Output:true if success , false otherwise (very important to

check)//Desc :Initializes all of our d3d stuff (i,e creates device.

window , etc)s32 InitD3D(HINSTANCE, WNDPROC);

Term: This would release everything that was created at Initialization , and will also release any textures, models , or object that were not properly freed by the users.


//Name :TermD3D//Input :none//Output:true if success , false otherwise//Desc :frees all of memory used by our main d3d objects32 TermD3D();

ACCESS FUNCTIONS: these are just functions that gives us access on some of the member variables of our main d3d class.

//Name: GetWindowHandle//Input:none//Output:Handle to our window handle//Desc:returns our game's Window handle

HWND GetWindowHandle();

//Name :GetCurrentDisplayMode//Input :Structure that would be filled witht the

display mode//Output:Error code (true if success , false if failure)//Desc :Retrieves the Current Display mode used by the

games32 GetCurrentDisplayMode(D3DDISPLAYMODE * displayMode);

//Name :GetDevice//Input :Gets the device created by our d3d object//Output:NONE//Desc :pointer to d3dDevice

inline IDirect3DDevice8* GetDevice();

//Name: GetCanBumpMap//Input: NONE //Output:True if our device can handle bumpmapping , false

otherwise//Desc :tell us if our device can handle bumpmapping

inline s32 GetCanBumpMap();

//Name :GetGameFont//Input: none//Output :ref to a D3DFONT class//Desc: returns a ref to our game's font

CD3DFont & GetGameFont();

//Name: GetNumFacesDrawn//Input: none//Output: Number of faces drawn after a render loop//Desc: Calculates how many faces were drawn in a game’s

render loopDWORD GetNumFacesDrawn();

Textures:


Description: Textures are hold in a structure that contains all pertinent information about them.

- Format: PNG format- Off Screen Textures: There are a limited amount of these textures that will

be use to render view ports, the TV screen and other overlaid 3d objects- Management: Textures will be managed through our Main D3d 3d object-- Structures

struct Stexture{mPath[]; //path where our file can be foundmName[]; //name of our texturemType; //(i.e. Base, Bump)mNumMipmaps; //num of mipmaps createdmUseColorKey; //does it use color keyingmColorKey; //RGB components of color keymImageInfo; //basic info about our imagemTexture; //pointer to direct 3d texture classmShared; //Number of models that are sharing this //texture};

- Functions: The functions needed for texture deal with texture management and interaction of textures and targets. (i.e. Models, 2d Graphics)//Name: LoadTexture//Input: name of texture to load, type of list it belongs to (i.e menu list ), Number of mipmaps to be created//Output: true if success, failure other wise//Desc: Loads a texture into video memory or system memory and adds it to our list so we can manage it

s32 LoadTexture(const char * path,const char * name, s32 listType, s32 type , s32 numMipmaps);

//Name: LoadTexture (OVERLOADED FUNCTION)//Input: name of texture to load, type of list it belongs to (i.e. e_Menu ), Number of mipmaps to be created ,does this texture use a color key, Color key value//Output: true if success, failure other wise

//Desc: Loads a texture into video memory or system memory and adds it to our list so we can manage it

s32 LoadTexture(const char * path,const char * name, s32 listType, s32 type , s32 numMipmaps, u8 useColorKey, Su8Color colorKey);

//Name: UnloadTexture//Input: name of texture to unload, list it belongs to

(i.e e_Menu)//Output: true if success, failure otherwise//Desc: frees a memory from memory deleting from our list too, anything associated with this texture is invalid,: after this function has been called


s32 UnloadTexture(const char * name , s32 listType);

//Name: SearchTexture//Input: name of texture to unload, list it belongs to (i.e. e_Menu), texture structure that will be filled//Output: True if texture was found, false otherwise//Desc: looks for a desired texture in one of our

texture listss32 SearchTexture(const char * name , s32 listType, Stexture **

outTexture);

//Name :LoadTexturesFromFile//Input: name of the file that contains the textures to load, list the texture will belong to (i.e. e_Menu)//Output:True if success , False otherwise//Desc: Loads all the textures that are specified on a given file and adds them to appropriate list

s32 LoadTexturesFromFile(const char * fileName , s32 listType);

Models:Description:

- Format: Microsoft (.X) format.- Management: This would be also managed by our D3dMain Object- Structuresstruct Smodel{mName[]; //Name of our modelmMesh; //Our mesh objectmMaterials; //Materials for our modelmTextureToUse; //tells us what textures to usemAdjacency; //specifies the three neighbors for each face in the mesh.mNumMaterials; //Number of materialsmTextures[]; //Textures Associated with this modelmTextureNames[][];mUnload; //Tells us if we need to unload a model};

- Functions: The functions needed for Managing model, and their interaction with other with 3D objects.

The Most important part about our models is to load the right models at the right time, and make sure that there are no duplicates in memory.So by reading models from a file that lists them, I check each one and make sure that they are not already loaded. And that also will take care of the textures associated with them. (The function that takes care of all of this is LoadModelsFromFile()).

//Name :LoadModel//Input: path where the model is with respect to the game

main directory, // Name of model to load


//Output:True if success, False otherwise//Desc: Loads our model and puts it in our model list

s32 LoadModel(const char * path, const char * name);

//Name :UnloadModelTextures//Input :pointer to a model //Output: True if success, False otherwise//Desc: Disassociates the textures from a model and if other models do not share them, it frees them

s32 UnloadModelTextures(Smodel * model);

//Name :UnloadModel//Input: name of model to unload//Output: True if success, False otherwise//Desc: Unloads a model given its name

s32 UnloadModel(const char * name);

//Name :UnloadAllModels//Input :a flag that tells it to unload only the models that have been flag if flag is true//Output: True if Success, False Otherwise//Desc: Unloads all models currently loaded if flag is false, and the marked models if flag is true

s32 UnloadAllModels(u8 useFlag = FALSE);

//Name: LoadModelsFromFile//Input : name of the file to load the models from//Output:True if Success, False Otherwise//Desc : Reads the models that need to be loaded from a

file s32 LoadModelsFromFile(const char * fileName);

//Name :SearchModel//Input :name of model to search , address of Pointer to a model that will point at found model//Output:True if model is found, False Otherwise//Desc: Looks up a model in our model list and fill out the input pointer to point to it

s32 SearchModel(const char * name, Smodel ** model);

//NOTE: This Function should only be used to set off screen textures to a model

//Name:SetModelTexture//Input: model name, type of texture (i.e. e_Base), Pointer to a d3d texture interface//Output: True if Success, False Otherwise


//Desc: Sets the texture of a model (only good for setting off screen textures)

s32 SetModelTexture(const char * model Name, s32 texture Type ,LPDIRECT3DTEXTURE8 texture);

Base Classes:Description: This is a base class, which will have basic functionality, and several virtual functions that later on 2d graphics, and Game strings can inherit and take advantage of.IMPORTANT: All of our 2d interface and menus coordinates are from Zero to One. This way our 2d Graphics will be resolution independent.

(0,0)

(1,1)

- ClassClass 2dbaseClass{mDepth; //tells us the depth of our base classmRect; //base class rect (determines position and

dimension)mActive; //is the graphic currently active}

- Functions: Most of the function will be pure virtual functions and the derived classes will have to implement them.

Non Virtual Functions://Name :GetActive//Input :NONE//Output:true if the graphic is active , false otherwise//Desc :returns the active state of a 2d graphic

inline virtual u8 GetActive();

//Name :SetActive//Input :state to be set//Output:true if success, false otherwise//Desc :sets the acive state of a 2d graphic

inline virtual s32 SetActive(u8 active);

//Name :SetDimension//Input ::width of 2dGraphic (0.0 - 1.0), height of 2d

graphic (0.0 - 1.0)


//Output:true if success,false otherwise//Desc :Set the width and height

inline virtual s32 SetDimension(f32 fractionX, f32 fractionY);

//Name :GetDimension//Input :width of 2dGraphic (0.0 - 1.0), height of 2d

graphic (0.0 - 1.0)//Output:true if success , false otherwise//Desc :gets the dimensions of a 2d graphic

inline virtual s32 GetDimension(f32 * fractionX, f32 * fractionY);

//Name :SetPosition//Input : X and Y positions (0 to 1.0)//Output:true if success , false otherwise//Desc :sets the position

inline virtual s32 SetPosition (f32 fractionX, f32 fractionY);

//Name :Move//Input :offset to add to our current position along the

X and Y axis repectively//Output:true if success , false otherwise//Desc :Adds the offsets given to our current base

class positioninline virtual s32 Move(f32 fractionX, f32 fractionY);

//Name :GetPosition//Input :position x of 2dgraphic (0.0 - 1.0) , position y of 2d graphic (0.0 - 1.0)//Output:true if succes , false otherwise//Desc :gets the position on the screen of a 2d graphic

inline virtual s32 GetPosition (f32 * fractionX, f32 * fractionY);

//Name :GetDepth//Input :NONE//Output:depht of 2dgraphic//Desc :Returns the depth of a 2d graphic

inline virtual f32 GetDepht();

//Name :SetDepth//Input :depth to be set//Output:true if success , false otherwise//Desc :set the depth

inline virtual s32 SetDepth(f32 depth);

//Name: RectInRect//Input: rect to be checked against our base class rect//Output: true if the rect intersect with our base class

rect, false otherwise//Desc: determines if a given rect intersects with our

base class rectinline virtual s32 RectInRect(SfRect const * rect);

//Name: PointInRect


//Input: point to be checked against our base class rect//Output: true if the point is inside base class rect, false

otherwise//Desc: determines if a given point is inside our base

class rectinline virtual s32 PointInRect(SfPoint const * point);

Virtual Functions: These are function that needs to be implemented for derived classes.

//Name: Draw//Input: NONE//Output: NONE//Desc: Empty pure virtual function

inline virtual s32 Draw() = 0;

Text Strings:Description: This class is how we manage all the strings that are drawn in the game. (Menu string, Interface Strings…)

- Types: there are 2 Types of Strings, Interface Strings and Menu Strings.

- Class: Member Variables.Class CgameString{mD3dMain; //Pointer to our Maind3d objectmType; //type of string (i.e. Menu)mScaleX; //Scaling factor along the XmScaleY; //Scaling factor along the YmViewPortPosX; //Position X of string in our viewportmViewPortPosY; //Position Y of string in our viewportmWidthHeightRatio; //WidthHeightRatiomString[]; //String that we want to displaymColor; //Color of our string};

Functions: Our game string function gives us control of what we can do with our game string (i.e. Change color, Pos, etc)

//Name: SetPosition//Input: position in the x (0-1), position in the y (0-1)//Output: True if success , False otherwise//Desc: Sets the position of our game string

s32 SetPosition(f32 positionX , f32 positionY);

//Name: SetDimension//Input: dimension along the x (0-1), dimension along the

y (0-1)//Output: True if success, False otherwise//Desc: Sets the dimension of our game string

s32 SetDimension(f32 dimensionX, f32 dimensionY);


//Name: SetDepth//Input: depht to be set, flag that tell us if we want to

sort our GameStrings//Output: True if Success, False Otherwise//Desc :It sets the depth of our

s32 SetDepth(f32 depth,u8 doSort = TRUE);

//Name: SetColor//Input: rgb values to set our new color//Output: True if Success, False otherwise//Desc: Sets the color of a game string

s32 SetColor(u8 r,u8 g ,u8 b);

//Name :GetColor//Input :(out) ptr to color struct//Output:True if Success, False otherwise//Desc :Fills out the in parameter with the color of

our game strings32 GetColor(Su8Color * color);

//Name: SetAlpha//Input: alpha to be set (0-255)//Output: True if Success, False otherwise//Desc: Sets the alpha (transparency of the string)

s32 SetAlpha(u8 alpha);

//Name: GetAlpha//Input: NONE//Output: alpha value of our game string//Desc: Returns the alpha (Transparency of our Game

string)u8 GetAlpha();

//Name: GetWidth//Input: char to be measured, (out) Width of character//Output: True if success, False otherwise//Desc: Gets the width of a given char

s32 GetWidth (char Char, f32 & fWidth);

//Name: GetScaleX//Input :(out) Scale X to be filled by function//Output: True if success, False otherwise//Desc: Gets the Scale along the x of the game string

s32 GetScaleX (f32 & fScaleX);

//Name: GetScaleY//Input :(out) Scale Y to be filled by function//Output: True if success, False otherwise//Desc: Gets the Scale along the Y of the game string

s32 GetScaleY (f32 & fScaleY);


//Name: SetString//Input: Var arg (JUST LIKE PRINTF ())//Output: True if success, False otherwise//Desc: Sets the string of our game string

s32 SetString(const char * format,...);

//Name: GetString//Input: NONE //Output: pointer to our game string //Desc: Returns a pointer to the string contained in our

game stringconst char * GetString();

//Name: Draw//Input: NONE//Output: True if success, false otherwise//Desc: Send our String data to the D3D Pipeline

s32 Draw();

//Name: Move//Input :offset along the x, offset along the y//Output: True if success, False otherwise//Desc: Moves a Game String by a given offset

s32 Move(f32 offsetX , f32 offsetY);

3D Objects:Description: This is the main class that represents objects in our world; every 3d object that is drawn in the game is of this type. And its member functions allow manipulating the different aspects of the 3d object (Position, Direction, etc)

- Types: There are 3 types of 3d objects in our game. Static Object: used for Objects that don’t move. (i.e. Pillars, Obstacles)Moving Objects: Used for vehicles and other moving objects in our game.Menu Objects: Used for the 3d part of our menus.

Class:

class 3dObject{mD3dMain; //our main d3d objectmDevice; //used to draw stuffmType; //type of our 3d object(static, moving)mTiltAngle; //Angles of rotationmAngleY;mAngleX;mAngleZ;mReferenceDirection;//Current direction of our 3d ObjectmDirection; //Current direction of our 3d ObjectmPosition; //Current Location of our 3d objectmScaleFactor; //Current Scale factor of our 3d objectmTranslate; //Translation of our objectmScale; //do we want our object to be big or small or normal


mRotateX; //rotation of our 3d ObjectmRotateY;mRotateZ;mFinalRotate; //Multiplication of our combined rotation matricesmFinalTransform; //Multiplication of our matrices abovemBoxMin,mBoxMax; //Bounding Box for our Object used for frustum culling

//figure out how to do it with a bounding spheremUntransformedSphere;mTransformedSphere;mUntransformedCollisionSpheres[];mSpherePosVectorMag[];mTransformedCollisionSpheres[];mFlags; //Flags that would tell us stuff about our objectmModel; //copy of model associated with this object//meshes to draw our bounding and collision bodiesmBoundingSphere;mBoundingBox;mCollisionSpheresMesh[];}

- Functions:

//Name :Init3dObject//Input: Main d3d object, type of 3d object (i.e. static, ), model to be //associated with object , position of 3dobject,// Direction of 3d object, and Scaling factor //Output: True if success, false otherwise//Desc :Initializes a 3d object with the given

parameters

s32 Init3dObject(Cd3dMain * d3dMain,s32 type, const char * modelName,D3DXVECTOR3 * pos, D3DXVECTOR3 * dir,D3DXVECTOR3 * scale);

//Name: Term3dObject//Input: NONE//Output: True if success, False otherwise//Desc: Frees and deinitializes any memory allocated in

Inits32 Term3dObject();

//Name: Draw//Input: NONE//Output: True is success, False otherwise//Desc: Calls the other overloaded Draw function with its internal //transformation mtx

s32 Draw();

//Name :Draw//Input: Ptr to a Transformation mtx//Output: True if success, False otherwise


//Desc: Sends our 3d object to the d3d pipeline given a //transformation mtx

s32 Draw(D3DXMATRIX * transform);

//Name: Update//Input: NONE//Output: True if success, False otherwise//Desc: Updates our 3d object if needed, (i.e Updates

pos, loc, rot etc)s32 Update();

//Name: Tilt//Input: a f32 specifying an angle//Output: True if success, False otherwise//Desc: Tilts our 3d object around the z axis

s32 Tilt(f32 angle);

//Name :RotateX//Input :a f32 specifying an angle//Output:True if success, False otherwise//Desc: rotates our 3d object around the X-axis

s32 RotateX(f32 angle);

//Name :RotateY//Input :a f32 specifying an angle//Output:True if success, False otherwise//Desc: rotates our 3d object around the Y-axis

s32 RotateY(f32 angle);

//Name :RotateZ//Input: a f32 specifying an angle//Output:True if success, False otherwise//Desc: rotates our 3d object around the Z-axis

s32 RotateZ(f32 angle);

//Name :SetPosition//Input: A d3dxvector struct//Output:True if success, False otherwise//Desc: Sets the postion of our 3d object

s32 SetPosition(D3DXVECTOR3 pos);

//Name: GetPosition//Input: NONE//Output:a D3dxvector struct//Desc: Returns the current postion of our 3d object

D3DXVECTOR3 GetPosition();

//Name: SetDirection//Input: A D3dxvector struct//Output: True if success, false otherwise//Desc: Set the direction of our 3d object

s32 SetDirection(D3DXVECTOR3 dir);

//Name: GetDirection//Input: NONE//Output: A d3dxvector struct


//Desc: Returns the current direction of our 3d objectD3DXVECTOR3 GetDirection();

//Name: SetScale//Input: A d3dxvector//Output: True if success, false otherwise//Desc: Sets the scale of our 3d object

s32 SetScale(D3DXVECTOR3 scale);

//Name: GetScale//Input: NONE //Output: a d3dxvector//Desc: Return the current scale factor of our 3d object

D3DXVECTOR3 GetScale();

//Name: SetActive//Input: a u8 indicating if the object is to be active or

not//Output: True if success, False otherwise//Desc: Set our 3d object active or inactive depending on //the parameter passed

s32 SetActive(u8);

//Name: GetActive//Input: NONE//Output: a u8 indicating if our 3d object is active or not//Desc: Return the active state of our 3d object

u8 GetActive();

//Name: GetCollisionSphere//Input: enum indicating what spehre to get (i.e e_Front),(out)Ptr to //sphere struct//Output: True if success, False otherwise//Desc: Fills our out parameter with collision sphere

requesteds32 GetCollisionSphere(EcollisionSpheres index, Ssphere * sphere);

//Name: HasOneFrontSphere//Input: NONE//Output: s32 that tells us if this 3d object has a front

sphere or not//Desc: Returns True if object has exactly one front

sphere , false othewises32 HasOneFrontSphere();

//Name: FrustumTest//Input: ptr to an array of 6 planes indicating our

frustum//Output: True if object is in or partially in frustum//Desc: Tests our 3d object against a frustum and

returns the results32 FrustumTest(D3DXPLANE * Frustum);

//Name: FindCollisionSpheres//Input: NONE//Output: True if success, False otherwise//Desc: Finds the collision sphere for this 3d object


s32 FindCollisionSpheres();

2D Graphics:Description: 2d Graphics is the main object that draws and manipulates the menus and the game interface. Its member’s functions manipulate its interaction with the texture associated with certain 2d graphic as well as the position, Transparency and others.IMPORTANT: The coordinate system used for the 2d graphics is inherited from 2dgraphics Base class.

- Types: There are 2 types of 2d graphics in our game, Menu and Interface.- Class

class C2dGraphic{mD3dMain; //used to get lots of the functionality needed to draw stuffmDevice;mType; //what kind of graphic this is (i.e menu, interface )mResolutionWidth;mResolutionHeight;mVisible; //is the graphic currently visible or do we need to clip itmRGBA[]; //color and alpha channel of uur primitive//Info to keep about a 2d graphic that is going to be loaded from a filemName[MAX_STRING];mFileName[MAX_STRING];mNumTextures;mUseTextureColor;mUseTextureAlpha;mScale; //tells us dimensions of the graphicmTranslate; //will tell us where the graphic is on the screenmFinalTransform; //concatenation of all transformations matricesmDiffuse[]; // Color in acceptable form to be passed to the vertex buffermTexCoord[][]; // Texture coordinates for our quadmVertex[];mQuad;mTextures[e_NumTextureTypes];}

- Functions: The following function manage the behavior of our 2d graphics:

//Name: SetDepth//Input: depth to be set, flag that tells it if the graphic is to be sorted once //the depth is set//Output: true if success false otherwise//Desc: Set the depth of a 2d graphic and sorts it if

neededs32 SetDepth(f32 depth,u8 doSort = TRUE);

//Name: SetDimension


//Input: width of 2dGraphic (0.0 - 1.0), height of 2d graphic (0.0 - 1.0)

//Output: true if success, false otherwise//Desc: sets the dimensions of a 2d graphic

s32 SetDimension(f32 dimensionX, f32 dimensionY);

//Name: SetPosition//Input: position x of 2dgraphic (0.0 - 1.0) , position y of 2dgraphic (0.0 //- //1.0)//Output: true if success, false otherwise//Desc: set the position on the screen of a 2d graphic

s32 SetPosition (f32 positionX, f32 positionY);

//Name :Move//Input :offset to add to our current position along the X and Y axis //respectively//Output: true if success, false otherwise//Desc: Adds the offsets given to our current 2d graphic

positions32 Move(f32 offsetX, f32 offsetY);

//Name :SetDiffuse//Input: vertex to set the diffuse, RGB components to be

set//Output: true if success, false otherwise//Desc: sets the diffuse (Color) of a vertex in a

2dgraphic s32 SetDiffuse(s32 vertex, u8 r, u8 g, u8 b);

//Name :SetDiffuse (OVERLOADED)//Input :RGB components//Output:true if success, false otherwise//Desc :set the diffuse (color) of the ENTIRE 2d

graphics32 SetDiffuse(u8 r, u8 g, u8 b);

//Name :UseTextureTranparency//Input: flag telling us if this 2dgraphic is to use the texture transparency //or the primitive one//Output: true if success, false otherwise//Desc: set the behaviour of a 2d graphic with respect to what alpha to use //(texture or primitive)

s32 UseTextureTranparency(u8 choice);

//Name: SetTransparency//Input: transparency to be set//Output: true, if success false otherwise//Desc: set the transparency of the primitive alpha

s32 SetTransparency(u8 alpha);

//Name: SetTextureCoord//Input: type of coordinates to set ( i.e base, bumpl, etc), array containig //the textures coordinates to be set//Output: true if success, false otherwise


//Desc: sets the texture coordinates of a given 2d graphic

s32 SetTextureCoord(s32 typeOfCoord,D3DXVECTOR2 * textureCoords);

//Name: MoveTextureCoord//Input: type of coordinates to move (i.e base, bump, etc), increment that //the coordinates are to be moved in both U and V axis//Output: true if success, false otherwise//Desc: moves the texture coordinates of a 2d graphic by the given //amount

s32 MoveTextureCoord(s32 typeOfCoord,f32 incU,f32 incV);

//Name :SetTexture//Input: name of the texture to be set, texture type( i.e base, bump , etc), //list that the texture belongs to (i.e. menu list)//Output: true if success, false otherwise//Desc: associates a texture with one of the 2d graphic

texture pointerss32 SetTexture(char const * names, s32 textureType ,s32 listType);

Camera:- Description: Our camera is what we use in the game to determine what is

to be rendered. We have 3 Cameras: 1) Menu Camera. 2) TV Screen Camera 3) Player Camera, these cameras are in our main d3d object

- Class

class Ccamera{mZoom; // Current zoom level of cameramFieldOfView, mAspect; // Field of view; aspect ratiomNearDist, mFarDist; // Distance to near plane; distance to far plane

mScriptTimer;

mPosTimer, mDirTimer; // Timers used to interpolate camera position, DirectionmZoomTimer; // Timer used to interpolate zoommFOVTimer, mAspectTimer; // Timers used to interpolate field of view and aspectmPosition, mDirection; // Current position and direction of cameramUpVector; // Relative up vectormView, mProjection; // View and projection matricesmtPos[]; // Interpolation range for positionsmtQuat[]; // Interpolation range for directionsmtObjectDir; // Object direction to be mapped into target orientationmtZoom[]; // Interpolation range for zooms mtFieldOfView[], mtAspect[];// Interpolation ranges for field of view, aspect ratiomInterpolation; // Method used to interpolate pointsmFlags; // Current status of camera


mScriptFrom, mScriptTo; // tells us what way point we are coming and going to //respectively

mScript; // Current script associated with cameramScriptName[]; //Name of the script associated with the camera};

- Functions: The functions for the camera give control about its position, direction, field of view and other member variables , There are also Script managing functions that interact with a already associated Script. Those are the following.

//Name :isScriptDone//Input: NONE//Output:True if script is done , False otherwise//Desc: Tells us if the current script associated with the camera is //done or not

u8 isScriptDone(void);

//Name: SetScript//Input: Ptr to a camera script//Output: True if success, False otherwise//Desc: Associates a script to a camera

s32 SetScript(CcameraScript * script);

//Name: updateScript//Input: NONE//Output:True if success, False otherwise//Desc: Updates the current camera script

s32 updateScript(void);

//Name :stopScript//Input: NONE//Output: True if success, False otherwise//Desc: Stops Current playing script

s32 stopScript (void);

//Name :playScript//Input: f64 indicating how much time it should take to get to the next //waypoint in the script//Output: True if success, false otherwise//Desc: Plays a Script , advances it to the next way

point if already playings32 playScript (f64 time = 0.01f);

//Name :pauseScript//Input: NONE//Output: True if success, False otherwise.//Desc: Pauses current associated script

s32 pauseScript (void);

//Name :rewindScript//Input: NONE//Output: True if success , false otherwise//Desc: returns current script to its beginning


s32 rewindScript (void);

Camera Script:- Description: Camera Scripts are used to set our camera to a given path.

The path is made out of waypoints and is read from a file

- Structure:

struct CcameraScript{mVersion; // Version of ScriptName[]; // Scripts namemWaypoints; // Waypoints to run through with script}

- Functions:

//Name :load//Input :string containing the name of the file that contains the script //waypoints//Output: True if Success , False otherwise//Desc: Loads a script from a given file

s32 load (char const * fileName);


User InterfaceUI System

General

The UI system functions as a subset of the graphics engine. It is modeled for the purposes of a fully general graphical user interface, and it depends on the graphics system and a math utility library only. It abstracts the implementation of numerous reusable GUI components, and in doing so provides greater flexibility to the user.

Chains

Chains are the glue that holds the UI together. Functionality is provided to create and maintain a set of logically connected set of menus within each chain. A chain contains two sets of menus: active and inactive. Inactive menus are not displayed and have no interaction with the user. Active menus are displayed in a stacked fashion; the menu that is displayed on top of all the others in this stack is considered to be the chain’s top-level menu.

Input to the UI is sent through the chain, and delivered to the components of the top-level menu; if the input gets sent to a menu that is not top-level (e.g. the mouse is clicked outside the current main menu, onto a lower menu), that menu will become the new top-level menu. Input is propagated to all components of the top-level menu, sending multiple events the user may respond to.

For basic purposes, one will only need one active chain. For instance, if the user traverses through the menus one by one, all the menus may be placed into a single chain. The default menu would start out activated, and all the other menus would be deactivated. As the user moved from one menu to another, the current menu could be deactivated and the new one activated.

More complex systems may require more than one chain to be active at one time; as a result, the GUI is structured to allow this design. UI components that logically require more than one top-level menu at once (e.g. if data is being exchanged between two menus) are an example of such a system.

Widgets

Widgets are the elements used to build up GUI components. They fall into two categories: menus and menu items. In designing components, the


user will never treat objects as widgets specifically, but there is some structure and functionality common to all widgets that is worth noting.

Every widget has a name assigned to it, which is used to uniquely identify and retrieve the widget within its scope (for a menu, this is within its chain; for a menu item, this is within its menu). Likewise, each widget has a region that defines its location and dimensions with respect to the space it resides in (for a menu, this is the screen; for a menu item, this is a menu). Methods are provided to test whether an object intersects this region.

Each widget is required to contain a background graphic. The user may wish to perform operations on this graphic that are outside the scope of the UI, such as changing the texture or the alpha, and so the user is able to acquire it as needed from the widget. In doing so, the user is expected not to violate other properties of the graphic already maintained by the UI, such as depth and location.

The user may also wish to maintain information particular to a given widget. For instance, one might want to track how many times a button has been pressed. For these purposes, it is possible to allocate a local context. This reserves a section of memory within the widget that may be filled with data, which may in turn be referenced at any point through the widget. It is only possible to specify one local context; allocating a new one will overwrite a prior instance.

Menus

Menus are used to structure GUI components. A menu consists of all the components described in the widget section, as well as any number of menu items that are displayed above it. A menu provides methods to manipulate its position, create and obtain menu items, and activate or deactivate itself.

If formatted messages are being sent to menu items within the menu, it will be necessary to set the menu’s focus to that menu item. One may set the focus to any focusable menu item; once the focus has been set, the user may try to change it to the previous or next focusable item in the menu (where items are ordered according to which order they were created or loaded in).

Menu items

Menu items are the primary unit used to build up GUI components. A menu item consists of all components described in the widget section, as well as a type. Each menu item consists of a number of graphical components and strings that must be configured at setup time, and that may be acquired from the item and manipulated later.


Buttons are the most basic type of menu item, and are minimal in the functionality they provide. Users may set and retrieve a string that is displayed over the button, and are able to provide an empty string if desired.

Sliders are built up out of a slider graphic and a thumb that is moved over it. They provide methods to manipulate the offset of the thumb in the range over which the slider spans. Users provide a starting and ending point for this span, which allows the slider range to be oriented arbitrarily (most often, only horizontal or vertical orientations will be necessary).

Listboxes allow users to place items into a list, where they are displayed row by row. The list may grow to an arbitrary length, but only a fixed number of items are displayed at any one time; the user may scroll up and down through the list to see different parts of the list. Items may be added to or removed from any position within the list. Each item in the listbox is associated with a text string, which is what the user sees. Also, the user may associate a value with each item; the meaning of this item is defined according to the user’s needs. The user may also select individual items or ranges of items; selected items are highlighted using a highlight graphic provided when the listbox is created.

Textboxes allow users to manipulate and display strings of text with some fixed length. Methods are provided to get, set, delete, and select characters or strings at arbitrary offsets into the text string. The textbox may be scrolled to the left and right to display portions of it that are not otherwise visible. When the textbox is created, the user also specifies a cursor and highlight graphic. The cursor can be set to align with a given text character, e.g. when a player is typing a name; if desired, the cursor may be disabled. The highlight is displayed over all selected text.

Event handlers

By default, there is no behavior attached to the UI; if input is sent to it, there will be no response. There are, however, a number of well-defined events that occur when input is sent, and the user may install handlers into a given widget to respond to these.

For menu items, the events are as follows:

Press: The input was a press, e.g. the mouse button was depressed, and the input was located over the menu item

Release: The menu item had previously been pressed, but the input is not a press

ReleaseOutside: The menu item had previously been pressed, but the input was not a press; if the input was located outside the menu item and this handler exists, this is sent instead of Release


Enter: The input just moved into the menu item from outside of itLeave: The input just moved out of the menu item from inside of itMoveInside: The input has moved inside of the menu itemMoveOutside: The input has moved outside of the menu itemDragInside: The menu item had previously been pressed, and the input

has moved inside of the menu item; if this handler does not exist, MoveInside is sent instead

DragOutside: The menu item had previously been pressed, and the input has moved outside of the menu item; if this handler does not exist, MoveOutside is sent instead

GetMessage: A formatted message has been sent to the menu; this is only sent if the menu item is the focus of the menu

FocusSwitch: The menu item has either become or stopped being the focus

Certain menu items have events unique to them:

DragThumb: The user had previously pressed the slider’s thumb, and is now moving

ClickItem: The user pressed over a listbox item

For menus, the following are provided:

Press: No menu items received a Press event of their own, and the input was over the menu

Release: The menu had previously been pressed, but the input is not a press

MoveInside: The input has moved inside of the menuMoveOutside: The input has moved outside of the menu DragInside: The menu had previously been pressed, and the input has

moved inside of the menu; if this handler does not exist, MoveInside is sent instead

DragOutside: The menu had previously been pressed, and the input has moved outside of the menu; if this handler does not exist, MoveOutside is sent instead

TopLevelSwitch: The menu has either become or stopped being the top-level menu of the chain

Activate: The menu has either been activated or deactivated

Each time input is propagated through the chain, the input’s position and press state are updated, and the appropriate events are sent. If a handler exists for a given menu or menu item, it will be called and whatever action the user has specified for it will immediately take effect. In this way, the UI can be designed to support any functionality the user needs for the game.

Input propagation


In order to keep a chain current, input must be continuously propagated to it. Input is retrieved in the form of presses (e.g. mouse, joystick), input location (e.g. cursor location) and formatted messages (e.g. keyboard codes merged with flags attached). The UI is agnostic to the mechanism of input delivery, so it does not depend on a particular device, such as the mouse. Instead, input is processed first and used to fill in an input data structure that is passed to the propagation function.

The propagation algorithm is as follows:

- Get the current input position, and figure out if the input is pressed- Using the input data, figure out which menu is top-level- If this menu has a focus, send any messages we have to the focus- For each item in the menu:

Trap any events unique to the menu item and send them Get the previous state of the input given to the item If the input is within the menu item:

Check for differences in press states If not pressed and we have a press, send Press If pressed and we don’t have a press, send Release Check for differences in movement and “insideness” If we moved and were not inside before, send Enter If we moved and were inside and pressed, send

DragInside If we moved and were inside and not pressed, send

MoveInside Otherwise:

Check for differences in press states If pressed and we don’t have a press, send

ReleaseOutside Check for differences in movement and “outsideness” If we moved and were not outside before, send Leave If we moved and were outside and pressed, send

DragOutside If we moved and were outside and not pressed, send

MoveOutside If we didn’t press a menu item:

Check for difference in menu item’s press states If not pressed and we have a press, send Press If pressed and we don’t have a press, send Release

Check for differences in movement If we moved and were inside and pressed, send

DragInside If we moved and were inside and not pressed, send

MoveInside


If we moved and were outside and pressed, send DragOutside

If we moved and were outside and not pressed, send MoveOutside

Loading

In order to avoid having to manually create all of a chain’s menu and menu item components, there is support for loading GUI components from a file. Once a chain has been instantiated, it may be given a file and all of its internal components will be loaded in and set to their initial state. The UI supports loading from both binary and text files.

Loading cannot be used to install handlers or allocate and load widgets’ local contexts, since these are stored as physical addresses in memory and thus will not remain consistent across game sessions. As a result, the game will install handlers after each chain has been loaded, and any relevant context information can be set likewise or extracted from other configuration/save files.

Binary is provided for loading speed. Components in this format are ordered just as they would be if the chain were being loaded manually in the game; this facilitates error checking and can be used to tell if the user provided a corrupt file. Each section of a binary file starts out with a byte code, which is unique for that particular section: e.g. the file starts out with bcTagEnterCHAIN (defined to be ('C'+'H'+'A'+'I'+'N') * 5), which is used to guarantee that at that particular point the data being loaded is chain data.

Text is provided for ease of editing. The structure of the file is identical to that of the binary format. In lieu of byte codes, the text format uses HTML-style tags. These tags are used to provide flow of control and error-checking in the same way that binary does. The user is free to use whatever indentation and white space scheme they desire in a text file.

The following is an example snippet from a text file:

<CHAIN><ACTIVE>

<MENU>name=MENUtexName=GraphicsModesMenu.pngX=0.0 Y=0.0 W=0.45 H=0.45depth=0.0

<LISTBOX>name=MODEtexName=GraphicsModesListbox.pnghighlightTexName=GraphicsModesHighlight.pngX=0.1 Y=0.1 W=0.8 H=0.4


maxItemsToDisplay=4textWidthToHeight=0.2r=255 g=255 b=255 a=255focusable=1

<ITEM> string=640x480 value=1 selected=1<ITEM> string=800x600 value=2 selected=0<ITEM> string=1024x768 value=3 selected=0<ITEM> string=1280x960 value=4 selected=0

</LISTBOX><BUTTON>

name=CONFIRMtexName=GraphicsModesConfirmButton.pngX=0.1 Y=0.8 W=0.8 H=0.1textWidthToHeight=0.2r=0 g=0 b=0 a=255focusable=0

<STRING> string=CONFIRM</BUTTON><FOCUS> focus=MODE

</MENU></CHAIN>

This file loads a single, active menu into the chain, and adds a listbox and button into the menu. Four items are added to the litbox, the first of which is selected. The button is given a string. The listbox is set as the focus of the menu.

Menu implementation:

Overview:

The menu system contains two layers of functionality: Features, and Specific Implementation. The feature section described above is part of the graphics engine. The specifics of how Vektor Space implements the features of the graphic engine are described as follows.

The menus have an independent control loop from the inner game. This allows you to put the game on hold in a single player game, and to allow the menus to load and unload the inner game, and its models.

The menus are processed into two Chains, this allows different input from the top and bottom half of the menus. The reason for two independent inputs is to allow the menus to have two different sets of menus in focus. The menus associated with the first chain are designed and loaded from menu.txt, and the menus associated with the second chain are included in menu2.txt. The bottom half of the screen is controlled by the first chain. This is the navigational part of the menu system. This controls the input for the users position in the menus and handles the loading and unloading of the actual game.


The second chain controls the top half of the screen. This controls the input for that manipulates the individual menus features. -Example; the user selects keyboard configuration in the first chain. This switches the menu into a screen where the top half of the screen now lists the previously assigned keys, and the second chain accepts the player’s input for changing the configuration. While the bottom half of the screen allows the player to back out of the menu.

The navigational menus in Vektor Space are categorized into four main areas: Instant Action, Vektor Circuit, Death Match, and Option. Listed below is a brief layout overview followed by some implementation features.

Instant Action:This is designed to allow the player to jump into a single match, in this

mode they can test their custom characters, our select a pre-made character, and battle against player defined course and number of AI bots. The menus associated with Instant action are as follows:

1. Character Select first menu in character selection, this allows the player to select a pre-made character or go to the custom character menu.

1a.Custom Character optional menu- allows the player to select from a list custom character or create a new one.

2.Course Selection this screen allows the player to select a course to play on and set the number of opponents.

2a.Garage optional menu- if the player selected a custom character there will be a link from the Course selection to the characters inventory called the garage.

2b.Shop system optional menu- selectable from the garage, allows the player to purchase new vehicles and parts, which can be equipped in the garage.

Vektor Circuit:This is the main single player mode of the Vektor Space. Circuit mode is

designed as a set of eight races, where the player competes against seven AI players. The menus take the player into the game and in between each race it is possible to allow the player to visit their garage and reconfigure their vehicle, and to visit the shop to purchase new items. The menus associated with Vektor Circuit are as follows:



2.Enter Race this screen gives the player a chance to visit the garage or gives them a moment to prepare before entering the first race in the circuit.


2a.Garage optional menu- if the player selected a custom character there will be a link from the Enter race screen to the characters inventory called the garage.


Death Match:Death Match is the only multiplayer mode in Vektor space. It allows the

player to create or join a multiplayer game. They can use a custom or pre-made character. The mode continues for a specified time, points, or until the host of the game leaves.



2.Course Selection this screen allows the player to select a course to play on and set the number of opponents (human & AI).

2a.Garage optional menu- if the player selected a custom character there will be a link from the Course selection to the characters inventory called the garage.


3a.Host allows the player to host a game on the Internet or LAN3b.Join allows the player to join a game on the Internet or LAN4.Chat players can converse before a game begins.

Options:Options are a set of menus where the player can customize controls, sound, and

video options.

1.Keyboard Config menu where the player can specify their in-game controls2.Video Options allows the player to set graphical options to make the game

play or look better3.Audio Options allows the player to set SFX volume, and music volume

Structures:The menus are linked together with a the following structures:

Menu Structure this contains information about which menu layer the player is in. It contains a pointer to the selected player structure


Player Structure holds information about the player that is passed into single and multiplayer games. The player structure contains a pointer to the player’s inventory.

Inventory Structure contains a list of all objects that can be purchased or equipped in the game. There are two instances of this in the menu. The players owned items, and the items left for sale in the shop.

Buttons:Below is an example of the functions needed for each button

//Main Menu - Instant Action Button (example not functional code)// Call this function when the button is releasedInstant_ Action_Button((CmenuItem::OnPressed)PressInstant);// Call this function when the button is releasedInstant_

Action_Button((CmenuItem::OnRelease)ReleaseInstant);// Call this function when the button is highlighted

Instant_ Action_Button((CmenuItem::OnEnter)EnterMenuButton);// Call this function when the button is unhighlighted

Instant_ Action_Button((CmenuItem::OnLeave)ExitMenuButton);

3D ObjectsThis is how to implement 3D objects in the menu system// activate the camera for the menus (example not functional code)GetCamera(MENU_CAMERA)->SetActive(true);// Set the camera positionGetCamera(MENU_CAMERA->SetPositon(D3DXVECTOR3);// load a 3D modelCreate3dObject(Menu_List, name, 3x D3DXVECTOR3);// Associating the 3D objects with a textureGetOffScreenTexture(OFFSCREEN_SURFACE);// map the texture onto a 2D objectMenu2DGraphic->SetTexture(e_Base,Menu->OffscreenTex);// Menu2DGraphic->SetPositon(Position);


MultiplayerOverview:Multiplayer will be achieved using TCP/IP stream connection; up to 8 simultaneous players will be supported in a client/server environment. Since the game will be fast paced, it’s important to have a fast connection with a low ping to the server (something lower than 50ms would be ideal). For that reason the game is better suited to be played on a LAN, although a fast broadband connection like DSL with a low ping also be ok.

Packet Loss:Stream connections are used instead of UDP connections since this game is mostly a LAN game, and the advantage of speed that UDP gives is not as noticeable under LAN environments, but it would add more complexity when dealing with packet loss. Therefore no packet loss control is necessary since we are not going to use UDP, and we are guaranteed to get every single packet.

Disconnection:TCP/IP will return a socket error when the connection is lost, so then the server will alert the clients that the player is no longer in the game and will be removed from the player’s list.

Client 1 Client 2

Client 3 Client 4

Client 5 SERVER

Client 7 Client 6

Example of Multiplayer: Seven clients connecting to 1 server, for a total of 8 players.


Structures://The generic packet structuretypedef struct mypacket {

int packettype;//Type of packetint sizeofdata;//Size of the packetchar * data;//Pointer to the packet structure data.

} MYPACKET;

// Class name: CNetworkMemoryManager// Description: This class helps to track down memory leaks and minimizes the OS calls to malloc.class CNetworkMemoryManager{private:

// Variable name: MallocList// Description: STL list of the memory manager listlist<MALLOCDEBUG> MallocList;// Variable name: MallocListCS// Description: Critical Section of the malloc listCRITICAL_SECTION MallocListCS;

public:

// Function name: CNetworkMemoryManager// Description: Constructor of CNetworkMemoryManager class.// Return type: voidCNetworkMemoryManager();

// Function name: MALLOC// Description: Memory manager's version of malloc(), helpful for

finding memory leaks// Return type: void * // Argument: int size// Argument: int lineofcode// Argument: char * strFileNamevoid * MALLOC(int size, int lineofcode, char * strFileName);

// Function name: FREE// Description: memory manager's version of free(), frees any

allocated memory with MALLOC// Return type: void // Argument: void * pointervoid FREE(void * pointer);

// Function name: ProcessMemoryLeaksFile// Description: Creates a debug file with any found memory leaks,

to help track them down// Return type: void // Argument: char * filevoid ProcessMemoryLeaksFile(char * file);

// Function name: ~CNetworkMemoryManager// Description: Destructor for the Memory manager, frees any

memory left to free to avoid leaks// Return type: void~CNetworkMemoryManager();

};


//This Server class, encapsulates the functionality for the serverclass CNetworkServer : public CNetworkMemoryManager{

private:

//member variables// Variable name: m_serversocket// Description : the server socketSOCKET m_serversocket;// Variable name: m_servernetworkidcount// Description: IDs countint m_servernetworkidcount;// Variable name: m_remotesocket// Description: remote socketsSOCKET m_remotesocket[MAXREMOTECONNECTIONS];// Variable name: m_remotesocketcount// Description: count of remote socketsint m_remotesocketcount;// Variable name: m_servermaxconnections// Description: maximum server connectionsint m_servermaxconnections;// Variable name: ServerPacketsReceivedQueue// Description: STL queue of server received packetsqueue<MYPACKET> ServerPacketsReceivedQueue;// Variable name: ServerPacketsReceivedQueueCS// Description: Critical Section of the server received queueCRITICAL_SECTION ServerPacketsReceivedQueueCS;// Variable name: ServerPacketsToSendQueue// Description: STL queue of the to send packets queuequeue<MYPACKET> ServerPacketsToSendQueue;// Variable name: ServerPacketsToSendQueueCS// Description: Critical Section of the server send packet queueCRITICAL_SECTION ServerPacketsToSendQueueCS;

// Function name: InitializeWinsock// Description: Starts the winsock dll// Return type: bool // Argument: char * errorstringbool InitializeWinsock(char * errorstring);

// Function name: ServerAcceptConnectionsThread// Description: Thread that accepts new connections// Return type: void // Argument: void * datavoid ServerAcceptConnectionsThread(void * data);

// Function name: ServerRemoteSocketThread// Description: Thread that receives data from a remote connection// Return type: void // Argument: void * remotesocketindexvoid ServerRemoteSocketThread(void * remotesocketindex);


public:

// Function name: CNetworkServer// Description: Constructor of server// Return type: voidCNetworkServer();

// Function name: StartServer// Description: Starts the server// Return type: bool // Argument: int port// Argument: int maxconnections// Argument: char * errorstringbool StartServer(int port, int maxconnections, char *

errorstring);

// Function name: Connected// Description: Checks if the server is working// Return type: bool bool Connected();

// Function name: ServerPushPacketsReceivedQueue// Description: push a packet to the packet received queue// Return type: void // Argument: MYPACKET mypacketvoid ServerPushPacketsReceivedQueue(MYPACKET mypacket);

// Function name: ServerPopPacketsReceivedQueue// Description: returns a packet from the received queue and

removes it.// Return type: MYPACKET MYPACKET ServerPopPacketsReceivedQueue();

// Function name: ServertSizeOfPacketsReceivedQueue// Description: returns the number of packets in the packets

received queue// Return type: int int ServertSizeOfPacketsReceivedQueue();

// Function name: ServerIsEmptyPacketsReceivedQueue// Description: Checks if the packets received queue is empty// Return type: bool bool ServerIsEmptyPacketsReceivedQueue();

// Function name: ServerPushPacketsToSendQueue// Description: pushes a packet to the send queue// Return type: void // Argument: MYPACKET mypacketvoid ServerPushPacketsToSendQueue(MYPACKET mypacket);

// Function name: ServerPopPacketsToSendQueue// Description: pops a packet from the send queue and removes it

from it.// Return type: MYPACKET MYPACKET ServerPopPacketsToSendQueue();


// Function name: ServerSizeOfPacketsToSendQueue// Description: number of packets in the tosend queue// Return type: int int ServerSizeOfPacketsToSendQueue();

// Function name : ServerIsEmptyPacketsToSendQueue// Description : checks if the packets to send queue is

empty// Return type: bool bool ServerIsEmptyPacketsToSendQueue();

// Function name: ServerCountActiveConnections// Description: counts the number of connections to the server.// Return type: int int ServerCountActiveConnections();

// Function name: ServerDisconnect// Description: Disconnects the server// Return type: void void ServerDisconnect();

// Function name: ~CNetworkServer// Description: Destructor of CNetworkServer class, frees any left

packets and disconnects everybody.// Return type: void~CNetworkServer();

};

//The client class encapsulates the functionality to createa client connectionclass CNetworkClient : public CNetworkMemoryManager{

private:

// ************************// * Member Variables// ************************// Variable name : m_clientsocket// Description : The client socketSOCKET m_clientsocket;// Variable name : ClientPacketsReceivedQueue// Description : STL queue of the packets receivedqueue<MYPACKET> ClientPacketsReceivedQueue;// Variable name : ClientPacketsReceivedQueueCS// Description : Critical Section of the packets receivedCRITICAL_SECTION ClientPacketsReceivedQueueCS;

// Variable name : ClientPacketsToSendQueue// Description : STL queue of the packets to sendqueue<MYPACKET> ClientPacketsToSendQueue;// Variable name : ClientPacketsToSendQueueCS


// Description : Critical Section of the packets to send queue

CRITICAL_SECTION ClientPacketsToSendQueueCS;

// ************************// * Functions// ************************

// Function name: InitializeWinsock// Description: Inits the winsock dll// Return type: bool // Argument: char * errorstringbool InitializeWinsock(char * errorstring);

// Function name: ClientReceiveThread// Description: Thread that receives data from server and pushes

it to the received queue// Return type: void // Argument: void * datavoid ClientReceiveThread(void * data);

public:

// Function name: CNetworkClient// Description: Constructor of CNetworkClient class// Return type: void// Argument: char * strServerIP// Argument: int PortCNetworkClient(char * strServerIP, int Port);

// Function name: ConnectTo// Description: Connects to a server// Return type: bool // Argument: char * serverIP// Argument: int serverport// Argument: char * errorstringbool ConnectTo(char * serverIP, int serverport, char *

errorstring);

// Function name: Connected// Description: returns true if we are connected to the server or

false if we are not.// Return type: bool bool Connected();

// Function name: ClientPushPacketsReceivedQueue// Description: pushes a packet to the received queue// Return type: void // Argument: MYPACKET mypacketvoid ClientPushPacketsReceivedQueue(MYPACKET mypacket);

// Function name: ClientPopPacketsReceivedQueue// Description: // Return type: MYPACKET MYPACKET ClientPopPacketsReceivedQueue();


// Function name: ClientSizeOfPacketsReceivedQueue// Description: returns the amount of packets in the received

queue// Return type: int int ClientSizeOfPacketsReceivedQueue();

// Function name: ClientIsEmptyPacketsReceivedQueue// Description: checks if the received queue is empty// Return type: bool bool ClientIsEmptyPacketsReceivedQueue();

// Function name: ClientPushPacketsToSendQueue// Description: Adds a packet to the send queue// Return type: void // Argument: MYPACKET mypacketvoid ClientPushPacketsToSendQueue(MYPACKET mypacket);

// Function name: ClientPopPacketsToSendQueue// Description: returns the packet and removes it from the queue// Return type: MYPACKET MYPACKET ClientPopPacketsToSendQueue();

// Function name: ClientSizeOfPacketsToSendQueue// Description: returns the amount of packets in the tosend queue// Return type: int int ClientSizeOfPacketsToSendQueue();

// Function name: ClientIsEmptyPacketsToSendQueue// Description: Checks if the packets to send queue is empty// Return type: bool bool ClientIsEmptyPacketsToSendQueue();

// Function name: ClientDisconnect// Description: Disconnects the socket from the server// Return type: void void ClientDisconnect();

// Function name: ~CNetworkClient// Description: Network Client Destructor, cleans up any left over

packets and disconnects// Return type: void~CNetworkClient();

};

class CNetworkMemoryManager{private:

// ************************// * Member Variables// ************************

// Variable name : MallocList


// Description : STL list of the memory manager listlist<MALLOCDEBUG> MallocList;// Variable name : MallocListCS// Description : Critical Section of the malloc listCRITICAL_SECTION MallocListCS;

public:// ************************// * Functions// ************************

// Function name: CNetworkMemoryManager// Description: Constructor of CNetworkMemoryManager class.// Return type: voidCNetworkMemoryManager();

// Function name: MALLOC// Description: Memory manager's version of malloc(), helpful for

finding memory leaks// Return type: void * // Argument: int size// Argument: int lineofcode// Argument: char * strFileNamevoid * MALLOC(int size, int lineofcode, char * strFileName);

// Function name: FREE// Description: memory manager's version of free(), frees any

allocated memory with MALLOC// Return type: void // Argument : void * pointervoid FREE(void * pointer);

// Function name: ProcessMemoryLeaksFile// Description: Creates a debug file with any found memory leaks,

to help track them down// Return type: void // Argument: char * filevoid ProcessMemoryLeaksFile(char * file);

// Function name: ~CNetworkMemoryManager// Description: Destructor for the Memory manager, frees any

memory left to free to avoid leaks// Return type: void~CNetworkMemoryManager();

};

// Class name: CNetworkServer// Description: Encapsulates all the functionality from WinSock to create a server.class CNetworkServer : public CNetworkMemoryManager{

private:


// Variable name: m_serversocket


// Description : the server socketSOCKET m_serversocket;// Variable name: m_servernetworkidcount// Description: IDs countint m_servernetworkidcount;// Variable name: m_remotesocket// Description : remote socketsSOCKET m_remotesocket[MAXREMOTECONNECTIONS];// Variable name: m_remotesocketcount// Description: count of remote socketsint m_remotesocketcount;// Variable name: m_servermaxconnections// Description: maximum server connectionsint m_servermaxconnections;// Variable name: ServerPacketsReceivedQueue// Description: STL queue of server received packetsqueue<MYPACKET> ServerPacketsReceivedQueue;// Variable name: ServerPacketsReceivedQueueCS// Description: Critical Section of the server received queueCRITICAL_SECTION ServerPacketsReceivedQueueCS;// Variable name: ServerPacketsToSendQueue// Description: STL queue of the to send packets queuequeue<MYPACKET> ServerPacketsToSendQueue;// Variable name: ServerPacketsToSendQueueCS// Description: Critical Section of the server send packet queueCRITICAL_SECTION ServerPacketsToSendQueueCS;

// ************************// * Functions// ************************

// Function name: InitializeWinsock// Description: Starts the winsock dll// Return type: bool // Argument : char * errorstringbool InitializeWinsock(char * errorstring);

// Function name: ServerAcceptConnectionsThread// Description: Thread that accepts new connections// Return type: void // Argument: void * datavoid ServerAcceptConnectionsThread(void * data);

// Function name: ServerRemoteSocketThread// Description: Thread that receives data from a remote connection// Return type: void // Argument: void * remotesocketindexvoid ServerRemoteSocketThread(void * remotesocketindex);

public:

// Function name: CNetworkServer// Description: Constructor of server// Return type: void


CNetworkServer();

// Function name: StartServer// Description: Starts the server// Return type: bool // Argument: int port// Argument: int maxconnections// Argument: char * errorstringbool StartServer(int port, int maxconnections, char *

errorstring);

// Function name: Connected// Description: Checks if the server is working// Return type: bool bool Connected();

// Function name: ServerPushPacketsReceivedQueue// Description: push a packet to the packet received queue// Return type: void // Argument: MYPACKET mypacketvoid ServerPushPacketsReceivedQueue(MYPACKET mypacket);

// Function name: ServerPopPacketsReceivedQueue// Description: returns a packet from the received queue and

removes it.// Return type: MYPACKET MYPACKET ServerPopPacketsReceivedQueue();

// Function name: ServertSizeOfPacketsReceivedQueue// Description: returns the number of packets in the packets

received queue// Return type: int int ServertSizeOfPacketsReceivedQueue();

// Function name: ServerIsEmptyPacketsReceivedQueue// Description: Checks if the packets received queue is empty// Return type: bool bool ServerIsEmptyPacketsReceivedQueue();

// Function name: ServerPushPacketsToSendQueue// Description: pushes a packet to the send queue// Return type: void // Argument: MYPACKET mypacketvoid ServerPushPacketsToSendQueue(MYPACKET mypacket);

// Function name: ServerPopPacketsToSendQueue// Description: pops a packet from the send queue and removes it

from it.// Return type: MYPACKET MYPACKET ServerPopPacketsToSendQueue();

// Function name: ServerSizeOfPacketsToSendQueue// Description: number of packets in the tosend queue// Return type: int int ServerSizeOfPacketsToSendQueue();

// Function name: ServerIsEmptyPacketsToSendQueue


// Description: checks if the packets to send queue is empty// Return type: bool bool ServerIsEmptyPacketsToSendQueue();

// Function name: ServerCountActiveConnections// Description: counts the number of connections to the server.// Return type: int int ServerCountActiveConnections();

// Function name: ServerSendPacketsToClients// Description: Sends packets to clients// Return type: void // Argument: voidvoid nt_ServerSendPacketsToClients(void);

// Function name: ServerDisconnect// Description: Disconnects the server// Return type: void void ServerDisconnect();

// Function name: ~CNetworkServer// Description: Destructor of CNetworkServer class, frees any left

packets and disconnects everybody.// Return type: void~CNetworkServer();

};

// Class name: CNetworkClient// Description: Information needed by the Listenerclass CNetworkClient : public CNetworkMemoryManager{

private:


// Variable name: m_clientsocket// Description: The client socketSOCKET m_clientsocket;// Variable name: ClientPacketsReceivedQueue// Description: STL queue of the packets receivedqueue<MYPACKET> ClientPacketsReceivedQueue;// Variable name: ClientPacketsReceivedQueueCS// Description: Critical Section of the packets receivedCRITICAL_SECTION ClientPacketsReceivedQueueCS;

// Variable name: ClientPacketsToSendQueue// Description: STL queue of the packets to sendqueue<MYPACKET> ClientPacketsToSendQueue;// Variable name: ClientPacketsToSendQueueCS// Description: Critical Section of the packets to send queue


CRITICAL_SECTION ClientPacketsToSendQueueCS;

// ************************// * Functions// ************************

// Function name: InitializeWinsock// Description: Inits the winsock dll// Return type: bool // Argument: char * errorstringbool InitializeWinsock(char * errorstring);

// Function name: ClientReceiveThread// Description: Thread that receives data from server and pushes

it to the received queue// Return type: void // Argument: void * datavoid ClientReceiveThread(void * data);

public:

// Function name: CNetworkClient// Description: Constructor of CNetworkClient class// Return type: void// Argument: char * strServerIP// Argument: int PortCNetworkClient(char * strServerIP, int Port);

// Function name: ConnectTo// Description: Connects to a server// Return type: bool // Argument: char * serverIP// Argument: int serverport// Argument: char * errorstringbool ConnectTo(char * serverIP, int serverport, char *

errorstring);

// Function name: Connected// Description: returns true if we are connected to the server or

false if we are not.// Return type: bool bool Connected();

// Function name: ClientPushPacketsReceivedQueue// Description: pushes a packet to the received queue// Return type: void // Argument: MYPACKET mypacketvoid ClientPushPacketsReceivedQueue(MYPACKET mypacket);

// Function name: ClientPopPacketsReceivedQueue// Description: // Return type: MYPACKET MYPACKET ClientPopPacketsReceivedQueue();

// Function name: ClientSizeOfPacketsReceivedQueue// Description: returns the amount of packets in the received

queue


// Return type: int int ClientSizeOfPacketsReceivedQueue();

// Function name: ClientIsEmptyPacketsReceivedQueue// Description: checks if the received queue is empty// Return type: bool bool ClientIsEmptyPacketsReceivedQueue();

// Function name: ClientPushPacketsToSendQueue// Description: Adds a packet to the send queue// Return type: void // Argument: MYPACKET mypacketvoid ClientPushPacketsToSendQueue(MYPACKET mypacket);

// Function name: ClientPopPacketsToSendQueue// Description: returns the packet and removes it from the queue// Return type: MYPACKET MYPACKET ClientPopPacketsToSendQueue();

// Function name: ClientSizeOfPacketsToSendQueue// Description: returns the amount of packets in the tosend queue// Return type: int int ClientSizeOfPacketsToSendQueue();

// Function name: ClientIsEmptyPacketsToSendQueue// Description: Checks if the packets to send queue is empty// Return type: bool bool ClientIsEmptyPacketsToSendQueue();

// Function name: ClientSendPacketsToServer// Description: Send the packets to the server // Return type: void // Argument: voidvoid ClientSendPacketsToServer(void);

// Function name: ClientDisconnect// Description: Disconnects the socket from the server// Return type: void void ClientDisconnect();

// Function name: ~CNetworkClient// Description: Network Client Destructor, cleans up any left over

packets and disconnects// Return type: void~CNetworkClient();

};


InputInput will be done using Direct Input 8.1

There will be direct support for keyboard, mouse, joystick and steering wheels.A class called Cinput will encapsulate everything we need to use Direct Input. Force feedback also will be supported in the Joystick thru DirectInput.

Enum:// Enum name: eKeyState // Description: enumerated values for the different key statesenum eKeyState {

eKeyStateReleased = 0,eKeyStatePressed,eKeyStateJustPressed,eKeyStateJustReleased,eKeyStateError

};

Structures:// Structure name: KeyStroke// Description: info passed by a keystroketypedef struct KeyStroke{

char Key[KEYSTROKE_SIZE];int numberofkeys;

} KeyStroke;// Structure name: JoystickData// Description: joystick information needed to choose a joysticktypedef struct _JoystickData{

GUID guid;char strJoystickName[256];

}JoystickData;

// Structure name: JoystickCaps// Description: Joystick capabilitiestypedef struct _JoystickCaps{

int numofbuttons;bool XAxisSupport; //X Axis Supportbool YAxisSupport; //Y Axis Supportbool ZAxisSupport; //Z Axis Support

bool rXAxisSupport; //Rotation in X Axis Supportbool rYAxisSupport; //Rotation in Y Axis Supportbool rZAxisSupport; //Rotation in Z Axis Supportbool Slider;int SliderCount;bool PointOfView; //A point of view controller DIDFT_POV int PointOfViewCount;


bool ForceFeedbackActuator; //An object that contains a force-feedback actuator. In other words, forces can be applied to this object.

bool ForceFeedbackTrigger; //An object that can be used to trigger force-feedback effects. } JoystickCaps;

// Structure name : FFEFFECT// Description: encapsulates info needed for a force feedback effecttypedef struct ffeffect{

LPDIRECTINPUTEFFECT m_pDIeffect;char name[STRSIZE];

}FFEFFECT;

Class:// Class name: Cinput // Description: Encapsulates all functionality for Keyboard, Mouse and Joysticks.class Cinput{private:

// *****************// PRIVATE VARIABLES// *****************

// Variable name: m_pDI// Description: Direct Input ObjectLPDIRECTINPUT8 m_pDI;// Variable name: m_pKeyboard// Description: Keyboard Direct Input interfaceLPDIRECTINPUTDEVICE8 m_pKeyboard;// Variable name: m_pMouse// Description: Mouse Direct Input interfaceLPDIRECTINPUTDEVICE8 m_pMouse;// Variable name: m_pJoystick// Description: Joystick Direct Input interfaceLPDIRECTINPUTDEVICE8 m_pJoystick;// Variable name: m_hWnd// Description: window handle to our applicationHWND m_hWnd;// Variable name: m_hInstance// Description: HINSTANCE of the programHINSTANCE m_hInstance;// Variable name: m_KeyQueue// Description: STL queue with key presses for chatsqueue<KeyStroke> m_KeyQueue;// Variable name: m_eKeyboardStateArray// Description: keyboard keystate arrayenum eKeyState

m_eKeyboardStateArray[DIRECTINPUT_KEYBOARD_ARRAY_SIZE];// Variable name: m_eMouseStateArray// Description: mouse button state arrayenum eKeyState m_eMouseStateArray[DIRECTINPUT_MOUSE_BUTTON_ARRAY];// Variable name: m_eJoystickStateArray


// Description: joystick button state arrayenum eKeyState

m_eJoystickStateArray[DIRECTINPUT_JOYSTICK_BUTTON_ARRAY];// Variable name: m_ptMouse// Description: mouse position pointPOINT m_ptMouse;// Variable name: m_MouseDX// Description: mouse x-axis change of positionint m_MouseDX;// Variable name: m_MouseDY// Description: mouse y axis change of positionint m_MouseDY;// Variable name: m_MouseDZ// Description: mouse wheel change of positionint m_MouseDZ;// Variable name: m_bJoystickFound// Description: true if we have a joystick attachedbool m_bJoystickFound;// Variable name: m_bforcefeedback// Description: true if we have FF supportbool m_bforcefeedback;// Variable name: m_forcefeedbackeffect// Description: list of force feedback effectslist<FFEFFECT> m_forcefeedbackeffect;

// *****************// PRIVATE FUNCTIONS// *****************

// Function name: InitDirectInput// Description: Inits Direct Input Object// Return type: bool // Argument: void

bool InitDirectInput(void);

// Function name: InitDirectInputKeyboard// Description: Inits the direct input keyboard interface// Return type: bool // Argument: void

bool InitDirectInputKeyboard(void);

// Function name: InitDirectInputMouse// Description: Inits the direct input mouse interface// Return type: bool // Argument: void

bool InitDirectInputMouse(void);

// Function name: InitDirectInputJoystick// Description: Inits a joystick specified by its guid// Return type: bool // Argument: GUID guid

bool InitDirectInputJoystick(GUID guid);

// Function name: scan2ascii


// Description: converts from a direct input scan code to ascii, useful for in-game chats// Return type: int // Argument: DWORD scancode// Argument: char * result

int scan2ascii(DWORD scancode, char * result);

// Function name: GetKeyName// Description: Gets the name of the key (used for key config menus)// Return type: void // Argument: int scancode// Argument: char * outbuffer// Argument: int outbuffersize

void GetKeyName(int scancode, char * outbuffer, int outbuffersize);

// Function name: UpdateDirectInputKeyboard// Description: updates the keyboard thru direct input// Return type: bool // Argument: void

bool UpdateDirectInputKeyboard(void);

// Function name: UpdateDirectInputMouse// Description: updates the mouse thru direct input// Return type: bool // Argument: void

bool UpdateDirectInputMouse(void);

// Function name: UpdateDirectInputJoystick// Description: Updates the joystick thru direct input// Return type: bool // Argument: void

bool UpdateDirectInputJoystick(void);

// Function name: GetKeyboardKeyState// Description: gets the state of a keyboard button// Return type: enum eKeyState // Argument: DWORD scancode

enum eKeyState GetKeyboardKeyState(DWORD scancode);

// Function name: GetMouseButtonState// Description: gets the state of a mouse button// Return type: enum eKeyState // Argument: int mousebutton

enum eKeyState GetMouseButtonState(int mousebutton);

// Function name: GetJoystickButtonState// Description: Gets the state of a joystick button// Return type: enum eKeyState // Argument: int joystickbutton

enum eKeyState GetJoystickButtonState(int joystickbutton );

public:// *****************// PUBLIC FUNCTIONS


// *****************

// Function name: Cinput// Description: Input constructor// Return type: void// Argument: HWND hwndCinput(HWND hwnd);

// Function name: UpdateInput// Description: This function updates the input, should be called

every time new input is needed.// Return type: bool // Argument: voidbool UpdateInput(void);

// Function name: GetKeyState// Description: Gets the state of a key, or button in mouse or

joystick// Return type: enum eKeyState // Argument: int keycodeenum eKeyState GetKeyState(int keycode);

// Function name: GetMousePosition// Description: Returns the current position of the mouse// Return type: POINT POINT GetMousePosition();

// Function name: PopChatStringKeyStroke// Description: gets the pressed key from the queue, used for in-

game chatting// Return type: KeyStroke KeyStroke PopChatStringKeyStroke();

// Function name: GetMouseAxisDeltas// Description: Returns the changes of position from the mouse in

dx (x axis), dy(y axis), dz(mouse wheel)// Return type: void // Argument: int &dx// Argument: int &dy// Argument: int &dzvoid GetMouseAxisDeltas(int &dx, int &dy, int &dz);

// Function name: GetJoystickXYZAxisPosition// Description: returns the position of each axis range -1000 to

1000// Return type: void // Argument: int &xaxis// Argument: int &yaxis// Argument: int &zaxisvoid GetJoystickXYZAxisPosition(int &xaxis, int &yaxis, int

&zaxis);

// Function name : GetJoystickCaps// Description: Gets the Information about the features of the

joystick


// Return type: JoystickCaps// Argument: GUID guidJoystickCaps GetJoystickCaps(GUID guid);

// Function name: IsJoystickConnected// Description: returns true if a joystick is connected// Return type: bool bool IsJoystickConnected();

// Function name: FreeDirectInput// Description: Frees every direct input interface// Return type: void // Argument: voidvoid FreeDirectInput(void);

// Function name: PlayFFEffect// Description: plays a force feedback effect on a joystick// Return type: void // Argument: char * strEffectvoid PlayFFEffect(char * strEffect);

// Function name: ~Cinput// Description: Input Destructor, calls FreeDirectInput()// Return type: void~Cinput();

};

// Function name: EnumJoysticksCallback// Description: Enumerates Joysticks// Return type: BOOL CALLBACK // Argument: const DIDEVICEINSTANCE* pdidInstance// Argument: VOID* pContextBOOL CALLBACK EnumJoysticksCallback( const DIDEVICEINSTANCE* pdidInstance, VOID* pContext );

// Function name: EnumObjectsCallback// Description: Enumerates objects// Return type: BOOL CALLBACK // Argument: const DIDEVICEOBJECTINSTANCE* pdidoi// Argument: VOID* pContextBOOL CALLBACK EnumObjectsCallback(const DIDEVICEOBJECTINSTANCE* pdidoi, VOID* pContext );


SoundOverviewThe sound will be done using the fmod library, and there will be a class called Csound encapsulating the functionality we need from fmod. We chose fmod because we can play compressed sounds like MP3 files or Ogg Vorbis files without much impact on the processor, this allow us to not depend on CD audio to play our sound, because that doesn’t lend itself very well for downloading the game over the Internet. And we found this library to be very fast, reliable and free for non-commercial use.

Structures:// Structure name: SOUND3DVECTOR// Description: sound 3d vector structuretypedef struct{float x;float y;float z;} SOUND3DVECTOR;

// Structure name: MYSAMPLE// Description: structure that encapsulates sample informationtypedef struct _MYSAMPLE{

char path[MAX_PATH];FSOUND_SAMPLE * sample;bool b3DSample;int channel;SOUND3DVECTOR position;SOUND3DVECTOR velocity;

}MYSAMPLE;

// Structure name: MYSTREAM// Description: structure that encapsulates stream informationtypedef struct _MYSTREAM{

char path[MAX_PATH];bool bLoadInMemory; //char * data;FSOUND_STREAM * stream;

}MYSTREAM;

// Structure name: LISTENER// Description: Information needed by the Listenertypedef struct Listener{

SOUND3DVECTOR position;SOUND3DVECTOR velocity;float fx;float fy;


float fz;float tx;float ty;float tz;

}LISTENER;

// Class name: Csound// Description: Wrapper class to the functionality in the FMOD library that we will be using.class Csound{private:// Variable name: m_SampleList// Description: linked list of samples

list<MYSAMPLE> m_SampleList;

// Variable name: m_StreamList// Description: linked list of streams

list<MYSTREAM> m_StreamList;

// Variable name: Listener// Description: Listener's position.

LISTENER Listener;

public:

// Function name: Csound// Description: default constructor// Return type: void

Csound();

// Function name: Update// Description: Updates the new 3D positions, should be called after Set3DListenerPos or Set3DSoundPos// Return type: void

void Update();

// Function name: Set3DListenerPos// Description: Sets the new position of the listener in the world for 3D sound// Return type: void // Argument: LISTENER & newlistener

void Set3DListenerPos(LISTENER & newlistener);

// Function name: Set3DSoundPos// Description: Sets the position of the sound object in the world// Return type: void // Argument: SOUND3DVECTOR & pos// Argument: SOUND3DVECTOR & vel

void Set3DSoundPos(SOUND3DVECTOR & pos, SOUND3DVECTOR & vel);

// Function name: Csound// Description: Constructor// Return type: void// Argument: int mixrate// Argument: int maxsoftwarechannels


Csound(int mixrate, int maxsoftwarechannels);

// Function name: LoadSoundSample// Description: Loads a sound sample// Return type: void // Argument: char * file// Argument: bool bLOOP// Argument: bool b3DSound

void LoadSoundSample(char * file, bool bLOOP, bool b3DSound);

// Function name: LoadSoundStream// Description: Loads a sound stream// Return type: void // Argument: char * file// Argument: bool bLOOP// Argument: bool bLoadInMemory

void LoadSoundStream(char * file, bool bLOOP, bool bLoadInMemory);

// Function name: Play// Description: plays a sound// Return type: void // Argument: char * file

void Play(char * file);

// Function name: PlayAll// Description: Plays all sounds// Return type: void

void PlayAll();

// Function name: Stop// Description: stops a sound// Return type: void // Argument: char * file

void Stop(char * file);

// Function name: StopAll// Description: stops all the sounds// Return type: void

void StopAll();

// Function name: Unload// Description: Unloads a sound from memory// Return type: void // Argument: char * file

void Unload(char * file);

// Function name: CleanUp// Description: stops all sounds and unloads them// Return type: void

void CleanUp();

// Function name: ~Csound// Description: Destructor, calls CleanUo// Return type: void

~Csound();};


OptimizationGraphics Frustum Culling is used reduce the number of polygons drawn, and increase the frame rate.

Memory In tight loops we are reusing memory. We also have memory managers that help find memory leaks and decrease calls OS calls to allocate memory.

InstallTo create the installer a compiler called InnoSetup will be used. This compiler uses scripts. To create this script we will use ISTool, this will give us a GUI for for the compiler that allows for easy creation of a install script.

Once the script is compiled we will get an installer that will contain the game compressed in itself, and since everything is contained in one file, we can potentially put this file on the internet or on a cd for easy installation. Some other useful features are the ability to check for supported versions of Windows, free hard drive space, automatic uninstall, icons and registry keys.The registry key set in the setup program will allow us to check when the CD is inserted in the autorun program if the game has been installed already, and if it is it will ask you to play it, without having to re-install it again.When the game is uninstalled the registry key with the path of the installed game will be erased.

The autorun program will also check to see if DirectX 8.1 is installed and if it’s not installed it will ask if you want to install it. In case the game was downloaded from the internet and DirectX 8.1 is not detected the game will ask the user to go to http://www.microsoft.com/directx and open the browser in that address automatically if the user decides to download it.


http://www.microsoft.com/directx

Copy protection

Our game is not a commercial game, and therefore copy protection is not needed.

ToolsOverview:

There are two external tools that will be used in the creation of Vektor Space, the Camera Editor, and the Level Editor.

Camera Editor:This editor is designed to create camera paths and save them to a file that can be

interpreted by the game. The features required are as follows:

Position: (X, Y, Z) -position of the camera in the world with respect to the center of the world located at (0,0,0).

Direction: (X, Y, Z) -direction vector for the orientation of the camera in the world

ID: (id) -identification number of this camera position

Next: (id) -identification number of next camera in list

Time (s) -time in seconds to next waypoint.

Implementation:The camera editor will be created as a separate window. This window will be created

with the same graphics engine as the game. The world model will be loaded into the editor, and the user will be able to navigate the camera to select an optimal position and direction of the camera. After a position is selected the user can specify the time it took to get from the last position to the current position. After a waypoint is created it can be selected again from a list of waypoints and moved as desired. A possible feature of the editor is to play back the waypoints in order to view the camera track. This editor will be created explicitly for the developers and not to be shipped with Vektor Space.


This is how to implement 3D objects (example not functional code)// activate the camera for the menusGetCamera(CAMERA)->SetActive(true);// Set the camera positionGetCamera(CAMERA->SetPositon(D3DXVECTOR3);// load a 3D modelCreate3dObject(Menu_List, name, 3x D3DXVECTOR3);// Associating the 3D objects with a textureGetOffScreenTexture(OFFSCREEN_SURFACE);// map the texture onto a 2D objectMenu2DGraphic->SetTexture(e_Base,Camera->OffscreenTex);// Menu2DGraphic->SetPositon(Position);

How the user controls the camera (example not functional code)// using the input system we receive keyboard messages if GetInputObject()->GetKeyState(DIK_FORWARD or DIK_BACKWARD) //move the camera forward or backwardsGetCamera(CAMERA)->SetPositon(D3DXVECTOR3);if GetInputObject()->GetKeyState(DIK_LEFT or DIK_RIGHT) // rotate the cameraGetCamera(CAMERA)->Rotate X, Y, Z

ButtonsAs described above the camera system can have several buttons read in from file and assigned functions that can handle the users input.

File IOThe Camera editor will have the ability to load in a file of waypoints and save a file in the same format. This will be handled with fileOpen(), fscanf(), fprintf() functions.


Schedule

First Semester Schedule (GAM400):

DATE TASKSeptember 27,2002 Pre-Engine ProofOctober 4,2002 Engine ProofOctober 11,2002 Pre-First PlayableOctober 18,2002 1st PlayableOctober 25,2002 AlphaNovember 4,2002 Focus groupsNovember 12,2002 (IGF submission) Beta(single player)

Second Semester Schedule (GAM450):

DATE TASKJan 10-24,2003 - Garage

- Multiplayer: Menus, Spectator Mode, Last Man Standing.- Video Options Menu: Changing resolutions on the menus.

Jan 24-Feb 7,2003 - Sound, Input and Options Menus.- Interface Tweaks.

Feb 7-21,2003 - Special Effects from GEN450 class.- Chat: Lobby and in-game.- Art: Levels.

Feb 21-28,2003 - Version to show at GDC ready.- Update Website.- Art: Misc. Stuff. - ALPHA

March 6-8,2003 - Show game at the Game Developer’s Conference.

March 10-28,2003 - Marketing Materials, testing. - BETA

March 28-April 11,2003 - More debugging.- Create installer.- Update website.- Finalize everything, - GOLD


Date post:	22-Apr-2018
Category:	Documents
Upload:	danghuong
View:	220 times
Download:	1 times

“VEKTOR SPACE” - DigiPen: A Leader in Game ... · Web viewWord Processor: Microsoft’s Word...

Documents