System Chaos Technical Design Document GAM300

System Chaos Technical Design Document GAM300

Polymorphic Productions Spring 2005

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)

Table of Contents

Table of Contents 2

Project Overview 4

Game Concept 4

Technical Goals 4

Technical Cost Overview 4

Staff 4

Technical Costs 4

Monthly Cost 5

System Requirements 5

Timeline and Milestones 5

Schedule 5

Risks 5

External Tools 6

Microsoft Visual Studio .NET 6

3D Studio MAX 6

GIMP 6

CVS 6

WorldCraft/Hammer 6

Internal Tool – Map Compiler 7

Overview 7

Interface 7

Benefits / Drawbacks 7

System Chaos Level File Format 8

Game Initialization and Resource Storage 9

Game Entities 10

Graphics 11

Overview 11

Structure 11

Advanced Graphics 11

Game Physics 13

Motion 13

Springs 14

Buoyancy 14

Collision Detection 14

Collision Resolution 14

Artificial Intelligence 16

Overview 16

State Machines 16

Flocking 16

A* Pathfinding 17

Multiplayer 19

Overview 19

Structure 19

Code Overview 22

Coding Standards 22

Naming Conventions 22

Code Documentation 22

Coding Practices 23

Main Game Loop 23

Initialize Game 25

Logic 25

Input 25

AI 25

Physics 25

Sound 25

Networking 25

Graphics 25

Load New Level 25

Shutdown Game 26

External Code 26

DirectX 26

FMOD 26

System Modules 26

Rendering 26

Window Object 26

Direct3D 27

VertexBuffer 27

IndexBuffer 27

Input 27

Audio System 27

Game Objects 27

PhysicsObject 28

Font 28

Input 29

Player 29

Enemy 30

ElementSource 30

Element 31

GameInfo 31

User Interface 32

Menus 32

In-Game HUD 32

Directory Structure 33

Art Resources 34

Appendix 35

Game Saving 35

SCL File Format 35

Resource 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 Cost

Monthly 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

Gold

All 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 Storage

When 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 Entities

Game 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.