tdd · web viewwith cartoon shading, there are only a few (typically three) shading intensity...

System Chaos: The Adventures of Trellian

Technical Design Document

Polymorphic Productions

Version 1.0 (2/15/2005)

Authors:

Ross Dexter (Technical Director)Malia Guerrero (Producer)

Greg Kohne (Designer)Adam Henderson (Product Manager)

Copyright ©2005 DigiPen (USA) Corporation. All rights reserved.

System Chaos Technical Design Document GAM300Polymorphic Productions Spring 2005

Table of Contents TABLE OF CONTENTS...............................................................................................................................2

PROJECT OVERVIEW................................................................................................................................4

GAME CONCEPT...........................................................................................................................................4TECHNICAL GOALS......................................................................................................................................4TECHNICAL COST OVERVIEW......................................................................................................................4

Staff.........................................................................................................................................................4Technical Costs.......................................................................................................................................4Monthly Cost...........................................................................................................................................5

SYSTEM REQUIREMENTS..............................................................................................................................5TIMELINE AND MILESTONES........................................................................................................................5

Schedule..................................................................................................................................................5RISKS............................................................................................................................................................5EXTERNAL TOOLS........................................................................................................................................6

Microsoft Visual Studio .NET.................................................................................................................63D Studio MAX.......................................................................................................................................6GIMP.......................................................................................................................................................6CVS.........................................................................................................................................................6WorldCraft/Hammer...............................................................................................................................6

INTERNAL TOOL – MAP COMPILER..............................................................................................................7Overview.................................................................................................................................................7Interface..................................................................................................................................................7Benefits / Drawbacks..............................................................................................................................7System Chaos Level File Format............................................................................................................8

GAME INITIALIZATION AND RESOURCE STORAGE......................................................................9

GAME ENTITIES........................................................................................................................................10

GRAPHICS...................................................................................................................................................11

OVERVIEW..................................................................................................................................................11STRUCTURE................................................................................................................................................11ADVANCED GRAPHICS...............................................................................................................................11

GAME PHYSICS.........................................................................................................................................13

MOTION......................................................................................................................................................13SPRINGS......................................................................................................................................................14BUOYANCY.................................................................................................................................................14COLLISION DETECTION..............................................................................................................................14COLLISION RESOLUTION............................................................................................................................14

ARTIFICIAL INTELLIGENCE................................................................................................................16

OVERVIEW..................................................................................................................................................16STATE MACHINES......................................................................................................................................16FLOCKING...................................................................................................................................................16A* PATHFINDING.......................................................................................................................................17

MULTIPLAYER..........................................................................................................................................19

OVERVIEW..................................................................................................................................................19STRUCTURE................................................................................................................................................19

CODE OVERVIEW.....................................................................................................................................22

CODING STANDARDS..................................................................................................................................22

Copyright ©2005 DigiPen (USA) Corporation. All rights reserved. 2


Naming Conventions.............................................................................................................................22Code Documentation............................................................................................................................22Coding Practices...................................................................................................................................23

MAIN GAME LOOP.....................................................................................................................................23Initialize Game......................................................................................................................................25Logic.....................................................................................................................................................25Input......................................................................................................................................................25AI...........................................................................................................................................................25Physics..................................................................................................................................................25Sound.....................................................................................................................................................25Networking............................................................................................................................................25Graphics................................................................................................................................................25Load New Level.....................................................................................................................................25Shutdown Game....................................................................................................................................26

EXTERNAL CODE........................................................................................................................................26DirectX..................................................................................................................................................26FMOD...................................................................................................................................................26

SYSTEM MODULES.....................................................................................................................................26Rendering..............................................................................................................................................26

Window Object..................................................................................................................................................26Direct3D............................................................................................................................................................27VertexBuffer......................................................................................................................................................27IndexBuffer........................................................................................................................................................27

Input......................................................................................................................................................27Audio System.........................................................................................................................................27

GAME OBJECTS..........................................................................................................................................27PhysicsObject........................................................................................................................................28Font.......................................................................................................................................................28Input......................................................................................................................................................29Player....................................................................................................................................................29Enemy....................................................................................................................................................30ElementSource......................................................................................................................................30Element.................................................................................................................................................31GameInfo...............................................................................................................................................31

USER INTERFACE.....................................................................................................................................32

MENUS.......................................................................................................................................................32IN-GAME HUD...........................................................................................................................................32

DIRECTORY STRUCTURE......................................................................................................................33

ART RESOURCES......................................................................................................................................34

APPENDIX...................................................................................................................................................35

GAME SAVING............................................................................................................................................35SCL FILE FORMAT.....................................................................................................................................35Resource Storage Tables............................................................................................................................35



Project Overview

Game Concept

System Chaos: The Adventures of Trellian is a third person action/platformer that will challenge your mental resolution to solve intriguing puzzles and defeat menacing enemies.

Technical Goals

Robust 3d graphics engine – Our 3d graphics engine will be able to render complex scenes both efficiently and with superior visual quality. The engine aims to be fast, freeing up processing power for the other aspects of the game. The engine will also employ vertex shaders to further enhance visual quality

Solid physics – The physics engine will allow us to create interesting, dynamic interactions between the player and the game world. Buoyancy and spring physics will add exciting game-play elements that will differentiate our game from most.

Challenging Artificial Intelligence – The AI of the player’s enemies will both challenge and entertain them, with complex AI algorithms creating unique enemy behavior.

Eight-player multiplayer – With the ability to play against up to seven other people, System Chaos’s multiplayer adds the potential for hours of replayability.

Technical Cost Overview

Staff Technical Director – Ross Dexter: $70,000 Producer – Malia Guerrero: $70,000 Designer – Greg Kohne: $70,000 Product Manager – Adam Henderson: $70,000

Total Salary: $280,000

Technical Costs Computers: $8,000 ($2,000 x 4) Microsoft Visual Studio .NET: $4,000 ($1,000 x 4) Windows Professional XP: $1,200 ($300 x 4) Microsoft Office: $2,000 ($500 x 4) 3D Studio Max: $3,500

Total Technical Cost: $18,700



Total Cost: $298,700

Monthly CostMonthly Salary: $35,000 ($280,000 / 8 months)Monthly Technical Cost: $2,337.50 ($18,700 / 8 months)

Total Monthly Cost: $37,337.50

System Requirements

Operating System: Windows 98/ME/2000/XP with DirectX 9.0c CPU: 1Ghz processor or equivalent Memory: 512 Megabytes Graphics: Geforce4 with 64 megs or better Disk Space: 100 megabytes

Timeline and Milestones

Each of the following objectives is listed by the week during which it must be completed (deadlines are the Monday following the provided date). Nearer deadlines are more detailed (including who must complete what), while further deadlines are a bit looser.

Schedule Engine Proof

Simple camera Character moving in 3 dimensions Can stand on platforms Chat system set up for networking Rough animation will be in Level loading and switching State machine AI in

Prototype Enemies have simple AI Character can get cubes and throw them Enemies can be killed Networking will be refined Simple puzzles are solvable HUD will be present Camera system will be refined 2 people (at least) can see stuff on the screen



Flocking and A* pathfinding AI in

Pre-Alpha Integrated buoyancy Testing of basic vertex shaders 8 players can watch the same thing on their screen AI up to this point debugged Good camera implemented Menu system implemented HUD complete

Alpha People can play together on a network Vertex shaders implemented, but not debugged Spring physics integrated Genetic AI in Basic levels Sounds and music integrated Animation system complete

Beta Fine tuning the engine Tweaking the gameplay Debugging graphic

GoldAll done!!!

Risks The graphics engine contains elements that may be difficult to implement, such as

animation and vertex and pixel shaders. Should some of these elements prove too difficult, they could be scaled back, or even removed altogether, if (like the pixel shaders) they are not absolutely essential to the game.

Detecting and correctly resolving complex collisions will be difficult, and implementing them in an efficient manner will be even harder to do. Resolving collisions with total accuracy would probably have more drawbacks than benefits. To simplify collisions, the player an enemies will use simple bounding spheres. The physics calculations will tend to favor more efficient algorithms rather than more complex (but more accurate) ones.



Developing the tools needed for the game may take longer than expected. The complexity of the map compiler (see Internal Tool – Map Compiler) could be scaled back to reduce the time needed to implement it, but that could negatively impact the quality of the levels we create. We will have to strike a balance between the complexity of the tools and the quality of the content they produce.

Networking will almost certainly prove to be a very difficult obstacle to overcome and it will have to be integrated into the game architecture at the most basic level for it to function well.

Implementing challenging and interesting AI behavior will certainly be a complicated.

External Tools

The external tools are used to develop content for System Chaos and generally make our lives easier by reducing time needed to develop internal tools.

Microsoft Visual Studio .NET

Polymorphic Productions develops all of its code with Microsoft Visual Studio .NET, which gives us a user-friendly interface and powerful debugging capabilities. It is also compliant with the C++ standard, allowing us to write correct, and potentially portable, code.

3D Studio MAX

3D Studio MAX will be used to create the 3d models for game objects, enemies, as well as the player. The models will be exported to Microsoft DirectX .X format which will in turn be loaded into our game via DirectX.

GIMP

GIMP will be used for all of our 2d art assets, such as textures, background images and GUI art. 2d graphics assets will use the .PNG format.

CVS

We will use CVS (Concurrent Versions System) for version control on the project. The CVS server is located offsite in Redmond, Washington, and allows us to backup all of our code, reducing lost development time in case of a problem.



WorldCraft/Hammer

WorldCraft (now also known as the Hammer editor) will be used to create the levels for our game. From WorldCraft, levels will be exported to .MAP format, which will then be read in by our own custom map compiler, which will reformat the data in a way that best suits our game.

The .MAP format is documented well enough for it not to present a significant barrier to the development of the game; at least it will not be any more difficult than designing and implementing a level editor from scratch. The Worldcraft level editor is far more robust than any custom tool we could develop in the time we have which should result in higher-quality levels.

Internal Tool – Map Compiler

Overview

Though we are using WorldCraft to design and build our levels, directly reading the .MAP files into our game may not be the best solution. We may want to perform some time-consuming algorithms on the map data that are simply not practical to run when loading the level into the game.

For example, in the .MAP format level geometry consists of sets of “brushes” which are convex polyhedra defined by planes. It would take far too long to convert all of the brushes in a level into a list of polygons at run-time, so instead we feed the .MAP file into a level compiler, custom built for our game. The map compiler will read in .MAP files, perform the needed operations on the map data, and save the resulting data into an .SCL (System Chaos Level) file. The .SCL files are read into the game with the data already compiled into the proper format so it will take far less time for the levels to load.

Interface

The System Chaos map compiler will not require a complex interface, so it will be a command line tool. The user will run the compiler with command line arguments specifying the .MAP file to compile, the name of the .SCL file to direct output to, and possibly other parameters that switch compiler options on or off if they should become necessary.

Benefits / Drawbacks

The major drawback in using WorldCraft to build our levels is in having to learn the .MAP file format and write the custom map compiler for System Chaos. However, there is much documentation available, so learning the format should not prove to be that



great of an issue. Writing the map compiler will be far more complex as it will require some fairly complex algorithms, such as constructive solid geometry (CSG) union to eliminate unnecessary polygons. Debugging the map compiler may also be rather tricky, and tracking down all the issues will likely be time consuming.

Though writing the map compiler may be difficult, the benefits will be significant. Using WorldCraft means we will not have to code our own level editor, which could save us a great deal of development and testing time. The WorldCraft editor is also much more refined and functional than any tool we could create during the course of the project’s development which will make it far easier to develop levels. We feel that these benefits far outweigh the drawbacks.

System Chaos Level File Format

See SCL File Format in the Appendix for details.



Game Initialization and Resource StorageWhen the game starts up it enters the initialization phase. All of the system

modules (see System Modules) are instantiated and initialized. First, the Window class is instantiated, which creates the window used to display the game. Then the Direct3D class is instantiated, which encapsulates the initialization of the Direct3D 9 object and device. Next follow the Sound and Input classes.

After the initialization phase is completed, the game loads the resources necessary to display the menu screens: textures for the graphics and sounds for menu clicks and background music. All textures will be stored in a Texture Table; an std::vector of IDirect3DTexture9 objects. Similarly, sound, music and fonts will be stored in Sound, Music and Font Tables, also std::vectors.

When the player decides to start a game (single or multiplayer), the game will read level data in from an .SCL file (see SCL File Format), and will load the appropriate textures, sounds, music, and meshes that are required by that level. As with textures and sounds, meshes also have their own table, an std::vector of ID3DXMesh objects. The polygons that make up the level geometry are similarly read into a table.

Game entities (see Game Entities) are also stored in tables, but are not visible resources. Rather, they are used to represent objects within the level. They are created after the graphical/audio resources are loaded in, generated from data contained within the .SCL file. Those game entities that have a mesh and texture field will be assigned indices to the location of their resources within the mesh and texture tables.

Should the player finish the current level and load a new one, all of the resources used by the previous level are released, and the resources needed for the new level are loaded. By loading in only the resources that are necessary for the current level (as opposed to simply loading all game resources into memory), we reduce the memory footprint of the game. Having to load resources before each level does increase load times, but we expect the set of textures, meshes, sounds and music for the game to be rather small, and should not significantly impact level load times.



Game EntitiesGame entities consist of two different kinds of objects: non-level geometry

objects that are visible within the game (the player, enemies, element sources, and elements); and invisible objects that control or affect the game (game info objects).

Player, enemy, element source, and element entities contain all of the information necessary to represent their respective object within the game. They contain information about which mesh they use, what texture covers them, where they are, which way they are looking, what they are currently doing, and more.

Game info entities are used to define things such as the location the player starts at when a level begins, where spawn points are in multiplayer, and where the end of a level is located. They are invisible to the player, but essential to the game.

Each game entity type will be stored in their own resource table, to eliminate the need to search for a particular entity type within a generic storage class. For more information on game entities, see the Game Objects section.



Graphics

Overview

The System Chaos graphics engine will be built around the DirectX 9.0c API. It will be designed to take advantage of advanced DirectX features, such as vertex shaders, and will be abstracted to simplify its interface to make it as easy as possible to get 3d images drawing on the screen.

The graphics engine will be responsible for drawing all geometry, as well as animating the player and enemy meshes, and displaying the HUD and game menus.

Structure

The heart of the graphics engine is the DrawScene function, which is called once a frame by the main game loop. All drawing and animation is performed here.

To draw a frame, the function will iterate over all objects stored within the game entity and level geometry tables. Local copies of each of the visible player and enemy meshes will be kept, and animations will be applied to them using the appropriate animation transformations. After the meshes are animated, the meshes and all visible level geometry would be rendered to the screen.

Rendering a mesh in Direct3D is very simple; you set the material and texture and then you tell the mesh to draw each of its subsets, one after the other. Each subset can be rendered with a different material and texture, if it is necessary.

For rendering the level geometry, we will first cull all polygons outside the view frustum, and then load each visible polygon into a mesh. The polygons will be arranged into subsets based on what texture they use; all polygons with the same texture will go into the same subset. Then we render the level geometry like any other mesh.

After the level geometry is rendered, we draw all visible game entities. Each one has a mesh and a texture, and it will be very simple to iterate over all of them, drawing each one in turn.

The geometry in the game will be fairly simple, both to reduce the number of complex collisions, and to decrease the load on the graphics engine. We do not anticipate needing a complex HSR (Hidden Surface Removal) algorithm, such as occlusion or portals; backface culling coupled with a depth buffer will most likely suffice. If the engine is found to run too slowly, we could implement an HSR algorithm to eliminate hidden geometry, and perhaps a BSP (Binary Space Partitioning) tree to take the place of a depth buffer. However, since we are targeting high-end machines and do not plan on



polygon-intensive scenes, the need to implement an HSR algorithm is very low on our list.

The HUD would also be displayed while the player is in the game, and any menus that might be active. The menus will be simple so as to increase the ease of their implementation. There won’t be a need for many different menus so they will be designed by hand rather than by a tool. The menus will occupy the entire screen, so when they are being displayed the rest of the game will be paused and rendering non-menus graphics will cease.

Menus and the HUD will both make use of textured quads, though each menu will likely use more than one quad, one for each button or graphic.

Advanced Graphics

The System Chaos graphics engine will make use of some more advanced graphics rendering techniques, such as vertex shaders. Specifically, the game will feature cartoon-style shading.

Cartoon shading (also known as cell shading) will give the game a stylized, cartoon-like appearance. With cartoon shading, there are only a few (typically three) shading intensity levels, with an abrupt transition between them. Objects also have their silhouette edges outlined, giving the scene a comic book feeling. Cartoon shading is one of the easier vertex shaders to implement, and should not be too difficult to get into the game.

If we find that cartoon shading is not too our liking (the game may not quite lend itself to the style), then we may experiment with other vertex shaders, to see what other techniques complement our game.

Since vertex shaders are only available on higher-end graphics cards, they will only be enabled if the GPU in the user’s computer supports them.



Game PhysicsPlease note for the following sections that any numbers (even relative ones) that

we might come up with are pretty worthless, so until we’ve had a chance to test physics these are “To Be Determined.” Also, hit points refer to any kind of health tracking for the player and enemies. Since they will be able to die, there must be a way to determine when.

Motion

All motion is vector-based, utilizing both acceleration and velocity. Jumping and falling mechanics (gravity) are dealt with merely by adding a downward constant to an object’s acceleration vector. Velocities, of course, are capped at a sane value. This means that if a character is falling, they’ll hit a terminal velocity fairly rapidly. The same goes for controlled movement, such as moving left or right.

For mobile game objects (such as enemies), they are given an arbitrary velocity based on their current state and the rest is left up to gravity. Much more interesting are the player mechanics, determined by player controls:

Jump: Set vertical velocity to a positive number and add gravity to acceleration. If time permits we can also add pressure-sensitive jumping. This means a tiny bit of acceleration upward is applied if the player holds down the jump button (causing a slightly higher jump).

Press/Release Left: Add/subtract high value to left acceleration (it should be above the constant used for terminal velocity).

Press/Release Right: Add/subtract high value to right acceleration (it should be above the constant used for terminal velocity).

Press/Release Forward: Add/subtract high value to forward acceleration (it should be above the constant used for terminal velocity).

Press/Release Back: Add/subtract high value to back acceleration (it should be above the constant used for terminal velocity).

Any time we’re not on the ground: Apply gravity constant to downward acceleration.

These acceleration-based controls offer a little bit more of an interesting sensitivity and semi-realistic feel.

Relating to efficiency, it can fly right past people that this can be done incrementally:

acceleration += external_force;velocity += acceleration;position += velocity;



Springs

In addition, to normal motion, the game will also incorporate springs. The main focus of them will be a boss with a spring-based tongue, but when the physics is written, they may be applied to a variety of things. Based on Hooke’s Law, the springs will act realistically:

F = ks * (L – r);

Where ks is the spring constant, L is the spring’s full length, and r is the spring’s length at rest. This force will be added to the other forces acting on the object, such as gravity.

Dampers will also be used to dampen springs, if needed.

F = kd * (v1 – v2);

Where kd is the damping constant, and v1 and v2 calculate the relative velocity of the connected points on the two connected objects. This force will be added to the total forces on an object.

Buoyancy

The game will also have buoyancy, so when the player or enemies stand on something that floats, it will act realistically. The buoyancy in this game will be a little unrealistic – the point of the game is not to stay upright in water, it’s to get across the water, so the buoyancy will be mainly for looks. It will not deal with center of mass or center of buoyancy. Basically, the buoyant force will make the floating object go up and down slightly. The buoyant force is:

F = * g * v;

In this formula, is the density of the liquid, g is gravity, and v is the volume of the object. Usually, characters won’t be able to float; they will be forced to stand on things floating in the water. The buoyant force will act mainly on these.

Collision Detection

Collision detection will initially be between bounding spheres (A) and given time, bounding boxes(C). Primitive physics objects (detailed in Game Objects) are designed such that new ones may be added without reworking existing code.

Collision Resolution



Collision resolution (as opposed to detection) is handled entirely in the update function. Following are the possible interactions to date:

Enemies and players: Injure the player (subtract hit points). If the player is attacking in the enemy’s direction, the reverse happens (subtract enemy hit points, leaving the player untouched).

Walls or other static objects: Allow the player to move up to the edge of this object, but once touching it, don’t allow any acceleration or velocity to be applied through the object. Static objects behave the same way toward enemies and projectiles.

Projectiles: When colliding with a player or enemy, apply damage to that object if whoever fired the projectile is not on the same side. In multiplayer, projectiles launches by the player will affect other players as well as enemies.

Particle effects: Damaging particle effects behave like projectiles. “For show” effects generally have no collision.

Objects will not be able to pass through each other. Thus, they will have to bounce off of each other. Collision resolution will handle that with vectors. Values from the previous frame will be stored so that the vector from each object’s previous position and the object’s new position can be calculated.

V = new_position – old_position;

With these vectors and velocities, the collision point can be calculated as well as the angle of incidence. The objects’ new positions will be the angle of reflection off of one another. The vectors will have a magnitude of the remaining time slice multiplied by their current velocities.



Artificial Intelligence

Overview

As of right now, the major headings in this section will be State Machines, Pathfinding, and Flocking. A 4th section may be added later for genetic algorithms or some other, more advanced AI algorithm.

State Machines

There are 4 lesser enemies and 1 boss that will need to be implemented. Each will have its own unique behavior, but also share things in common. For this, we will use a base class called “CMonster”, and have derived classes for each of the different types. We will most likely use virtual functions. For instance, we may have a “MoveTowardsPlayer()” function that will have slight differences in the way that each type of monster approaches the player.

There will be an enumeration in CMonster that enumerates all the different possible states for the different monsters. For now, these are the states in the enumeration (may change):

enum State{

MOVE_TOWARDS_PLAYER,IDLE,CIRCLE_PLAYER,STOP_AND_SHOOT,STRAFE,RUN,LASH_OUT_TONGUE,SPEW_FIREBALL,BREATHE_FIRE,SELF_DISTRUCT

};

Each state has a corresponding function that at least one of the different types of monsters will use. If we discover that the function is one that all monsters can use, the function will be made virtual.

Flocking

There will be one type of enemy (called a “quanta”) that will approach the player as a flock. The flocks will be in a random cloud-like formation, and will be no bigger than 10 units (since flocking is an n2 algorithm we decided on this restriction). The



purpose of the flock will not be to swarm the player but more to impede progress (so they will walk up to the front of the player and keep a small distance and shoot rather than surround the player). However, to get past the flock of quanta, the player will have to destroy them.

Since the flock size will be limited to 10 enemies, there will be no “leader of the pack”, as the reason for having a leader is only to optimize the algorithm for large flocks.

A* Pathfinding

Since some game levels may be maze-like and complex, A* Pathfinding will be the behavior of the lesser monsters that are within a certain range of the player, and then when they get up close it will switch to whatever the unique behavior of that particular monster is.



Multiplayer

Overview

There will be a pointer to a multiplayer object manager in the global data struct, which has a list of all the players and an instance of a client/server class.

The client/server module contains a list of connections to connected computers, a queue for sent- and pending (sending) messages, as well as other lower level things for basic UDP networking and logging (debug). The class will have the functionality to send and receive packets using the reliable UDP methods. All clients will send their input to the server; the server will then take the input and resolve the current game state, then send the resulting updates back to the clients.

The following are the only things that will be processed in multiplayer: collisions (between players, terrain, game objects, and event-spots), elemental effects (overloads that affect health and/or score), scoring (as players hit each other with elements, score goes up or down), time (how long it takes a player to get to the end of the level), and the end of the match event. The server will be running a timer such that when it runs out, the race to the end of the level ends and melee mode is entered.

There will not be a split-screen multiplayer mode; instead each player will interface to a server and the game from their own computer. We will have to keep view matrices for, and instances of all the players in the server module, but the clients will only have their own view matrix. Each player will additionally have fields for time-taken, hits and name field to distinguish them from other player's in there scoring at the end of multiplayer matches. Other than that the multiplayer game will share all the same data as the single-player game. Some simple colored text output in a table/list like format will display the stats of each player at the end of the match.

Structure

Multiplayer Manager:

Contains the client/server module Contains flag indicating which mode of multiplayer is currently active

RACE_TO_FINISH MELEE

Contains a flag denoting whether the end was reached in RACE_TO_FINISH mode END_REACHED

Contains the number of remaining players (for use in MELEE mode) Contains the total time elapsed for the entire multiplayer match



Contains a max_time elapsed value to indicate the amount of time that can be taken before the end can be reached, before the match turns into a melee.

Contains the minimum time taken to reach the end of the level (The first part of multiplayer matches).

Contains a list of structs containing all players and their scores/times/ranking. Checks if the match is over

If in RACE_TO_FINISH mode, check if END_REACHED flag was set to true in the frame-update. Send end of game message through the client/server module, then display scores

If in MELEE mode, check if number of remaining players is 1 Send end of game message through the client/server module and display scores

Client/Server Module:

A separate networking thread will be used which keeps a list of all "connected” IP addresses (If server client, client will only have one).

Sending a packet:

Pull messages from a message queue. Stuff messages into packets

Packets must be under the maximum packet size. They will automatically be broken up if too large, but if any one is lost they are all thrown out.

Give the packets an ID number when sending (by adding one to the previous packet ID).

Three data sections within each packet: Initial Data section: contains the packet ID Turn Number (if sending more than one packet per "turn"). Reliable Data section: messages that must be received. Unreliable Data section: messages that are not required (position updates...).

Additional data Sync number (optional): Generates a random number and checks to see if it

matches with one generated by the client/server (if the numbers are not the same, something is wrong).

ID of the last packet sent (containing reliable data). ID of the last packet received.

If packets are broken up, they must indicate that they are part of a larger piece of information (point to the other packets). If these packets are received out of order, they can just be re-ordered. If sending large chunks of data, it is usually a good idea to keep it separate from

other data. If a packet contains any reliable data, place it in a sent queue (this is used to

resend data if necessary).

Receiving:



If the server, check who the packet is from. Save the last packet ID processed (from each connection).

The ID of each packet is sequential. Store the ID of this packet.. After the packet is processed, discard it. If the ID is not the next one in sequence, there was a missing packet(s). If only unreliable data is contained (position updates...), process the data.

Will have a pending packets queue for missing packets. Packets will be added to the queue if the next packet received says the last packet with reliable data is the packet that is missing. If there is a missing packet that contains no reliable data, don't add it to pending.

Resending Packets If the incoming packet indicates that a packet containing reliable data has not been

received, the packet must be resent. If the ID of the last packet the connection received is lower that and ID of the last

packet sent, re-send the packet. Remove from the sent queue based on these messages.



Code OverviewCoding Standards

Naming ConventionsFor the most part, we should simply use common sense in creating names for

variables, classes and functions. They should be brief and descriptive, and ideally you should be able to tell exactly what something does just by looking at its name (and perhaps a short comment near the declaration). Naming your variables, classes and functions well makes it far easier for others to maintain your code.

To keep code somewhat uniform across the project, it would be good to adhere to the following simple naming conventions whenever possible:

Capitalize the first letter of every word: ClassName, FunctionName, VariableName

Single-letter loop control variables are brief and familiar to us all: i, j, k, x, y, z Prefix pointers with ‘p’: pPointerToVariable Prefix class member variables with ‘m_’: m_ClassMemberVariable Prefix function parameters with ‘p_’: p_FunctionParameter Use combinations of the above Avoid the use of underscores, especially leading underscores

Code DocumentationComments that describe your code are always good, but well written code is self –

documenting. Clean, well-formatted code is easier to read and understand, and if you need five pages of comments to describe one function, then it is either too long or poorly written.

Still, no matter how well you write your code, you are still going to need some comments in there so others can easily understand how it works. Single-line comments distributed throughout your code can go a long way.

The following commenting conventions should be followed to help make everyone’s code easier to maintain over the lifetime of the project:

File headers: File name(s) Author Date created Basic description

Classes: Basic description

Functions: Description Explanation of function parameters



Return

Variables: Include a brief description if its purpose isn’t obvious.

Coding PracticesMost of the following rules and guidelines are in place to reduce the possibility of

side-effect bugs. Often these bugs won’t be caught until far too late in the project and may take many days to fix, instead of a few minutes doing it properly the first time. Some are just suggestions, while others need to be followed. Consider rules higher in the list to be the most important.

1. There will be one global object. Don’t make any more, even if they’re only declared in your header.

2. Don’t assume that the people using your classes or functions will understand how they work. Make them as robust (break-resistant) as possible. By the same token, don’t require anyone to care about how you do something. You should be able to tear out an implementation and drop in an entirely different one without changing any other code.

3. Only expose class interfaces that need to be public. Rarely (if ever) should private variables be fully exposed. This largely ties in with the above point, but bears repeating.

4. Avoid any optimization that depends on a strange coding trick or a detail of your implementation. These details might change, which can cause such (often difficult to track down) optimizations to break anything that depends on your implementation. If performance is in question we can worry about optimizing bottlenecks later.

Use the const keyword with every function (or reference/pointer function parameter) to which it applies. This is just style, but aids readability immensely. It’ll also keep you from accidentally altering something you shouldn’t.

Main Game Loop

When the game starts up, it immediately enters into the main game loop. The behavior of the game loop is controlled by a set of game states. Some of the possible game states include IN_MENU, ACTIVE, PAUSED, LOAD_LEVEL and SHUTDOWN.

The IN_MENU state indicates that a menu should be displayed. If the player brought up the menu while in the middle of a level, the game is paused in the background, and AI and Physics are deactivated, because they are unnecessary.



The PAUSED state indicates that the player has decided to pause the game and, like in the IN_MENU state, AI and Physics are deactivated, and Input ignores any commands to move the player.

The ACTIVE state means that the game is in full swing, and all components of the game are run. If AI and Physics components are inactive, they are reactivated.

The LOAD_LEVEL state is set when the player reaches the end of the current level, and the next level needs to be loaded.

The SHUTDOWN state is activated when the player chooses to exit the game.

The following chart illustrates the flow of the game loop:

Initialize GameInitializes all game objects (Graphics, Sound, Networking, etc.), loads resources

(meshes, textures, sounds), set the game state to IN_MENU, and activates the root menu.



LogicDetermines when the player has finished the level and changes the state to

LOAD_LEVEL to transition to the next.

InputGets input from the user via the keyboard and mouse. In the menus, Input

determines where the player has clicked, and if a new menu should be loaded or if the game should be started. When in-game, it uses the input from the player to move them around and interact with the game world.

AIPerforms all artificial intelligence algorithms to move the enemies around, attack

the player, etc.

PhysicsDetects and resolves collisions, applies gravity, spring, and buoyancy calculations

on the player, enemies and elements.

SoundPlays a sound for each action taken by the player and the enemies, collisions and

element effects, and plays background music as well.

NetworkingIn a multiplayer game, the Networking component handles all communication

between the clients/server.

GraphicsRenders all visible geometry to the screen, and displays the menu when it is

active.

Load New LevelIf the game state is set to LOAD_LEVEL, this will load the next level into

memory after unloading the previous level.



Shutdown GameIf the game state is set to SHUTDOWN, this will free all game resources and

terminate the game.

External Code

External code includes any 3rd-party APIs we use in the implementation of our project.

DirectX

System Chaos will use DirectX for rendering 3d graphics, reading input from the user, and for networking machines together for multiplayer. DirectX is very capable, and thought it restricts us to Windows systems, we gain the ability to create very impressive, speedy 3d graphics, as well as abstract both input and networking.

FMOD

Sound is not one of the primary features of our project, and as such we want to spend as little time implementing it as possible. That is why we chose to use FMOD to add both sound and music to our game. It is very simple to implement and use, and will more than adequately serve our purposes.

System Modules

Rendering

The rendering classes encapsulate the creation of the window, the initialization of DirectX, and drawing to the screen. They are initialized and released through the use of the Init() and Release() methods, so we can control exactly when and where they are created, and not have to rely on constructors and destructors.

Window ObjectWindow Object is a highly limited class for creating and releasing a blank GDI

window. It abstracts full screen and windowed mode so they both behave exactly the same way.



Direct3DAs the name might imply, it’s Direct3D. This keeps a reference to the Window

object so that we don’t have to duplicate information.

VertexBufferThis is an encapsulation of Direct3D’s vertex buffer mechanisms. It wraps the

lock/unlock functions as well as various initialization, release, and error-checking mechanisms.

IndexBufferThis object is almost exactly like vertex buffer… only it’s for Direct3D’s index

buffer mechanism.

Input

The Input Object is the main storage and manipulator for input data. One or more of these objects are created by the game and mapped to an input device. Each object stores one input device, so an object is created for the Keyboard and one for the mouse.

At run time the system creates and initializes the keyboard and mouse. Players can change key bindings from the options menu. These objects are set up with the button configuration from the options data file, which is updated whenever the user changes the key bindings.

Audio System

The audio system will consist of a class that allows sound objects to be created based on the object invoking them. For the most part, this behaves as a wrapper class much like the ones we’ve already written for Direct3D and DirectInput.

Startup (Init) will create background music to be played, or a collision will cause a sound effect to be played, for example. Music will have attributes allowing its volume to be changed, as well as a start/stop for pausing and moving through menus. Sound effects will most likely all have a set volume, unless the effect requires a specific manipulation. All sounds will have the option to loop, which will be (de) activated upon creation.

All sound effects for a level will be loaded at startup. While this requires us to have a slightly larger memory footprint, it eliminates any worry of trying to dynamically load sounds as they’re required.

Game Objects



This section holds the collective descriptions of each required class. Many of these classes include lists of member variables and methods, though does not necessarily reflect exactly what every class will need. Other than that, this is as detailed as it can be. Since this is only for game objects, we won’t be discussing all of the low-level graphics encapsulation.

PhysicsObjectThis is the base class for all primitive objects. All physics objects will be treated

as if they are the base class except on initialization. This class must be kept abstract to prevent anyone trying to instantiate it. For physics objects intended to have no effect on the world around them, a null object (with empty interfaces) is provided. A critical feature of the physics object is that it must remain extensible.

Members: Acceleration: Floating point vector. Velocity: Floating point vector. Position: Floating point vector. Mass: Floating point value. Volume: Floating point value.

Functions: virtual bool CollidesWith (const PhysicsObject &object) const;

o Check whether this object collides with another. Virtual int GetType (void) const; Returns a flag (constant) telling what type of object this is (box, circle, etc).

FontFonts will be implemented as bitmapped fonts. A 256x256 texture will contain all

possible characters, each in a 16x16 pixel block. This does support variable width fonts, in which case the character is always on the left edge of its block and an array is stored denoting its true width. Similarly, kerning is easy enough to implement.

Very special care must be taken when scaling a font. Any font that might be scaled will likely have inaccurate texture map coordinates, so a bit of padding space (and anti-aliasing in the texture) should be added to account for this problem. That means you’re effectively limited to a 15x15 font (assuming one pixel of padding at the bottom and right sides).

Members: TextureID: index into the texture table where the font texture is stored. Quads: This is a vertex buffer that stores all the processed vertices for each letter.

The start of a particular quad is always “character_code*4”. The list of quads is calculated upon loading the font.

Spacing: Number of pixels to space characters by.



InputMembers:

DI ‘stuff’: This covers the actual DirectInput8 object, necessary handles, references, Contexts, etc.

buffer: Used to hold input events until they’re processed. actions: Stores the last 3 (more if required) actions taken. The player probably

will never be able to input faster than our game loop handles it, but don’t discount things like programmable/turbo controllers.

type: Just for keeping track whether object is Keyboard or Joystick.

Functions have not yet been finalized, but the basic requirements are as follows: void Process (void);

o Gets the current input and translates it. This polls the device, but any state change is stored internally.

bool CheckStateo Checks the current state of any button (either pressed or not).

Because we allow dynamic configuration of buttons and keys, a lookup table is required for all key reads. This is fairly basic to implement, and mainly consists of a two-way table that translates key codes to game actions (an enumerated list), and vice versa. Having the redundancy makes for quicker lookups when assigning buttons on the menu (if the player enters a button choice that is already assigned, we must remove it from the already assigned button). This is just a sub class storing these two items that will be a member of the Input object.

class LookUp{public:bool SetButton(int button number);bool SetAction(int button number);

bool CheckButton(int button number);bool CheckAction(int button number);

// do the obvious things here

private:char ActionMap[256]; // controllers won’t need this many buttons, butchar ButtonMap[256]; // keyboards will, no need to split code and have

// objects for each};

PlayerThe player structure contains all information needed to represent the player in the

game. This includes a 3d model, animation, position, and so on. The game will have a table of player data; only one entry will exist within it during single-player, but in multiplayer it will contain one entry for each player in the game.



Members: PhysicsData: a PhysicsObject that contains all the data needed to represent the

object in terms of physics. Health: an integer that represents how much health the player has. CurrentElement: an element structure that indicates what element, if any, the

player is currently holding. MeshID: an index into the mesh table where the player mesh is stored. TextureID: an index into the texture table where the player texture is stored. AnimationSet: the set of animations the player can go through. CurrentAnimation: the current animation the player is going through. AnimationFrame: current frame of animation.

EnemyThe enemy structure, like the player structure, contains the information necessary

to represent an enemy in the game. It shares many of the same data members as the player structure, with the added features of an AI behavior and an elemental weakness.

Members: PhysicsData: a PhysicsObject that contains all the data needed to represent the

object in terms of physics. Health: an integer that represents how much health the player has. CurrentElement: an element structure that indicates what element, if any, the

enemy is currently holding. MeshID: an index into the mesh table where the enemy’s mesh is stored. TextureID: an index into the texture table where the enemy’s texture is stored. AnimationSet: the set of animations the player can go through. CurrentAnimation: the current animation the player is going through. AnimationFrame: current frame of animation. AI: pointer to an AI behavior for this enemy. Weakness: indicates which element this enemy is susceptible to.

ElementSourceAn element source is an object that the player and enemies can extract elements

from. The element source structure contains all relevant information that is needed to place and use an element source in the game.

Members: MeshID: an index into the mesh table where the element source mesh is stored. TextureID: an index into the texture table where the element source’s texture is

stored. Position: 3d position of the element source. Orientation: element source’s 3d orientation vector. BoundingVolume: a bounding volume that best represents the element source. Type: type of element that can be extracted from the source.



Elements: number of elements contained within the source. Value is negative if number is infinite.

Cap: maximum number of elements the source can contains. Scale: 3d scaling vector.

ElementThis structure represents elements when the player or enemy is holding them, and

when they are being thrown through the air.

Members: PhysicsData: a PhysicsObject that contains all the data needed to physically

represent the element. Type: the type of the element (fire, flora, earth, etc.) Infinite Source: this is set to true if the element originated from an infinite source

(elements from infinite sources behave differently).

GameInfoThe GameInfo structure represents abstract game entities; such as the level start

position, the level end position, and multiplayer spawn points.

Members: Type: the type entity this instance represents (single-player start, multi-player

start, level end position, etc.) Position: 3d position of the GameInfo entity.



User InterfaceMenus

The main menu consists of a few graphical buttons (selectable by keyboard or mouse) denoting the following options:

Start Game – Start a new single player game. Multiplayer – Start a new multiplayer game. Options – Set up button/key mappings for both single player and multiplayer as

well as sound levels and graphics settings. Credits – Display the game credits. Quit – Exit the game.

Options jumps to a new menu with a list of commands the player can execute. By using the mouse, the player may click on any command and be prompted to input a keystroke or mouse button press, which registers the button/key to the command. After exiting the menu, the button configuration is saved to file. Sound levels and graphics options (such as filtering level, max draw distance, and perhaps more) are also configurable.

When beginning a multiplayer game, the player can chose to either choose to start a server, or search the LAN for an existing server to join as a client. They can choose the name they wish to play under, and (if they are running a server) which level to play on.

In-Game HUD

The in-game interface is as unobtrusive as possible. Two bars appear overlaid on the game in the bottom left corner. These bars indicate current health and throw/grab strength. This setup is extremely simple, and occupies a very small percentage of the screen.



Directory StructureDirectory structure will be broken into several main groups: Include, Source,

Textures, Data, and User.

Include and Source: These are for all source files. There should be no subdirectories. The reason these are segregated is to keep per-machine settings (such as project and *.suo files) from mingling with the source in version control.

o Textures: All image data is stored here, grouped in subdirectories based on their use. Menu textures will get their own directory, as will mesh textures, and level geometry textures.

Data: Immutable data files (engine-related). User: Mutable, user-configurable data files, such as configurations and saved

games.



Art ResourcesSimply put, all 2D art sources should be in PNG format. TGA also retains an

alpha channel, but is large, and bitmaps are just as large with no alpha channel support. These can be created in any way you like (Photoshop, Paint Shop Pro, GIMP, MS Paint, etc).

The only limitation on 2D art is that it must be sized in powers of two (EG: 64 pixels wide, 128 tall), and must be 256x256 pixels or smaller. We can use a smaller portion of this texture via U/V coordinates if a non-power-of-two size is more desirable. Just pad the extra space in the texture with black pixels.

3D models will be in .X format, so that they can be read in directly by DirectX. We will have to use a .X exporter for 3D Studio MAX, but it should not be difficult to find one that suits our needs.



Appendix

Game Saving

The ability for the player to save their progress in the middle of a level may be implemented, but it is far from a critical feature, and will be dropped if time becomes an issue. Should it be implemented, save game files would likely consist of the simply the name of the level and a dump of the player, enemy, element source and element tables to a text file.

SCL File Format

The SCL (System Chaos Level) file format will be used to store the level data for the game. The map compiler will generate .SCL files from .MAP files that are exported from WorldCraft. What the exact structure of the format will look like is not known at this point, however we know what information it will need to contain:

Enemy List: a list of all enemies in the level. Element Source List: a list of all element sources in the level. GameInfo List: a list of all game info entities in the level. Mesh List: a list of all meshes used within the level, including those used by

entities. Texture List: a list of all the textures that are used in the level. Polygon List: a list of all the polygons that make up the level geometry, including

vertex normals and texture coordinates, as well as what texture should be applied to each surface.

This information should allow us to properly represent the levels for the game. Including all the meshes and textures used in the level allows us to load only those we need, reducing the game’s memory footprint.

Resource Storage Tables

All game resources will be stored in std::vectors, which will make memory management extremely simple and accessing the information extremely simple. There are different resource storage tables for:

Meshes (ID3DXMesh) Textures (IDirect3DTexture9) Sounds (FMOD sound) Music (FMOD music)



Animations Level Geometry (Polygon) Player Entities (Player struct) Enemy Entities (Enemy struct) Element Source Entities (ElementSource struct) Element Entitles (Element struct) Game Info Entities (GameInfo struct) Fonts (Font class)


tdd · web viewwith cartoon shading, there are only a few (typically three) shading intensity...

Documents