[ digipen institute of technology ] · web viewideally, a simulation with the same number and types...

[ DigiPen Institute Of Technology ]

The Mad Skills Programmersof

GAM300 – Winter 2003(row 1)

present their project…

StarfallTechnical Design Document

Dragons are awesome!

Written byJustin LaLone

Jeffery LindseyAdam Brennecke

Clark MorseChristian Crowser

1-15-2003

Version 1.1

The Mad Skills Programmers DigiPen Institute Of TechnologyStarfall TDD v1.1

Table of Contents

Table of Contents 1About This Document 5

Purpose of This Document 5Change Log 5

Project Overview 6Game Concept 6Technical Goals 6Target Platform / System Requirements 6

Minimum 6Recommended 6

Development Platform 6Development Team 6Development Time 7Manpower Allocation 7Development Risks 7External Tools 7

3D Studio Max 7The GIMP v2.1 7Adobe Photoshop 7Ogg Drop 7Reason 2 7Settings editor 7Mission editor 8Menu editor 8InstallShield 8

Interim Milestone – Feb 28th 9Individual Milestones 9

Engine Proof – Mar. 21st 10Individual Milestones 10

Interim Milestone – April 8th 11Individual Milestones 11

First Deliverable – April 18th 12Individual Milestones 12

Alpha Deliverable 13Individual Milestones 13

Beta Deliverable 14Individual Milestones 14

Final Deliverable 15Individual Milestones 15

Gameplay Overview 16Overview 16Multiplayer Coop Aspects 16Levels of Difficulty 16

Development Ideology 17

1


Coding Standards 18Naming Conventions 18

Functions 18Classes and Structs 18Variables 18Member Variables 18Function Parameters 18Global Variables 18Constants and Enum Types 18Enumerations (Enums) 18

Aliases 18Commenting 19Class Requirements 20Leak Checking 21

Graphics Engine 22Rendering Information 22Hidden Surface Removal 22Models/Meshes 23Skyboxes 23Particle Systems 23Shaders 24

Artificial Intelligence 25List of AIs 25Collective Radio Memory (CRM) 25

Physics 26Object Collision 27Code Objects 28

Class Hierarchy for game objects 28Object Storage 28

Octrees 28object 29

Public methods 29Implementation Overview 30

renderobject 30family 30Purpose 30Public Methods 30

particlesystem 30family 30Purpose 30

screenobject 30family 30Purpose 31

skybox 31family 31Purpose 31

physicalobject 31family 31Purpose 31Public Methods 31

2


Implementation Overview 31particle 31

family 31Purpose 31

spatialobject 32family 32Purpose 32

projectile 32family 32Purpose 32

ship 32family 32Purpose 32

playership 32family 32Purpose 32

capship 32family 32Purpose 33

missile 33family 33Purpose 33

component 33family 33Purpose 33

turret 33family 33Purpose 33

capweapon 33family 33Purpose 33

weapon 34Purpose 34public Methods 34

Sound 34Purpose 34

Input / Interface 34Purpose 34

Lists 34Purpose 34

Threads 34Purpose 34

Settings 34Purpose 34

Logger 35Purpose 35

Time 35Purpose 35

Memory Manager 35Purpose 35

Camera Controller 35Purpose 35

3


Camera 35Purpose 35Public Methods 35

Console 36Purpose 36

particlecontroller 36Purpose 36

Multiplayer / Networking 37Network Layout 37Network Protocol 37

Packet Structure 38Network Messages 38

Game Control 39Pre-mission 39

Mission Handler 41Game Specific File Formats 42

Mission File Format 42Settings File Format 42Model File Format 42Log File Format 42

Resource File Naming Conventions 43Models 43Sound Effects 43Skybox Textures 43

Art and Video 44Models 44Other Graphics 44Memory Usage 44

Sound and Music 46Sound Effects 46Music 46

User Interface 47Menu System 47Heads Up Display (HUD) 47

Console Commands 48

4


About This Document

Purpose of This Document

This Technical Design Document exists to provide some semblance of guidelines and general overview on how we (the Mad Skills Programmers) are technically going to complete this project currently known as StarFall. (Not to mention getting a good grade in game projects class.)

Change Log

2/14/03 – Version 1.0 – Initial Version 2/24/03 – Version 1.0.5 – Large updates to all design sections. 2/26/03 – Version 1.0.6 – Proofreading and error correction, as well as updates to

collision detection, the art and video section, tools, and coding standards.

2/27/03 – Version 1.1 – Merged in AI and pre-game control from Jeff, graphics engine from Adam, Octrees from Clark, menu system from Christian, and added mission handler and console command sections.

5


Project Overview

Game Concept

Starfall is a PC space shooter where you are a single pilot in massive space war.

Technical Goals

Technically, Starfall will have realistic collision physics, high-quality visual effects, and up to one hundred individual AI-controlled ships running smoothly on the recommended system listed below.

Target Platform / System Requirements

Minimum700 MHz Pentium III256 MB RAM3D accelerated graphics card approximately equivalent to the GeForce2, with at least 32 MB of video RAM100 MB of hard drive spaceWindows 2000

Recommended1GHz Processor256 MB RAM3D accelerated graphics card approximately equivalent to the GeForce3, with at least 32 MB of video RAM100 MB of hard drive spaceWindows 2000

Development Platform

We intend to develop this game on Windows 2000 machine that doesn’t nearly meet the minimum system requirements, and code using Microsoft Visual C++ version 6.0 Professional Edition.

Development Team

A total of five (5) people are on the development team:Clark Morse – ProducerJeffrey Lindsey – DesignerJustin LaLone – Technical Director

6


Adam Brennecke – Lead Tester, Sound Director, Art DirectorChristian Crowser – Product Manager

Development Time

Five months are allocated for the completion of this project.

Manpower Allocation

All team members, with the exception of Justin Lalone, are scheduled to work 16 hours per week on the project. Justin is scheduled to work only 12 hours per week due to the fact that we works elsewhere some of the time.

Development Risks

Our main worry for this semester is that we will be flooded with so much homework that we might not be able to spend enough time working on the game. Additionally, both the 3D engine and the AI are major obstacles that must be overcome.

External Tools

3D Studio Max3DSMax will be used for creating all 3D models within the game.

The GIMP v2.1GIMP will be used for creating and modifying miscellaneous 2D graphics. This tool is also free, and is available for download at www.gimp.org. Only one team member really knows how to use this tool, but all team members have access to it and may learn.

Adobe PhotoshopPhotoshop may also be used for the creation and modification of graphics, but is only available to team members who can use it at home.

Ogg DropOgg Drop will be used to convert and compress wave (.wav) files into the Ogg Vorbis (.ogg) file format. This is yet another free program that is available at www.vorbis.com.

Reason 2Reason may be used for the creation of music tracks, but again is only available to team members who can use it at home. It can generate .wav files and a number of other formats.

Settings editorThe settings editor we are currently developing to edit settings files for Starfall. All settings will be stored in binary format, in a hierarchy with pages containing subsections

7

http://www.vorbis.com/

http://www.gimp.org/


with multiple data fields of type int, float, or string. The editor will also generate a c++ header file that maps these fields to enumerations within nested namespaces that mirror the settings file for easy access.

Mission editorA mission editor will be created to allow us to position ships and other objects for missions and flag them for mission objectives.

Menu editorA menu editor will be used to create all of the in-game menus, by laying out buttons, fields, graphics, etc. It will not define behavior for these objects, that will be done in code.

InstallShieldWe will use InstallShield to install Starfall on our target machines, giving our users a simple, familiar installation interface to get them through it quickly.

8


Interim Milestone – Feb 28th

The input wrapper will be complete on this date. The user will be able to view basic models of ships and also move the camera around in the world using key presses. You can see the background stars in space. Ships will move around slightly. Joystick, mouse, and keyboard support will be implemented, but not all may be assigned to in game controls yet. AI design will be more fully fleshed out as well.

Individual Milestones

Input wrapper 100% complete Christian CrowserMenu Editor 50% complete Clark MorseObject Class 100% complete Justin LaLoneSkybox 100% complete Adam BrenneckeCamera Class 100% complete Adam BrenneckeBinary File Editor 100% complete Clark MorseLighting/Basic Textures 100% complete Adam BrenneckeMenu Classes 50% complete Jeff Lindsey & Christian CrowserFMod Sound Wrapper 100% complete Clark MorseDirect3D Wrapper 60% complete Adam Brennecke

Additional Accomplishments:

- Cancelled Menu Editor Development- Basic Camera Movement (Free look)- Console 20% Complete

9


Engine Proof – Mar. 21st

Ship selection will be partially created but will be buggy. A few basic weapons will be available in game. The user will be able to control a single ship at least and pilot it around. They will also be able to fire any basic weapons that have been implemented at this time. Collision detection will be in early development and may not work yet. The opponent AI will continue to be worked on and the basics of it will be working on the opponent ships. One or two projectiles will also be in the game and will be able to be fired or used in some manner. The menu editor will be near completion. The ship will be able to be switched from first to third person views by key press.


Direct3D Wrapper 100% complete Adam BrenneckeScreen Object Class 100% complete Adam BrenneckeProjectile Class 100% complete Clark MorseWeapon Class 100% complete Justin LaLoneBasic Ship Selection/Switching 100% complete Jeffrey LindseyImplementation of Basic Ship classes 60% Jeffrey LindseyMenu Creation 100% Christian CrowserCollision Detection 50% complete Justin LaLoneMission Editor 50% complete Clark MorseHUD 20% complete Jeffrey Lindsey

10


Interim Milestone – April 8th

The networking framework will be started, but nothing will be implemented in game yet. All in-game menus will be created using the menu editor. Collision detection will be complete and put into the game. Collision response will also partially be done which will allow for basic ship-to-ship deflection. A HUD will be visible to the user, but will not be fully complete. The mission editor will also be completed at this time and mission creation will be started. All of the specifics of networking will now be designed and the networking kernel may be running, but it will have little or no visible effect on the game.


Networking 20% complete Christian CrowserImplementation of Basic Ship classes 100% Jeffrey LindseyCollision Detection 100% complete Justin LaLoneMission Editor 100% complete Clark MorseHUD 60% complete Jeffrey LindseyCollision Physics 50% complete Justin LaLoneFirst Mission 10% complete All members

11


First Deliverable – April 18th

The basic components of the first mission will be completed. Collision between objects will be completed. Opponent ships will be able to fight each other and their AI will be improved to allow some strategic thinking such as avoiding being shot. At this point, it will be possible to run a server and have users connect to it, but not all network messages will be handled and there will likely be synchronization problems.


HUD 100% complete Jeffrey LindseyCollision Physics 70% complete Justin LaLoneNetworking 40% complete Christian CrowserFirst Mission 30% complete All members

12


Alpha Deliverable

The user will be able to go through the menus and start a single or multiplayer game. They will be able to select the ship they wish to fly and begin their mission. At this point, the user will be able to complete a mission both by destroying all of the opponents or achieving the appropriate goals for that mission. At least 3 missions will be completed by this time and the fourth will be well on its way to completion if not completed already. The user will be able to switch between ships in combat and the AI will take over for the player when they leave a ship. Radio commands will be implemented as well and the AI will react to the voice commands that the player gives them as well as commands from other AI units. All networking will be complete, although some tweaking may still be done to improve client-server synchronization.


First Mission 100% Complete All membersSecond Mission 100% Complete All membersThird Mission 100% Complete All membersFourth Mission 70% Complete All membersNetworking 100% Complete Christian Crowser & Jeff LindseySound Effects 100% Complete Adam BrenneckeGraphical Effects 40% Complete Adam Brennecke & Clark MorseCollision Physics 100% Complete Justin LaLoneAI 70% Complete Jeffrey Lindsey

13


Beta Deliverable

The user will be able to play the missions cooperatively through multiplayer with at least 7 of their friends. All of the missions will be completed, but may contain minor issues/bugs that need to be attended to. The user will have all of the functionality that they would have at alpha, but by this point all of the new textures and models will be in the game as well as finalized soundtracks and sound effects. The game will also be able to be installed using InstallShield.


Background Soundtrack 100% Complete Adam BrenneckeFourth Mission 100% Complete All membersVoice Commands 100% Complete Adam BrenneckeFinalized Art 50% Complete All membersAI 90% complete Jeffrey LindseyInstaller 100% Complete Clark Morse

14


Final Deliverable

By this point, the game will be finished and all functionality will be in. The box art will be completed as well as the manual. All known bugs will be fixed and the game should be able to be completed in it’s entirety along with multiplayer being finalized as well. For the meaning of finalized, see “Gameplay Overview.”


Finalized Art 100% Complete All membersBox Art 100% Complete Christian CrowserManual 100% Complete Adam BrenneckeAI 100% Complete Jeffrey Lindsey

15


Gameplay Overview

Overview

Two armies are at battle. All human players are always fighters on the good side (Calenalph). Each side will start with no less than 20 fighters, and about 60 fighters on average. Each player will only be able to control one ship at a time, so AIs will control all other ships. There will always be at least two mission objectives available to the players. One possible objective will always be to destroy the enemy fighters. Secondary objectives may include defending a ship or space station, disabling a large enemy ship, gathering stranded objects, or preventing a moon from crashing into a planet. Ideally, a simulation with the same number and types of ships on each side, no secondary objective, and no human intervention, should result in a 50-50 chance of either side winning. In the real game, the enemy should always start out with a larger force so that the players are required to show superior skill, and turn the tides of the battle. With this system, the levels of difficulty can be translated into the difference between the starting forces on each side.

Players can switch between ships at any time. Upon switching out of a ship, the original AI pilot will retake control. If a player’s ship is destroyed, they will automatically be switched to another ship. Switching ships should take time and this will be filled with the player’s camera smoothly and automatically moving to the next ship the player will take control of. There will be some sort of smart decision programmed to choose the next best ship for the player, however the player will also be able to choose which ship to take control of. Players will only be able to take control of friendly fighters that aren’t being controlled by another human.

If a player, or group of players fail a mission, they will all lose a large amount of points, but will still be able to proceed to the next mission.

Multiplayer Coop Aspects

The main multiplayer aspect of the game will be cooperative play. All human players will be working together on the good side (Calenalph). Players will have all their same preference choices as in single player. The only difference between single player and multiplayer coop is that there are multiple human players on the good side, and that the game is played over the network.

Levels of Difficulty

The single player missions will progress in an increasing level of difficulty. Three different levels of difficulty will also be available for each mission. These levels of difficulty will simply alter the number of enemy fighters. The “Normal” difficulty level will not alter the enemy fighter count. The “Medium” difficulty level will have 120% the normal amount of enemy fighters, and “Hard” will have 150%.

16


Development Ideology

Computer programs are complex. Computer games – doubly so. As the complexity of a program increases, the harder it becomes to manage it. If not properly managed from the beginning, a program can quickly turn into a horrid creature that perhaps only one person knows what is going on, and that one person knows that they would be better off if they just dump everything and start over. In the effort to avoid this situation, all developers of this project should agree to the following ideologies so that this project may grow into a well-structured piece of art.

The game should be composed of several small and easily modified modules. Code that has been written rarely stays static. It often times needs to be fine tuned, altered, or completely redone. If some component is too large it may become difficult to maintain. Such components should be broken down into smaller and easier to maintain sub-components.

Modules should be more self-contained than dependent, or depended upon. If one module depends too much upon another, then it could easily be severely impaired in the event that the other module would be changed or deleted. Should that happen, it would then require approximately twice as much work to fix. The same applies if too many modules all rely on one central module.

The connections between modules should be simple and flexible. If some part of the program needs to be altered, the bonds between the effected modules should be able to bend to conform to the new structure. The connections between modules should also be simple enough to be altered or remade if such case may arise.

Start simple, and expand from there. Often our minds become clouded with wonderfully amazing ideas, technical advances, or other such delusions of grandeur. However, if one focuses solely on such a goal, they will undoubtedly create something that is inflexible and poorly built. A better approach is to determine the simplest form of the idea and build from that toward your goal with a solid base.

Hopefully in keeping with this ideology we can minimize the complexity of this project.

17


Coding Standards

Naming Conventions

FunctionsFunction names are lower-case words concatenated with underscores (_)Example: get_node()

Classes and StructsClass and struct names are all lower-case, directly concatenated words.Example: ddrawwrapper

VariablesVariable names are lower-case concatenated with upper-case letters.Example: currentNode

Member VariablesVariables that are members of a class are preceded with ‘m_’.Example: m_image

Function ParametersFunctions parameter variables are preceded with ‘p_’.Example: p_filename (note: ‘filename’ can be considered one word)

Global VariablesGlobal variables (excluding constants) are preceded with the word ‘the’.Example: theLog

Constants and Enum TypesConstants and the values contained in enums are all upper-case words concatenated with underscores (_)Example: MAIN_WIN_CLASS

Enumerations (Enums)Enumerations are lower-case with all words beginning with an upper-case character.Example: UnitType

Aliases

The following aliases and abbreviations should be commonly understood:ab.. – abstractAI – artificial intelligencebmp – bitmapBPP – bits per pixel

18


buf – bufferchar – charactercmd – commanddbl – doubledec – decrement / decreasedest – destinationfps – frames per secondinc – increment / increaseinit – initializeint – integer or interfacemax – maximummem – memorymin – minimummsg – messagenum, n.. – numberpos – positionpri – primaryptr – pointerreg – registerRGB – red, green, bluestd – standardstr – stringsrc – sourcesrf – surfacesys – systemtrans – transparentvp – viewportwin – window

Commenting

Code should be sufficiently commented, but does not need to be overly commented. Any person that has some understanding of C++ (and the English language) should be able to look at any piece of code and have some understanding of what it is supposed to do. Also remember that well named variables are also just as important to understanding code.

The only explicitly required comments are the function header, and the formatting at the top of header (.h) files. Function headers must contain the following information:

What the function is supposed to do.An explanation of the parameters.An explanation of the return value.The people (person) who understand the function, and have worked on it.A general list of what that function depends on (besides standard C/C++ stuff).

19


The status of the function, such as: being worked on, untested, stable, hacked, buggy, etc..After alpha is reached, the date of the most recent post-alpha change to the function.

This macro can be used to automatically insert a block for this…

Sub starfallFH()

'DESCRIPTION: Starfall method header commentActiveDocument.Selection.StartOfLineActiveDocument.Selection = "/*============================================================================" + vbLfActiveDocument.Selection = "Purpose: enter purpose" + vbLfActiveDocument.Selection = "Parameters: None" + vbLfActiveDocument.Selection = "Return: None" + vbLfActiveDocument.Selection = "Author: jlalone" + vbLfActiveDocument.Selection = "Depen: none" + vbLfActiveDocument.Selection = "Status: Incomplete" + vbLfActiveDocument.Selection = "----------------------------------------------------------------------------*/"

End Sub

The top of header (.h) files should be formatted in the following way:

// pre-definitionsclass newclass; (any objects that get declared after the project

includes)

// project includes#include "player.h" (header files that are part of the project)

// external includes#include <stdio.h> (header files that are not part of the project)

// leak checker#include "LeakCheck.h"#undef THIS_FILEstatic char THIS_FILE[] = __FILE__;/***********************************************************************/

(the rest is up to the coder)

Class Requirements

All classes must have the following methods declared. If a function is not implemented, then it must be placed in the private section of the class.

A default constructor A copy constructor Assignment operator for classes of the same type A destructor

20


Leak Checking

All files will use LEAK_CHECK to assist in debugging memory leaks. This is NOT optional. LEAK_CHECK outputs to the debug window all dynamically allocated memory that was still allocated when the program quits, including the file and line number that it was originally allocated and shows what is in the first several bytes. The lines required for leak checking are shown in the header comment above.

21


Graphics Engine

Rendering Information

The graphics engine will be built using Direct3D 9. It will support and enumerate all standard video modes over 640x480x16 and any refresh rate. The player will, at any time, be able to set the video mode and format during the runtime of the game. The menu system will always run at 800x600 for consistency and readability of the menu items. During mission load, the resolution will be switched to the player’s desired video mode.

Textures will be loaded in the resource bins and handled with the resource manager. Most of the time, we will not use multitexturing, however, in some circumstances, like the particles, multitexturing might be a solution to get the desired effect. Multitexturing is having multiple textures blended together on a single object. We can use multiple texture blending to apply textures, shadows, specular lighting, diffuse lighting, and other special effects in a single pass. If multitexturing is not supported on the video device, multiple rendering passes should be used. All textures, except for the screenobjects will be rendered with bilinear filtering. No texture should be larger than 512x512.

Lighting is simplified. We will only be using one directional light with soft ambient lighting. The direction vector and the color of the light should be varied mission to mission, specified by the mission file.

All in-game objects that can be rendered to the screen will be derived from the renderobject. All objects will be expressed using a left-handed co-ordinate system.

Hidden Surface Removal

For speed, we will only be doing view frustum culling for entire models in software, and will be relying on the depth buffer for all other hidden surface removal. The frustum culling can use the octree structure for extreme efficiency. If any octant of the octree is inside any part of the view frustum, then it will be marked as an octant that will not be culled. Any renderobject inside a culled octant volume will be culled. There will be colored linear fog in the far distance for a smooth falloff to the far clip plane. The far clip plane distance should be a console variable, so we can test values that produce a desired view distance without hindering performance.

22


Fast frustum culling using octree

Models/Meshes

Models will be stored in .x format, will use 32-bit textures for the materials, and initially only one texture per model. To improve performance on our target platform, which includes bottom-of-the-line 3D accelerators, we will be using progressive meshes for level of detail adjustments at different distances. Using 3D Studio Max, the artists will create and export the high-end, detailed meshes. DirectX Graphics, using the utility functions, automatically generates the progressive mesh. We will need a little algorithm for finding the correct level of detail to display for each mesh. With some tinkering, this should be a simple distance calculation from the camera to the object with a lookup into a table to get the percentage of vertices to display for the mesh. This might be a problem for different FOVs since the aspect ratio of the meshes on the screen is different, and this algorithm will require some fiddling to get the desired performance. For more information on progressive meshes see Game Programming Gems 1 – p.434 and p.454.

Skyboxes

Star field backgrounds will be textured skyboxes. A skybox is an inverted rendered box with the orientation of the camera being at the center of the box. If time permits, there should be a simple effect of a halo on the skybox if there is a sun in view. Skyboxes should make use of vertex buffers. The skybox textures should be stored in the texture resource bin.

Particle Systems

Particle effects will be used heavily throughout the game. The particle system manager should control all particle systems. It should be very easy for the user (programmer) to spawn and create the desired particle system. At a later date, March 21st, the effect document should be completed. This will be a list of all particle effects in detail and the way that they should be implemented. Each particle system will be derived off of a base particle system class, because every particle system has its own intricacies and

23

octant

renderobject

camera

View frustum

Non Culled Octant

Culled Octant


behaviors. For example, the lightning particle system for the YBMA weapon effect will behave differently than a ship explosion particle system. The particle system and manager should be very scalable, meaning that the player should be able to easily set the detail level or number of particles displayed on the screen at a time.

Shaders

Shader effects will be not used in the game. If we do opt to do shaders for some of the graphical effects down the road, we probably should use Microsoft’s HLSL. Possible uses of shader effects are: spherical environmental mapping, shield effects, and advanced particles.

24


Artificial Intelligence

The AI of allied and enemy units will be a finite state machine with fuzzy logic developed using a genetic learning algorithm. Most importantly, it needs to be able to control all the ships on both sides about equally well, so that with equivalent numbers of ships on either side of the battle, the battle will be roughly even. The AI will be able to lead its shots by a simple vector calculation, with a small % random error. Examples of simple states are attacking a target, evading an attacker (which is broken up into smaller sub-states, for different maneuvers), etc. The AI will also be able to communicate its “needs” with other AI’s and the player (if it is under attack and needs help, for instance) as well as responding to such signals.

AI will be implemented in classes derived by the ‘pilot’ class.

List of AIs

Calenalph Lakra fighter pilot AICalenalph Rivet Joint fighter pilot AICalenalph Starmover fighter pilot AIMorgwath Ricksaw fighter pilot AIMorgwath Bore Hunter fighter pilot AIMorgwath Jacknife fighter pilot AIHoming AI (for projectiles)Turret/Autoaim AICapital ship pilot AIMenu ship pilot AIRadio message selection AI (for decision of which radio messages to output to the user)

Collective Radio Memory (CRM)

The fighter pilot AIs will communicate with each other by a small set of simple radio messages. Whenever an AI wants to communicate a radio message, it will add it to the collective radio memory. The collective radio memory (CRM) is a list of all radio messages that have been sent in the last few seconds. Other AIs will read through this list, and decide if they wish to take some action on a particular message. Each radio message will have an auto-incrementing unique ID. Each AI will remember what message ID they last heard so that the next time they check the list, they will not listen to messages that they have already heard. The CRM will need to have an update function called periodically so that it may remove old radio messages.

25


Physics

The physics model used in Starfall will be mostly Newtonian based. Conservation of momentum will be used for collisions and debris from explosions. Ships will have a speed cap for gameplay reasons, but otherwise they will accelerate and turn as though they were ships with a large thruster on the back and smaller maneuvering jets along the rest of the ship to change its direction of motion to the direction it is pointing. Hence, if a ship rotates 90 degrees at full speed, it will take a couple seconds for it to lose all its speed in the previous direction. On the ships, players will not control any sort of throttle, but rather they will adjust a speed setting that the ship will always accelerate to as quickly as possible. The only way to accelerate faster is with the afterburner, which also increases the max speed cap while in use, and ignores the player’s set speed. Massless projectiles fired from the ship will have an initial velocity relative to the ship, and will not accelerate or decelerate.

Objects that use physics can have the following attributes:

position direction the object is “pointing”, for orientation purposes up vector for orientation target direction for sliding maximum and minimum target velocity settings acceleration for the target velocity magnitude maximum forward acceleration vector maximum magnitude for lateral acceleration (this is independent of sliding) maximum rotation rates for each axis maximum angular acceleration rates for each axis

Objects that can collide also have mass, which is used to determine collision response assuming completely elastic collisions.

Most objects will only be able to accelerate forward, decelerate, and turn. A few special objects, such as the Rivet Joint ship and the free-floating camera, will also be able to accelerate in any direction, which is called “sliding”.

26


Object Collision

With the large number of objects we will have in the game at once, it will be necessary to have a fast collision detection algorithm. We will be using octrees and bounding boxes to speed up collision detection. One possible problem that may result from using octrees occurs when the battlefield becomes very large with ships growing very far from the origin. This may result in a loss of performance if very many ships leave the octree boundary. Because of this, the octant sizes will increase linearly or exponentially from the center of the battle to keep distant objects in separate octants. Objects will also have axis-aligned bounding boxes to further reduce the necessity of expensive ellipsoid collisions.

All collision detection will be more fully defined by the March 21st engine proof. Currently, the collision pipeline looks like this:

Continue with all objects sharing octants

Do ellipsoid checks if the object Do spheretree checks for all other has shields objects

Note: All ellipsoid checks are prefaced by a bounding sphere check.

27

Octree culling

AABB collision check

spheretree check vs ellipsoid or spheretree

ellipsoid check vs ellipsoid or spheretree


Code Objects

Class Hierarchy for game objects

Object Storage

Objects will be stored in a variety of ways. A few will be stored in the globals class, but most will be stored in list within a manager class of its specific type, such as ships, projectiles, AI pilots, and particles.

There will also be a number of other storage devices for pointers to objects. There will be one list of all objects that are updated each frame, one list of all objects that can be rendered, etc. There will also be an octree system set up for all physical objects to help with collision detection.

The lists will be stored and managed by an object manager class. It will support two kinds of addition to the list; in the first, it will look at the type of the object and add it to the lists it belongs in. In the second, the default lists may be overridden by passing in Boolean values to the add function. However, the class will still check to see if these settings are valid and will only add the object to legal lists.

OctreesThe use of an octree will be required in Starfall to allow us faster access to highly

queried data and information throughout the course of the game. The octree will be used to provide us quick access for collision detection, finding of nearby objects, and frustum culling for hidden surface removal. The octree is set up as a tree of bounding volumes with 8 children nodes that themselves are also bounding volumes defining their own

28

object

screenobject

renderobject

particle

spatialobject

planet? asteroid?ship

capship playership

component

turret capweapon

projectile

skyboxphysical object

missile mine

particle system

input receiver

shield


octree structure. The octree is built, managed, and traversed recursively. A diagram of how the 3D environment is partitioned using the octree can be seen below:

The final partition of the octree makes up the leaves at the bottom, which contain a list of objects that currently reside within their bounding volume. All leaves contain a closed volume except for the leaves around the border of the octree, which extend out to infinity so that no object can move outside one of the octree leaves no matter how far it travels from view. Traversal of the tree which includes finding objects in the tree, modifying the objects in the tree, and adding objects to the tree all operate in log8(n) efficiency for an octree with n leaf nodes. We will most likely use an octree of depth 4 which will partition the entire 3D world into 4096 leaves or volumes.

object

PurposeThis class serves as a base class for every object with position, velocity, acceleration, etc.

Public methodsvirtual void update( float p_time );

This method moves the object and transforms its orientation according to its current state. Most children of this class will override this function, but still call this one to handle the motion.

virtual bool receive_input( Input p_enum, float p_fraction );

This method receives input from the direct input wrapper and processes it. Children of this class may override this function to take input not already handled here.

29


D3DXMATRIX & get_local_to_world_matrix( D3DXMATRIX * p_input );D3DXMATRIX & get_world_to_local_matrix( D3DXMATRIX * p_input );

These methods get matrices that can be used to transform to and from the object’s coordinate system to world coordinates.

In addition, there are a number of get and set functions for the acceleration and velocity of the object, as well as for rotation around each axis.

Implementation OverviewThe update method is the core of this class. It processes all of the motion variables, updates them, and sets the transformation matrices. The object class does not interact in any way with other objects; any such behavior must be defined in the child classes.

renderobject

familyobject->renderobject

PurposeThis is the base class for all objects which must be rendered.

Public Methodsvirtual void render( void );

This method will render the object. It is expected that this will generally be overloaded by the derived classes.

particlesystem

familyobject->renderobject->particlesystem

PurposeThe particlesystem class represents one group of particles, e.g. the particle trail

from a single ship.

screenobject

familyobject->renderobject->screenobject

PurposeScreen objects are any renderobject whose position is kept in screen co-ordinates

rather than world co-ordinates, such as hud graphics and menu items.

30


skybox

familyobject->renderobject->skybox

PurposeThe skybox class handles the pretty backgrounds as a skybox.

physicalobject

familyobject->renderobject->physicalobject

PurposeThe physical object class is the base class for anything that requires collision

detection. It also handles the other ‘physics’ of the game; including linear and rotational acceleration, velocity, and displacement.

Public Methodsbool check_collision_against( const physicalobject & p_other );

This method is used to determine whether two physicalobjects intersect. It will later be modified to return the intersection.

bool bounce( const physicalobject & p_other, ... );

This method will be used to force two physical objects to bounce off of one another.

Implementation OverviewThe physicalobject class stores the mass of the object it describes as well as the

collision data, so any collision detection and response must be handled here.

particle

familyobject->renderobject->physicalobject->particle

PurposeThe particle class represents individual particles within the game.

spatialobject

familyobject->renderobject->physicalobject->spatialobject

31


PurposeThe spatialobject class handles “terrain” in space, such as asteroids, which may

move and take damage but are not controlled by an AI and cannot act by themselves.

projectile

familyobject->renderobject->physicalobject->projectile

PurposeThe projectile class handles simple projectiles that fire at a constant velocity and

damage targets on impact.

ship

familyobject->renderobject->physicalobject->ship

PurposeThe ship class handles anything that may have an ai associated with it. Ships also

have shield and armor values, where the shield may be 0 for some objects. Finally, ships also have pointers to weapons that they may fire.

playership

familyobject->renderobject->physicalobject->ship->playership

PurposeThe playership class represents any ship that can be controlled by the player, as

well as enemy fighter ships. Playerships are associated with weapons, a model, and particle effects. They will always have an AI associated with them, although it will not have control while the player commands the ship.

capship

familyobject->renderobject->physicalobject->ship->capship

PurposeCapships represent large capital ships that cannot be controlled by the player.

Each capship is associated with a number of subcomponents and an AI.

32


missile

familyobject->renderobject->physicalobject->ship->missile

PurposeMissiles are objects launched from a ship or component that explode when shot or when they collide with a physical object, and damage that object. These also include mines, which can be implemented as a missile with a speed of zero.

component

familyobject->renderobject->physicalobject->ship->component

PurposeComponents are assigned to capships are represent individual things that can be damaged on the capship.

turret

familyobject->renderobject->physicalobject->ship->component->turret

PurposeTurrets are components that shoot at playerships. They are therefore associated with a weapon.

capweapon

familyobject->renderobject->physicalobject->ship->component->capweapon

PurposeCapweapons are components that shoot at capships.

weapon

Purposethe weapon class stores information about a particular weapon on a ship or turret. This includes information on fire rate, what projectile, missile, or mine is used, ammunition, hud icon (if applicable), exit position of the projectile/missile/mine, etc. It also stores a pointer to the object the weapon is mounted on in order to retrieve information about its position.

33


public Methodsvoid fire( void );

This method spawns a projectile according to the state of the weapon and of it’s object.

Sound

PurposeThe sound wrapper will be used to play streaming sounds such as music and static sound effects. It will have support for playing streaming compressed Ogg Vorbis sound files as well as static .wav files, and will have 3D sound capabilities.

Input / Interface

PurposeThe input and interface classes will process keyboard, mouse, and joystick input and interpret them according to the current state of the game.

Lists

PurposeThe list class implements a doubly-linked list and is the most common container we will use. It must be thread-safe.

Threads

PurposeThe thread class can be used to start and control new threads created by the program. The thread objects can then be given messages to do stuff, such as quit.

Settings

PurposeThe settings class stores settings loaded in from binary files at run-time. These will mostly be configuration settings and unit statistics.

Logger

PurposeThe logger will be used to output debug information to a file.

34


Time

PurposeThe time class will store time-related data such as the amount of time passed since the last frame, the amount of time since the program started, etc. It also will be used to handle the mission clock, which can be fed a start time in hours, minutes, and seconds and can update that time every frame.

Memory Manager

PurposeThe memory manager, used primarily by the lists, allows us to keep better track of the memory we use and can assist in debugging.

Camera Controller

PurposeThe camera controller class will handle camera movement and transitions from one position to another, and it will handle binding the camera to world objects.

Camera

PurposeThe camera class will be used to set up the view from different perspectives, such as from in the player’s ship or from “above” the battlefield.

Public Methodsset_state(camera::CAMERASTATE p_state);camera::CAMERASTATE get_state(void);

These methods get and set the camera state, which determines whether the camera is free roaming, following an object, attached to an object, stationary, following an object while looking at another object, in a cockpit, or in chase mode.

void look_at_object(object * p_obj);

This method sets an object for the camera to stay focused on.void attach_to_object(object * p_obj);

This sets an object for the camera to base its position on.

Console

PurposeThe console class will implement a command-line style interface that can be pulled up within the game to give a variety of commands to the game. It will be most extensively used for debugging purposes. One particular use of the console will be to set the amount of information that is logged by the logger, by setting different debug levels.

35


particlecontroller

PurposeThe particlecontroller class will manage the various particle systems, storing them and deallocating them when they are not in use.

36


Multiplayer / Networking

Network Layout

We will be using a client-server network layout, where one player’s computer updates the game state for all the other computers. Some tasks, however, such as AI and other tasks which only require periodic updates may be divided among computers if the processor load turns out to become too great. This will be determined by checking the AI behavior for variable numbers of ships. If there is a noticeable decrease in AI capability with fewer than 100 ships, then experiments will be performed to determine whether the increased network traffic is worth the processor cycles saved on the server.

The client and server are to be designed to both run simultaneously on the same machine. There will be no single-player only engine. The single player game will be run by the server module, and the network layer will short-circuit the packet layer to transfer data to the client module directly.

Client Server

World updates will be sent by a separate thread that loops through the list of objects, sending updates out where necessary. This thread only exists on the server, and only in a multiplayer game.

Network Protocol

We will be using UDP/IP for our networking, as TCP/IP would definitely prove too slow for the fast paced action our game will have. As a result, periodic partial game state updates will need to be sent, in addition to event messages. Examples of these are updating the exact position of ships, with more frequent updates for nearby ships, updates for shield/armor values, etc.

37

Game Data

network layer

world update thread

gamedata structuringpacket stuffingnetwork

gamedata structuringpacket stuffingnetwork


Packet StructurePacking will use little endian byte encoding. The first X bits of data (this value

will grow as we develop more messages) will always be the id code of the message being sent. The rest will be decided on a per message basis in order to compact as much information as possible, in the fastest manner possible.

Network MessagesAll messages will have a specific class associated with them. When sending data,

the program will fill out one of these classes with the appropriate information, and then use one of its methods to transmit the information. The classes will use their own methods for packing and unpacking data, so that we can maximize the packing capabilities of common packets, and to ensure that the right class receives the data. The actual transmission process should be transparent to the user.

Each of the clients will keep track of the information of the game world, and transmit actions to the server who will redistribute them along, with changes to the game world, to the other clients.

When transmitting information for actions, (such as firing a weapon) the client will assume the command to be true, and show the action on the screen. Then it will send the information to the server who will check the action to make sure that it is valid. If it is invalid (such as firing an empty weapon) then the server will send a failure message. If the action is valid, then the server will update the game world and transmit the action to the other clients.

If the client and server are on the same computer (checked by comparing ip addresses) then the game should use the exact same methods for transmitting methods as if they were on different machines. The message classes will discover this, and short-circuit the call to the transmission code. Instead it will notify the server as if he had just arrived by network receive code.

38


Game Control

Pre-mission

Program startsGlobals are initializedProcess the command line parametersStart the splash window thread (if game is in windowed mode only) BT

Load the main settingsInitialize the main windowInitialize 3DStart the thread to load the basic menu resources BT

Initialize input

39

Main Menus

Load mission, graphics, sound

Start Game Loop

Start AI threadsIf server, start world update thread

Retrieve input

Update All Objects

Render all renderobjects

Start Client and/or server threads

Send Events

Send Events


Initialize the game consoleKill the splash window thread if it is running KT

Enter the main loop

Do something while we’re waiting for the basic menu resources

Once we have the basic menu resources loadedStart the thread to load the background menu resources BT

Quickly transition to the menu system

Once the background menu resources have been loadedStart the thread to load the common game resources BT

Fade the menu background in under the menus (handled by the menus)

If goes into the multiplayer menuInitialize networkingDon’t bring up the multiplayer menu until networking successfully initializes

Once the user selects to start a missionStart the thread to load the mission briefing resourcesTransition to the mission briefing and loading screen

Once the mission briefing resources are availableStart the thread to load the mission resourcesBegin the mission briefing

Once all the mission resources have been loaded and the user has gone through the mission briefing

Start the game

40


Mission Handler

The mission handler is responsible for ensuring that missions load, begin, and run as they are designed. It loads all the objects in the mission into the object manager before the mission starts, storing pointers to special mission objectives in its own lists for quick access. It will then spawn a thread to check the status of all objectives periodically, and begin the mission. The threads that check completeness of objectives will be different for each mission. The mission handler will also check the time every frame to activate timed events.

41


Game Specific File Formats

Mission File Format

The mission file format will not be fully designed until the mission editor is underway. It will include types and positional data for all ships and other objects in the mission and flags to indicate mission objectives.

Settings File Format

The settings will be in a binary file format and can only be modified using the settings editor tool. The layout of the format is as follows:

# of data entries (4 bytes)

# of pages (4 bytes)

Page name length (4 bytes)

Name of the page (x bytes)

Page comment length (4 bytes)

Page comment(x bytes)

# of sub sections(4 bytes)

Sub section name length(4 bytes)

Sub section name(x Bytes)

Sub section comment length(4 bytes)

Sub section comments(x Bytes)

# of rows in the current subsection(4 bytes)

Name entry of current row length(4 bytes)

Name entry string(x Bytes)

Data type(1 byte)

[If data type is a string write the size of the string](4 bytes)

Actual Data(4 or x Bytes depending on type)

Length of row comment(4 bytes)

Row comments(x Bytes)

…

Model File Format

We will be using the .x file format for models, which is the standard Microsoft DirectX file format. .x files can be created with 3DStudioMAX.

Log File Format

Log files will be simple text files generated by the game, and will most likely be disabled in the final build. Their purpose is to assist in debugging.

42


Resource File Naming Conventions

The files will not change names between development and release.

Models

/root/models/

All models will be named with a prefix corresponding to the type of object that contains them.

particle: PAR spatial object: SPO screen object: SCR projectile: PRO ship: SHP missile: MSL capship: CPS mine: MIN playership: PSH component: CMP turret: TRT capweapon: CWP

Sound Effects

root/sounds/

Sound effects will also have the three-letter prefixes above, where applicable. When there are multiple sound files for a single effect, the files will have the same name with an incrementing numerical suffix.

Skybox Textures

root/textures/skybox/

Skybox textures will be named up#, down#, left#, right#, front#, back#, where # is the mission number that the skybox is used in.

43


Art and Video

Models

We will require a large number of 3D models for a variety of objects, in .x format. All fighter craft should be no more than 64 polygons each at long range. Missiles and other projectiles should be no more than 28 at long range. Capital ship subcomponents which number more than four per ship should be no more than 18 polygons at long range, and capitals ships as a whole should not be more than 400 polygons at long range. These numbers currently are fairly rough; we are aiming for a maximum of 2000 polygons on screen at one time, and this allows three capital ships, twenty fighters, 5 missiles, and 30 HUD items and billboarded projectiles. Even in a battle with four capital ships and 80 to 100 fighters, it is unlikely the player will have that many present on screen at a time. At close range, models will be allowed to have eight times that many polygons, though using fewer is strongly encourages. Models will be created in 3D studio max.

All models will be stored in a resource bin, so any object which contains a model actually just stores an index into a bin.

All models will be oriented such that the z-axis acts as their forward vector and the y-axis acts as their up vector.

Other Graphics

Two dimensional billboard objects, such as the items on the hud and small projectiles, as well as all of the menu graphics, will also be necessary. Particle effects will also be used within the game, and those will be created in 3D Studio Max.

Skyboxes will be composed of up, down, right, left, front, and back textures, 512x512 pixels, and stored in .tga format. This means a skybox will take up six megabytes of video RAM. Because of this, we may eventually need to put in alternate skyboxes using smaller textures later in the project, if performance degrades too much.

Memory Usage

With 6 MB used by the skybox, and another 6MB used for video and depth buffers, 20 MB remain to work with on the video card. This leaves enough memory for 74 256x256x32 textures, or 328 128x128x32 textures, which is more than enough for all models in the game. Using textures this large may still impact performance, however, so texture resolution is still to be minimized where possible. All models will have an accompanying text file with the same name except for the .txt extension containing a count of the memory used by the model and its accompanying textures, to simplify the

44


task of keeping track of video memory used, as well as the relative efficiency of the models. This .txt file will also contain vertex and polygon counts as well.

45


Sound and Music

Sound Effects

The sound effects used in the game will be in simple WAV format for speed. Sounds will be in a resource bin to prevent duplication in memory; anything that uses a given sound effect only needs the index of the sound. FMod will be used for playback and manipulation of sound effects, as well as for 3D sound effects. Static sound effects will be stored in hardware buffers where possible to reduce latency.

Music

Each of the soundtracks will be encoded using the Ogg Vorbis file format for compression. The soundtracks will be loaded and played using the FMod sound library, and will be streamed from system memory.

46


User Interface

Menu System

All of the menu objects (buttons, windows, and text fields) are different objects derived from the menuobject class. The menu systems will be in a windows-style format, and the “windows” will be a menupage object. A menupage will have a list of pointers to the menuobjects that are displayed in its window. It will relay input from the input wrapper to these subobjects based on the player’s current focus (the object currently in focus will be determined by keyboard/mouse input). Subobjects will store their own information, such as graphics, text (using a textstring object or a textstringlist object), and information an what to do when it receives input (such as ‘close the current window and open a new one’, or ‘start the game’).

Menu Objects: Page: Window that will house all of the other menu objects. Button: Will have graphical information for idle, mouseover, and clicked

states. They will contain information on actions to perform when clicked. Text Field: Box that the user can type in text to by selecting it as the current

focus. Text: Static text that does not have a box. Drop Down Box: Static text field that will drop down when given the focus,

and allow the user to select and option. It will display the selected option when not in focus.

Check Box: Boolean box that will change states when selected. Scroll Box: Drop Down Box that is always down. Has scroll through different

selections. History Box: Text Field that can drop down previous entries.

Heads Up Display (HUD)

The heads up display will consist almost entirely of static, 2D images stored in screen co-ordinates. The only exceptions to this should be the target camera, and the targeting reticule when in a 3rd person view. Graphical effects for the HUD include shaking, static, and a shield effect showing which direction a hit came from.

47


Console Commands

Additional console commands will be defined as the need arises.

Set – takes a page, subsection, and name of a setting and outputs the value of that setting. An additional parameter may be specified to alter the contents of the setting.

g_showfps 1/0 – toggles the frame rate display on and off. g_showtris 1/0 – toggles the tris count display on and off

48

[ digipen institute of technology ] · web viewideally, a simulation with the same number and types...

Documents