Villager Kisses
Technical Design Document
GAM400
Semester 7
DEVELOPMENT TEAM ............................................................................................................................ 5
VILLAGER KISSES: GAME OVERVIEW.............................................................................................. 6
HIGH CONCEPT ........................................................................................................................................... 6
TARGET AUDIENCE AND RATING ............................................................................................................... 6
GAME PLAY ................................................................................................................................................ 6
SYSTEM REQUIREMENTS ...................................................................................................................... 7
MINIMUM SYSTEM REQUIREMENTS............................................................................................................ 7
RECOMMENDED SYSTEM REQUIREMENTS .................................................................................................. 7
3RD PARTY TECHNOLOGIES .................................................................................................................. 8
DIRECTX 9 ................................................................................................................................................. 8
FMOD........................................................................................................................................................ 8
GAME CODE OVERVIEW........................................................................................................................ 9
CODE DEPENDENCY LAYERS ...................................................................................................................... 9
VILLAGER KISSES SUB-SYSTEMS ......................................................................................................10
Class: AutoList .....................................................................................................................................11
Class: Singleton ...................................................................................................................................12
Class: Handle ......................................................................................................................................13
Class: HandleRef .................................................................................................................................14
Class: RandomNumberGenerator ........................................................................................................15
KEY COMPONENT: GAME APPLICATION........................................................................................16
MODULE: GAME ........................................................................................................................................17
Class: GameMgr ..................................................................................................................................18
MODULE: USER INTERFACE .......................................................................................................................19
Class: MenuMgr ..................................................................................................................................20
Class: UI Object ..................................................................................................................................21
Class: Button........................................................................................................................................22
Class: ListBox ......................................................................................................................................23
Class: EditBox .....................................................................................................................................24
Class: SliderBar ...................................................................................................................................25
Class: Image ........................................................................................................................................26
Menu File Format ................................................................................................................................27
Class: KeyStrokeObject .......................................................................................................................28
Class: DropdownBox ...........................................................................................................................29
MODULE: COMMAND CONSOLE ................................................................................................................30
Class: CommandMgr ...........................................................................................................................31
Class: ParsedCommand.......................................................................................................................32
MODULE: OBJECT SYSTEM ........................................................................................................................33
Class: Object Manager ........................................................................................................................34
Class: Object........................................................................................................................................36
Class: Movement Grid .........................................................................................................................38
Class: Date Time..................................................................................................................................40
Class: Outdoor Weather ......................................................................................................................41
Class: Indoor Weather .........................................................................................................................42
Class: Outdoor Lighting ......................................................................................................................43
Class: Indoor Lighting .........................................................................................................................44
Class: Collision Volume ......................................................................................................................45
Class: Physics ......................................................................................................................................46
Class: Energy Calculator ....................................................................................................................47
Class: Inventory ...................................................................................................................................48
Page 1 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Path Finding .............................................................................................................................49
Class: Yeti Controller ..........................................................................................................................50
Class: Villager Controller ...................................................................................................................51
Class: Static Mesh................................................................................................................................53
Class: Dynamic Mesh ..........................................................................................................................54
Class: Particle System .........................................................................................................................55
MODULE: VILLAGE TERRAIN.....................................................................................................................56
Class: VillageMgr ................................................................................................................................57
Class: VillageTerrainPiece ..................................................................................................................58
MISCELLANEOUS APPLICATION CLASSES: .................................................................................................59
Class: MusicMgr ..................................................................................................................................59
Class: SoundFXMgr.............................................................................................................................60
Class: FXContentMgr ..........................................................................................................................61
Class: PathNameMgr ...........................................................................................................................62
Class: GameTime .................................................................................................................................63
KEY COMPONENT: GRAPHICS ............................................................................................................64
GRAPHIC OBJECT LIFETIME .......................................................................................................................65
USING D3DXEFFECTS FOR RENDERING ....................................................................................................66
PIXEL SHADER TARGETS ...........................................................................................................................67
RENDERING LOOP ......................................................................................................................................68
MODULE: DISPLAY MANAGER ..................................................................................................................69
Class: DisplayMgr ...............................................................................................................................70
MODULE: FX RESOURCE MANAGER .........................................................................................................71
Class: FXResourceMgr ........................................................................................................................72
Class: FXResource...............................................................................................................................73
MODULE: TEXTURE RESOURCE MGR ........................................................................................................74
Class: TextureResourceMgr ................................................................................................................75
Class: TextureResource .......................................................................................................................76
Class: TextureFileResource .................................................................................................................77
Class: TextureHLSLResource ..............................................................................................................78
Class: TextureRenderTargetResource .................................................................................................79
MODULE: VERTEX BUFFER MANAGER ......................................................................................................80
Class: VBResourceMgr ........................................................................................................................81
Class: VBResource...............................................................................................................................82
Class: DynamicVBResource ................................................................................................................83
MODULE: INDEX BUFFER MANAGER .........................................................................................................84
Class: IBResource ................................................................................................................................85
Class: IBResource ................................................................................................................................86
Class: DynamicIBResource .................................................................................................................87
MODULE: ANIMATED MODELS ..................................................................................................................88
Class: ModelMgr .................................................................................................................................89
Class: ModelHandle ............................................................................................................................90
Class: ModelResource .........................................................................................................................91
MODULE: TEXT MANAGER ........................................................................................................................92
Class: TextMgr ....................................................................................................................................93
Class: Text ...........................................................................................................................................94
MODULE: SCENE GRAPH ...........................................................................................................................95
Class: SceneMgr ..................................................................................................................................96
Class: ObjectNode ...............................................................................................................................97
Class: ObjectNodeHandle....................................................................................................................98
MODULE: RENDER MANAGER ...................................................................................................................99
Class: RenderMgr ..............................................................................................................................100
MODULE: QUAD MANAGER.....................................................................................................................101
Class: QuadMgr ................................................................................................................................102
Class: Quad .......................................................................................................................................103
Page 2 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
MODULE: PARTICLE MANAGER ...............................................................................................................104
Class: ParticleMgr.............................................................................................................................105
Class: ParticleSystemInitializer ........................................................................................................106
Class: ParticleSystem ........................................................................................................................107
Class: Particle ...................................................................................................................................108
MISCELLANEOUS GRAPHICS CLASSES .....................................................................................................109
Class: Render To Texture ..................................................................................................................109
Class: FXConstant .............................................................................................................................110
Class: RenderableGeometry ..............................................................................................................111
KEY COMPONENT: AUDIO .................................................................................................................112
Class: AudioMgr ................................................................................................................................113
Class: AudioData ...............................................................................................................................115
Class: AudioDataHandle ...................................................................................................................116
KEY COMPONENT: INPUT ..................................................................................................................117
Class: InputMgr .................................................................................................................................118
PROJECT MILESTONES .......................................................................................................................119
MILESTONE: IMPLEMENT FXCONTENT AND FXCONSTANTS, FXRESOURCE, AND FXOBJECT CLASSES..120
MILESTONE: IMPLEMENT RENDERABLEGEOMETRY SET OF CLASSES ......................................................121
MILESTONE: IMPLEMENT RENDERMGR ...................................................................................................122
MILESTONE: IMPLEMENT A PROCEDURAL TEXTURING AND MODELING LIBRARY ..................................123
MILESTONE: VILLAGE TERRAIN ..............................................................................................................124
MILESTONE: VILLAGE OBJECT PLACEMENT ............................................................................................125
MILESTONE: VILLAGE LIGHTING .............................................................................................................126
MILESTONE: VILLAGE TERRAIN TEXTURING ...........................................................................................127
MILESTONE: ICE REFLECTION GRAPHICS EFFECT....................................................................................128
MILESTONE: MODEL LOADING AND TEXTURING.....................................................................................129
MILESTONE: MODEL ANIMATION ............................................................................................................130
MILESTONE: MODEL INSTANCING ...........................................................................................................131
MILESTONE: PARTICLE MANAGEMENT FRAMEWORK..............................................................................132
MILESTONE: PARTICLE DRAWING ...........................................................................................................133
MILESTONE: PARTICLE FUNCTIONALITY DEFINITIONS ............................................................................134
MILESTONE: PARTICLE SYSTEM DEFINITIONS .........................................................................................135
MILESTONE: SCENE MANAGER ...............................................................................................................136
MILESTONE: GAMEMGR STRUCTURE ......................................................................................................137
MILESTONE: UI STRUCTURE....................................................................................................................138
MILESTONE: UI PARSING ........................................................................................................................139
MILESTONE: UI OBJECTS ........................................................................................................................140
MILESTONE: GAMEMGR FINALE .............................................................................................................141
MILESTONE: UI FINALE ...........................................................................................................................142
MILESTONE: UI TEMPLATES ....................................................................................................................143
MILESTONE: DROPPING ITEMS ................................................................................................................144
MILESTONE: BURNING ITEMS ..................................................................................................................145
MILESTONE: GRILL AND MELT ITEMS .....................................................................................................146
MILESTONE: TIME SYSTEM .....................................................................................................................147
MILESTONE: WEATHER SYSTEM .............................................................................................................148
MILESTONE: DISPENSE ITEMS .................................................................................................................149
MILESTONE: ENERGY SYSTEM ................................................................................................................150
MILESTONE: COLLISION ..........................................................................................................................151
MILESTONE: PATH FINDING ....................................................................................................................152
MILESTONE: VILLAGER SURVIVAL ..........................................................................................................153
C++ SOURCE CODE SYNTAX RULES ................................................................................................154
HLSL AND FX SOURCE CODE SYNTAX ...........................................................................................155
Page 3 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
MENU SKIN SPECIFICATION .............................................................................................................156
Page 4 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Development Team
Name
Title
Development Tasks
Ryan Juckett
Designer
AI and Game Objects
Lewis Mohr
Product Manager
Gilberto Rosado
Technical Director
Alexander Van Berg
Producer
Graphics, Scene Graph,
and User Interface
Graphics, Terrain, and
Render Manager
Graphics, Audio, Input,
Text, Models
Signatures
Ryan Juckett
_____________________________________
Gilberto Rosado
_____________________________________
Lewis Mohr
_____________________________________
Alexander Van Berg
_____________________________________
Page 5 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Villager Kisses: Game Overview
High Concept
Villager Kisses is a social strategy game in which the user must physically persevere and
socially flourish in a villager community.
Target Audience and Rating
Villager Kisses has a target audience of teenage males and females. Its focus on social
interaction will help it appeal to both of the sexes. Similar to the target audience, Villager
Kisses has a target rating of “Teen” due to its potentially more mature implications.
Game Play
You, an ordinary everyday Villager, have been appointed by Kisskimo, the Villager
cupid, to spread joy throughout your village. It is your mission to maintain as many
friendships as possible with your fellow village members, and you have luckily been
promised rewards for showing progress in this task. At first, it seems that it should be
easy enough to be friendly and nice to your neighbors, but you soon learn that they are
not fond of sharing your friendship with others. Their jealousy runs deep into the
village’s social network and you are only able to achieve your goal through spreading lies
and manipulating your friends.
While you may be cold hearted enough to take advantage of others, you definitely don’t
have much time to do so. There is so much to be done during the day in order stay
healthy, and without your health, there will be no one willing to talk to you. Constantly
getting hungry and thirsty, you must cook above the fire at home, but what are you to
cook? Only by gathering wood to start a fire and finding some fish to cook over it, can
you satisfy your need for food. You probably also need to grab some snow for melting
while you are out, but if you stay outside too long in a storm you might freeze. You may
fear the cold at first, but it’s the yetis that thrive in the wilderness that will truly scare you
away.
Having once lived the simple Villager life, it will take time to adjust to your new
situation. Once working to survive alone, and perhaps maintain a friendship here and
there, you now must support yourself and as many friends as possible. You can only hope
that the rewards you receive as you progress up the ranks of society will allow you
impress you friends with fancy presents and a fresher look of health on your face.
Page 6 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
System Requirements
Minimum System Requirements







Operating System: Windows 98/ME/2000/XP
Video: NVIDIA GeForce 2 or ATI Radeon 7500 with 32MB VRAM
Processor: 1GHZ Intel Pentium or AMD Athlon
Memory: 128MB
Hard Drive Space: 60MB free hard disk space
Audio: Windows compatible sound card
DirectX: DirectX 9 runtime and video card drivers
Recommended System Requirements







Operating System: Windows 2000/XP
Video: ATI Radeon 8500/9600/9800 or NVIDIA GeForce 4 TI 4200/FX 5900
Processor: 1.8 GHZ Intel Pentium or AMD Athlon XP 1700+
Memory: 256MB
Hard Drive Space: 60MB free hard disk space
Audio: Windows compatible sound card
DirectX: DirectX 9 runtime and video card drivers
Page 7 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
3rd Party Technologies
DirectX 9
Creator:
Microsoft
Available at: http://microsoft.com/windows/directx/
Usage:
The game’s 3D renderer will be based on Direct3D9. The D3DX9 library
will be used extensively for vertex and pixel shaders using Microsoft’s High Level
Shading Language (HLSL), and mesh animation.
DirectInput8 will be used for keyboard and mouse user controls.
FMOD
Creator:
Firelight Technologies
Available at: http://www.fmod.org/
Usage:
FMOD is a platform independent audio engine. It supports 3d sound, midi,
mods, mp3, ogg vorbis, wma, aiff, recording, obstruction/occlusion, cd playback, mmx,
internet streaming, dsp effects, spectrum analysis, user created samples and streams,
synchronization support, ASIO, EAX 2&3.
Page 8 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Game Code Overview
Code Dependency Layers
The code project for Villager Kisses has three layers of dependencies. The bottommost
layer is composed of the sub-systems, a collection of common code dealing with data
containers, memory management, math classes, and general helper code. The second
layer consists of the Graphics, Audio, and Input systems. These systems are designed to
be generic and are not meant to have any game-specific code. The third and topmost layer
is the Application layer. The Application layer consists of all game-specific code
including game-play, artificial intelligence, and game objects.
Figure 1: The Relationship between the main code components.
Page 9 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Villager Kisses Sub-Systems
The Villager Kisses Sub-Systems are a collection of helper classes and functions in the
project. These classes are available for use to any part of the game project, and their
usage is encouraged to help unify the coding styles and implementations of the different
programmers in the project.
Use of the C++ Standard Template Library (STL) is also strongly encouraged to be used
by the programmers of the Villager Kisses project. The STL defines many ready to use
containers and algorithms. Documentation on the STL can be found in the MSDN library,
the Internet, and countless C++ books.
Page 10 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: AutoList
Description: The AutoList design pattern is used when a list of all instances of a class is
desired. If a class inherits from AutoList, all instances of that class are inserted to the list
as they are created, and are removed when they are destroyed.
Public Interface:
Function Names
GetAutoListBegin
GetAutoListEnd
GetAutoListCount
Description
Returns an iterator to the first element of the list.
Returns the end iterator of the list.
Returns the number of elements in the list.
Usage: A class that desires AutoList functionality inherits from the AutoList class. For
example:
class ListMe : public TAutoList< ListMe >
{
};
When a user wishes to iterate through all instances of the ListMe class, they ask for the
Begin and End iterators.
//get begin iterator
list<ListMe*>::type::iterator it_beg =
AutoList<ListMe>::GetAutoListBegin( );
//get end iterator of all of the windows
SS::list<ListMe*>::type::iterator it_end =
AutoList<ListMe>::GetAutoListEnd( );
SS::list<ListMe*>::type::iterator it;
//for all of instances
for(it = it_beg ; it != it_end; ++it)
{
}
Page 11 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Singleton
Description: The Singleton design patter is used when there should only be one instance
of a class.
In this implementation the user can get a reference to the Singleton object by calling the
static Get( ) Function.
Public Interface:
Function Names
Initialize
Unintialize
Is_Initialized
Get
Description
Creates the Singleton.
Destroys the Singleton.
Returns true if the Singleton is currently initialized.
Returns a reference to the Singleton.
Usage: To create a Singleton class, derive from Singleton. For example:
Class MakeMeSingleton: public Singleton<MakeMeSingleton>
{
};
Page 12 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Handle
Description: Handles are used when more than one pointer needs to reference the same
object. By using handles, the user need not worry about deleting the memory it is
referencing because once the referenced object’s internal reference count reaches zero, it
will automatically be deleted.
In the Villager Kisses project, the handle class is used in conjunction with the HandleRef
class. See the documentation of the HandleRef class for an example of using the Handle
and HandleRef classes.
Note:
In this document, when it is mentioned that a Handle is being used or passed back from a
function, it is assumed that it’s an object derived from the Handle class.
Requirements:
 Must properly interact with the referenced object to keep the correct referenced
count.
 Must overload the appropriate copying operator and constructors to ensure the
proper reference count at all times.
Public Interface:
Function Names
Is_Valid
Relase
Reference
Description
Returns true if the handle is currently referencing an object.
Releases the handle, decreases the reference count of the object
formerly being reference.
Sets the object being referenced by the handle.
Implementation Details: The Handle class may only reference objects that derive from
the HandleRef class.
Page 13 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: HandleRef
Description: Classes of objects that need to be referenced counted should derive from
the HandleRef template class. HandleRef objects are referenced by objects derived from
Handle.
Requirements:
 Must properly keep track of its reference count
Public Interface:
No public interface
Usage:
A class that needs to be referenced is defined in the following manner:
class ReferenceMe : public HandleRef<ReferencedMe>
{
};
The corresponding Handle class is defined as shown below:
class HandleToReferenceMe : public Handle<ReferenceMe>
{
}
The handle is used as follows:
HandleToReferenceMe handle;
handle.Reference( new ReferenceMe ); //get a handle
//do stuff with handle
handle.Release( ); //done using the handle, release it
Page 14 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: RandomNumberGenerator
Description: RandomNumberGenerator serves as a base class for classes implementing
random number algorithms. Several child classes are implemented in the project.
Requirements:
 Separate instances of RandomNumberGenerator classes must provide separate
streams of numbers. Specifically, getting a random number from one object
should not affect the next random number returned from another object.
Public Interface:
Function Names
Seed
Rand
Description
Seeds the random number generator algorithm.
Returns a random number.
Page 15 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Key Component: Game Application
Description: The Game application component implements game specific features.
Modules in the Game Application include the GameMgr, which is responsible for
transitioning the game from the title-screen to the menus and then to the actual gameplay.
Modules:
 Game Manager
 User Interface
 Command Console
 Object System
 Village Terrain
Page 16 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Game
Description: Handles the more general aspects of the game, such as state changes,
loading screens, etc.
Dependencies: Not directly dependant on any modules, but will be calling functions
from several modules, including the ObjectMgr.
Classes:
 Game Manager
Page 17 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: GameMgr
Module: Game Manager
Description: Handles state transitions between menus and game.
Requirements: Handle state transitions between menus and game.
Public Interface:
Function Names
Update
Render
Description
Update all active modules in the current state.
Render all active modules in the current state.
Implementation Details: The GameMgr is a state machine with 3 major states, Intro,
Menus, and Game. Each one of these has 3 minor states, Loading, Normal, and Exiting.
As of the current design, this would use a flexible coded design using function pointers or
derived classes.
Page 18 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: User Interface
Description: Load up scripted menu files to display the user interface in the game.
Functionality will be included in the script files, as strings to be executed through the
Command Manager.
In the event that executing commands through the CommandMgr is not sufficient
for our purposes, it is designed such that adding specific derived types is very easy.
Dependencies: Command Manager, Quad Manager
Classes:
 MenuMgr
 UI Object
 Button
 ListBox
 EditBox
 SliderBar
 Image
 Keystroke
 DropdownBox
Page 19 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: MenuMgr
Module: User Interface
Description:
Requirements: Load, Update and Draw menus.
Public Interface:
Function Names
LoadMenuTree
Update
Draw
Set/GetActiveObject
Description
Load up the descriptor file, and a menu file, and recursively
load up all referenced menus in that file.
Update the active menu.
Draw the active menu.
Gets/Sets a Boolean as to whether or not there is an active
object. Used primarily for edit boxes and dropdown boxes
to avoid conflicts with other objects in the menu.
Implementation Details: The script files look similar to XML, each object is delimited
by angle brackets, and each object block starts with the type of the object. Please see the
Menu File Format specification section for more details.
The system for active objects allows multiple objects to be active at a given time, but this
is mainly so that objects can be constantly active, such as the mouse cursor, or something
animating. In general, there will only be one active object that can be directly interacted
with.
Page 20 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: UI Object
Module: User Interface
Description: An abstract base class for all UI Objects.
Requirements: Allow Update and Render to be called on this object.
Public Interface:
Function Names
Update
Render
SetAsActiveObject
IsActiveObject
Description
Pure Virtual.
Pure Virtual.
Sets a Boolean that this object is active.
Retrieves the Boolean as to whether or not this object is active.
Page 21 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Button
Module: User Interface
Description: A simple click-to-use button.
Requirements: Highlight when moused-over, depress when clicked, activate when
released.
Public Interface:
Function Names
Update
Draw
Description
Update the logic for this object.
Draw this object to the screen.
Implementation Details: The button stores a list of strings to be executed in the
CommandMgr when the button is activated, as well as a string with a CommandMgr
command executed to gain the new value to update itself with.
The button class contains four Image UI Objects.
State Machine:
Disabled:
Button is grayed out.
No Events
Normal:
MouseOver  Highlighted
Highlighted:
Button changes appearance to become brighter, etc.
MouseDown  Selected
!MouseOver  Normal
Selected:
Button changes appearance to become pressed.
!MouseOver  Normal
!MouseDown  Execute String Data  Normal
Page 22 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: ListBox
Module: User Interface
Description: ListBox is derived from UI Object, and contains a SliderBar object.
Requirements: Allow the user to select from a scrollable list of items.
Public Interface:
Function Names
Update
Draw
Description
Update the logic for this object.
Draw this object to the screen.
Implementation Details: Contains 3 Image UI Objects
State Machine:
Disabled:
No events
Normal:
MouseOver  Highlighted
Highlighted:
Active item is highlighted, moused-over item is highlighted in different color.
!MouseOver  Normal
MouseDown  Selected
Selected:
Only the moused-over item is highlighted.
!MouseOver  Normal
!MouseDown  Set var to current value.  Normal
Page 23 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: EditBox
Module: User Interface
Description: Derived from Button. Allows the user to enter text.
Requirements: Support deletion of characters, random access into the string, string
length limits, flashing cursor.
Public Interface:
Function Names
Update
Draw
Description
Update the logic for this object.
Draw this object to the screen.
Implementation Details: Stores an internal String_C8
State Machine:
Same as Button, except for the Selected State:
Selected:
Keystrokes  Add to internal string.
Escape Key  Revert to previous value.
Enter, or MouseClick outside of box  Execute String  Normal
Page 24 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: SliderBar
Module: User Interface
Description: Allows the user to specify a range between 0 and 1.
Requirements: Click and drag the slider, click on bar to move slider by 1/10th, output
floating-point value.
Public Interface:
Function Names
Update
Draw
Description
Update the logic for this object.
Draw this object to the screen.
Implementation Details: Uses a float from 0-1, but scales by value specified in file. File
also specifies a flag as to whether or not the slider is horizontal or vertical (vertical is
default).
Contains 4 Image UI Objects
State Machine:
Disabled:
No Events
Normal:
MouseOver  Highlighted
Highlighted:
!MouseOver  Revert to previous value  Normal
MouseDown  Selected
Selected:
!MouseDown  Execute string to set value.
!MouseOver  Revert to previous value  Normal
Mouse is over slider  Move Slider
Mouse is over bar  Move Slider 1/10th of bar towards cursor.
Page 25 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Image
Module: User Interface
Description: Displays a static image.
Requirements: Display a static image.
Public Interface:
Function Names
Update
Draw
Description
Nothing.
Draw this object to the screen.
Implementation Details: Stores a texture handle and a position on the screen. Can be
parsed as one of two different ways:
Single – Standard method, image is stretched to fit rectangle.
Grid – Image is split into 9 equally sized squares, where the corners are never
scaled, the vertical edges are only scaled vertically, the horizontal edges are only scaled
horizontally, and the center is scaled to fill the box. This is used for edit boxes and other
objects to avoid distortion of the edges when scaling.
State Machine:
No events are accepted by this object.
Page 26 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Menu File Format
Objects are allowed to be nested.
All parameters that are not applicable to the parent object are ignored.
See the Appendix for a list of all applicable parameters for objects.
A .mnu file contains one or more of the following:
<
Type :
BaseName
// : BaseName is optional
// Double slashes denote a commented line
// All fields hereafter are optional
// These are the valid object non-specific parameters
ObjectName = “ObjectName”
// Params go here, Example:
HitBox = ( x, y, w, h )
InitialState = 0
Image = “GlowingButton.bmp”
Page 27 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: KeyStrokeObject
Module: User Interface
Description: Performs an action based on one or more keystrokes. This has no physical
appearance.
Requirements: Specify multiple keystrokes; execute a string in CommandMgr when
anyone is pressed.
Public Interface:
Function Names
Update
Draw
Description
Update the logic for this object.
Nothing.
Implementation Details: Stores a list of DIK_* codes.
State Machine:
Disabled:
Nothing
Normal:
KeystrokeDown  Selected
Selected:
KeystrokeUp  Execute String  Normal
Page 28 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: DropdownBox
Module: User Interface
Description: Allows the user to select a single item from a variably sized list.
Requirements: Dynamic addition and removal of items.
Public Interface:
Function Names
Update
Draw
Description
Update the logic for this object.
Nothing.
Implementation Details: Derived from Button, this contains a ListBox and a SliderBar.
State Machine:
The same as a ListBox, except that in Selected, it is displayed as a list box rather
than a button.
Page 29 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Command Console
Description: The purpose of this module is to tokenize a text string and call the
associated function. Example: The string “SetAttraction Suzy 10” would be tokenized
and the SetAttraction function would be called with the parameters “Suzy” and “10”,
both as strings.
Dependencies: String
Classes:
 CommandMgr
 ParsedCommand
Page 30 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: CommandMgr
Module: Command Console
Description: Manage commands given by UI objects and the Console.
Requirements: Given a string, tokenize and pass to the appropriate function.
Public Interface:
Function Names
RegisterCommand
UnregisterCommand
AppendCommand
InsertCommand
ExecuteCommand
Update
Flush
SetPauseTime
Description
Insert the command name / function pointer pair into the map.
Remove the command name / function pointer pair from the
map.
Add the string to the end of the list of commands to be
executed.
Add the string to the front of the list of commands to be
executed.
Parse the given string and send to the appropriate function.
Parse a number of commands from the list based on how much
time has passed.
Remove all commands from the command buffer.
Increments the internal time to wait before executing the next
command.
Implementation Details: The function pointer required by the CommandMgr is void
function that takes in an STL list of String_C8s. Each element of this list is one of the
arguments. Initially, an STL map will be used to associate commands with function
pointers. This may be changed later in development if something more efficient is
needed. The command buffer is an STL list, and during Update, the first few commands
are executed and removed from the list.
There is one default command, “wait <seconds>”. This is primarily used for
scripting, as it will set a delay before the next command is executed. It is implemented in
the same way as other commands; a global non-member function called
WaitCmdHandler is defined, and it converts the first argument to a float, and then calls
the SetPauseTime (float) function of the CommandMgr. The Update function of the
CommandMgr then decrements this timer and will not execute the next command until it
hits zero.
Tokenizing the string is done without modifying the original string, and is copied
into new strings as tokens are found. The space, comma, tab and new-line are all used as
delimiters. If a double quote is used, then the rest of the tokens are read as one token until
the end quote is found. For example, “I’m a “DigiPen Student”” would be tokenized to
“I’m”, “a”, “DigiPen Student”. Delimiters are not included in the tokenized strings.
Page 31 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: ParsedCommand
Module: Command Console
Requirements: Store all of the variables needed to execute a command after parsing.
Public Interface:
Function Names
No member functions
Description
Implementation Details: This class stores a list of arguments and the command name.
Page 32 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Object System
Description:
The object system maintains the responsibility of controlling the game-play portion of the
application.
Dependencies:
 Display Library
 Audio Library
 Input Library
 Back End Library
Classes:
 Object Manager
 Object
 Movement Grid
 Date Time
 Outdoor Weather
 Indoor Weather
 Outdoor Lighting
 Indoor Lighting
 Collision Volume
 Physics
 Energy Calculator
 Inventory
 Path Finding
 Yeti Controller
 Villager Controller
 Static Mesh
 Dynamic Mesh
 Particle System
Page 33 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Object Manager
Module:
Object System
Description:
The object manager sits at the highest level of the object system. When the application
enters the game-play state, it will instruct the object manager to either load a village from
file or create a new village. The application will then tell the object manager to update
and draw as needed until it is time to exit the game-play state. Upon exiting the gameplay state, the object manager will be appropriately told to destroy its village.
Requirements:
 Manage all objects in existence as part of a village.
 Be able to save the entire state of a village to a file.
 Be able to load the entire state of a village from a file.
 Be able to draw the environment containing the active object.
 Track the time in the current village.
Public Interface:
Function Names
Load village
Save village
Create village
Destroy village
Get Village
Create object
Update
Draw
Set active object
Get active object
Description
Destroy the current village, and load a village from a given
file.
Save the village currently in the manager to a given file.
Create a new village from scratch with a given village name
and given user-controlled Villager settings.
Destroy the current village. This process includes the
destruction of all objects contained within the village.
Get a handle to the current village
Create a new object of a given type with a parent
corresponding to a given handle.
Update the objects after a given logic time has elapsed. The
update process will only update the village object. This will
then perform a preorder traversal of the object tree by each
object updating is child objects.
Draw the objects at a given offset in logic time from the
previous update. When drawing, only the parent object of
the active object is told to draw. If the active object has no
parent, then only the active object is told to draw. Note that
when an object draws, it will execute draw calls on all of its
children in a preorder tree traversal.
Set the active object for user viewing and control to a given
object handle.
Get a handle to the active object for user viewing and
Page 34 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
Set village time scale
Get village time scale
GAM400
Semester 7
control.
Set the scale of village time relative to logic time.
Get the scale of village time system relative to logic time.
Implementation Details:
The object manager maintains a handle to the village object, a handle to the active object,
and a camera. The village object will serve as the root node of the object tree. All objects
used in the game will be reference a single time in the object tree and, therefore, the tree
can be safely used for object traversal. When a village is created for the first time or
loaded from file, it will contain handles to all of its child objects which will contain
handles to their children and so forth.
The active object is used to determine how the object system should interact with the
user. All information displayed on the user interface will be relative to the active object,
and the camera used to render the world is always tracking the active object. In a release
version of the game, the active object should only ever be set to the user-controlled
Villager, but during the development process, it can be toggled between any object for
debugging purposes.
When updating, the village object is passed in the logic time elapsed scaled by the village
time scale. The scale can be set to zero to pause the village time.
Page 35 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Object
Module:
Object System
Description:
The object class has the ability to contain any type of object in the game, and is
referenced through object handles created in the object manager.
Requirements:
 Store all required types of objects in the game.
 Check for data component support.
 Access supported data components.
 Check for action component support.
 Access supported action components.
Public Interface:
Function Names
Get type
Update
Draw
Supports data
Supports action
Fails target action
conditions
Initiate target action
Get parent object
Description
Get access to the identification value of this object’s type.
Update all data components that can be updated.
Draw all data components that can be drawn.
Check if this object’s type (and thus this object) supports a
data component with a given identification value.
Check if this object’s type (and thus this object) supports an
action component with a given identification value.
Check if any conditions for initiating an action supported by
a target object through that target object would fail given the
current states of the this object and the target object.
Initiate an action supported by a target object through that
target object.
Access a handle to this object’s parent object.
Implementation Details:
The objects are stored using a data and action component system. There is no actual
derivation tree of object types that create different classes. Every object is stored in the
same class and contains an identification value that determines its type. Tables are then
used to determine what components each object type supports. Components are split into
actions and data. For example, a grill would support actions a “cook fish” action, and a
“food transformer” data type.
Each object also has the ability to link to a parent object. The parent object determines
the space in which the child exists. The only object that does not need a valid parent in
order to be managed by the object system is the village. While all objects can be children,
not all objects can be parents. Some objects such as the village, an igloo, or a villager
Page 36 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
(through the use of its inventory) support data types that can contain a list of child
objects. Only these objects that can reference children are allowed to be parent objects.
Each object needs to contain an array of pointers to allocated data types that it supports.
A table is used to determine how far to index indo an objects data array to access a
supported data type. These data types can range anywhere between a single character and
a complex class.
Actions do not need to be stored within each object because they consist solely of
functionality that operates on given objects. Actions are initiated by an initiator object
through a target object. The action must be supported by the target object. For example, if
a villager wants to a cook fish on a grill, the Villager is the initiator, the grill is the target,
and the grill supports the action. Note that the initiator object does not need to support the
action.
In addition to actions needing to be supported by the target object of the initiation
process, actions also contain a list of requirements that need to be checked at runtime to
see if they can validly be executed. For example, if a villager wants to a cook fish on a
grill, the Villager needs to be carrying a fish that it can cook.
Action requirement functions are split into two main categories: single object and dual
object. Single object requirement functions can be given any object in existence to
perform their tests on. Dual object requirement functions must be given two objects in
existence to perform their tests on. In addition to the function, a requirement must also
specify whether it requires the function true or false. Note that the list of requirements is
always concatenated with a Boolean AND. This means that all of the requirements must
be met.
Each action type has a set of requirement function lists that must be met. Each list
corresponds to different set of input objects to be given to the requirement functions. List
will exist, for the initiator object, the initiator object’s inventory object, the initiator
object together with the target object, and so forth. An example of a single object
requirement function is checking if the object supports a given data component type, and
an example of dual object functions is checking if the distance between the two objects is
within a given range.
Page 37 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Movement Grid
Module:
Object System
Description:
The movement grid class is an object data component that provides the object with the
ability to provide a surface that child objects can exist in and move around on.
Requirements:
 Store a height map aligned to a square grid structure.
 Store a spatially partitioned list of all children.
 Perform collision tests requested by dynamic children.
 Update the child objects when this object is updated.
 Draw the child objects in view when this object is drawn.
Public Interface:
Function Names
Set edge vertex count
Get edge vertex count
Set edge logical size
Get edge logical size
Set vertex
Get vertex
Predict location
Check collision
Enumerate Objects In
View
Insert Child
Move child
Remove Child
Update
Description
Set the number of vertices that are stored on an outer edge
on the grid.
Get the number of vertices that are stored on an outer edge
on the grid.
Set the logical size of an outer edge on the grid. This is the
distance between to corner vertices of the entire grid that
share the same edge, and can be used to calculate the
distance between adjacent vertices in the two dimensional
grid plane.
Get the logical size of an outer edge on the grid.
Set the parameters of an indexed grid vertex.
Get the parameters of an indexed grid vertex.
Predict the location of a given dynamic object on the grid
after a given amount of time. This will calculate collisions
with the grid.
Check for the first collisions between a given dynamic
object on the grid and another object on the grid given a line
segment that will be traversed over a given mount of time.
Enumerate all of the objects that can be seen through a
given view frustum. An invalid handle will be used in the
case where no such object exists. This functionality will be
most useful to the yeti controller class.
Insert a child into the grid at a given location.
Move a given child object to a new location in the grid.
Remove a child from the grid.
Update all the child objects.
Page 38 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
Draw
GAM400
Semester 7
Draw all of the child objects in view.
Implementation Details:
The movement grid stores a square, two-dimensional array of vertex heights. The
movement grid uses a quad tree to store its child object handles. This tree is then used to
perform collision and display culling. When performing physics calculations, the normal
to the grid plane is considered to point in the opposite direction of gravity, and all
complex interpolations will be done using a fourth order Runge-Kutta integrator.
Page 39 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Date Time
Module:
Object System
Description:
The date time class is an object data component that provides the object with the ability
to track a current date and time of its space.
Requirements:
 Track and update date and time information.
Public Interface:
Function Names
Set Date
Get Date
Set Time
Get Time
Update
Description
Set the date to a given value.
Get the stored date.
Set the time to a given value.
Get the time.
Update the time given an amount of logic time that has
elapsed.
Implementation Details:
This class tracks year, month, day, hour, minute information where all values are stored
as integers except for minutes which is a floating-point value. When updating, the current
time is advanced appropriately.
Page 40 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Outdoor Weather
Module:
Object System
Description:
The outdoor weather class is an object data component that provides the object with the
ability to track an outdoor weather system.
Requirements:
 Be able to calculate temperature, cloud coverage, snowfall, wind speed and wind
direction based on the village name, date, and time.
Public Interface:
Function Names
Calculate weather
Draw
Description
Calculate all of the current weather conditions based on the
village name, and the current date and time.
Draw the snowfall.
Implementation Details:
When calculating weather for a given time, two weather conditions are calculated for the
day sections surrounding the given time. These two endpoints are then interpolated to get
the current weather conditions.
Page 41 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Indoor Weather
Module:
Object System
Description:
The indoor weather class is an object data component that provides the object with the
ability to track an indoor weather system.
Requirements:
 Calculate a temperature based on the temperature of a parent object.
Public Interface:
Function Names
Calculate Temperature
Description
Calculate the environments temperature by increasing the
temperature stored by the object’s parent’s weather system.
Implementation Details:
The process of calculating this object’s temperature based on a parent object’s
temperature consists of simply adding a constant temperature offset to it. The object will
also check for any child fuel burners such as a fire to perform additional temperature
modifications.
Page 42 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Outdoor Lighting
Module:
Object System
Description:
The outdoor lighting class is an object data component that provides the object with the
ability to track an outdoor lighting system.
Requirements:
 Calculate a light direction and color based on the time of day.
Public Interface:
Function Names
Calculate lighting
Description
Calculate the lighting conditions based on the current time
of day.
Implementation Details:
When calculating lighting conditions for a specific time, the conditions are calculated for
the surrounding day segments and then the calculated conditions are interpolated.
Page 43 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Indoor Lighting
Module:
Object System
Description:
The indoor lighting class is an object data component that provides the object with the
ability to track an indoor lighting system.
Requirements:
 Calculate a light color based on the time of day.
Public Interface:
Function Names
Calculate lighting
Description
Calculate the lighting conditions based on the current time
of day.
Implementation Details:
When calculating lighting conditions for a specific time, the conditions are calculated for
the surrounding day segments and then the calculated conditions are interpolated.
Page 44 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Collision Volume
Module:
Object System
Description:
The collision volume class is an object data component that provides the object with the
ability to collide with other objects in a shared parent object’s movement grid.
Requirements:
 Store an axis aligned box.
Public Interface:
Function Names
Set collision box
Get collision box
Description
Set the object’s bounding box.
Get the object’s bounding box.
Implementation Details:
The collision box is stored as a minimum point and maximum point relative to the
position of the object.
Page 45 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Physics
Module:
Object System
Description:
The physics class is an object data component that provides the object with the ability to
function within the dynamic physics system of its parent object.
Requirements:
 Be able to update position and linear velocity within the parent object’s
movement grid.
 Be able to update orientation and angular velocity within the parent object’s
movement grid.
Public Interface:
Function Names
Set mass
Get mass
Set linear velocity
Get linear velocity
Set inertial tensor
Get inertial tensor
Set velocity
Get velocity
Update
Description
Set the mass.
Get the mass.
Set the linear velocity.
Get the linear velocity.
Set the inertial tensor matrix.
Get the inertial tensor matrix.
Set the angular velocity.
Get the angular velocity.
Update the object’s position, orientation, linear velocity, and
angular velocity within the parent object’s movement grid
over an elapsed amount of time.
Implementation Details:
The parent object will requested to perform physics integration on this object.
Page 46 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Energy Calculator
Module:
Object System
Description:
The energy calculator class is an object data component that provides the object with the
ability to calculate an energy level based on the environment and actions performed
within it.
Requirements:
 Calculate health values based on attribute values and need values.
 Calculate energy values based on health values.
Public Interface:
Function Names
Set attributes
Get attributes
Set needs
Get needs
Set health
Get health
Set energy
Get energy
Update
Description
Set the attribute levels.
Get the attribute levels.
Set the need levels.
Get the need levels.
Set the health levels.
Get the health levels.
Set the energy levels.
Get the energy levels.
Update the health and energy levels over an elapsed time
span taking into account the current state of the object.
Implementation Details:
When updating the energy levels, the health values will require a simple integration of
time, but the energy values need to be integrated over time using the health integration in
order to get accurate results over any amount of elapsed time.
Page 47 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Inventory
Module:
Object System
Description:
The inventory class is an object data component that provides the object with the ability
to carry another object.
Requirements:
 Store an inventory object as a child object.
 Update the inventory object when updated.
 Draw the inventory object when this object is drawn.
Public Interface:
Function Names
Set Object
Get Object
Update
Draw
Description
Set the inventory object handle. Supplying an invalid handle
will remove the object.
Get the inventory object handle.
Update the child object.
Draw the child object.
Implementation Details:
When an object is placed in this object’s inventory, its position must be adjusted to be
relative to this object’s position so that is drawn to look like it is being carried.
Page 48 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Path Finding
Module:
Object System
Description:
The path finding class is an object data component that provides the object with the
ability to find paths to set locations while avoiding collisions.
Requirements:
 Efficiently calculate paths for movement from the objects current position to a
desired position.
Public Interface:
Function Names
Set Destination
Update
Get Path Segment
Description
Set a new destination to calculate a path for.
Update the current path based on our current position and
destination
Get the remaining direction and distance in the current path
segment.
Implementation Details:
When generating a path, an A-Star algorithm will be used across the movement grid. As
paths starting points and destinations are changed, the pre-generated portions of the
current path will be reused if possible.
Page 49 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Yeti Controller
Module:
Object System
Description:
The yeti controller class is an object data component that provides the object with the
ability to be automatically controlled to function as a yeti.
Requirements:
 Wander aimlessly outside of the igloo circle by default.
 Attack Villagers when found.
Public Interface:
Function Names
Update
Description
Update the thought process of the yeti after an elapsed
amount of time. This will result in the yet deciding what
future actions need to be performed.
Implementation Details:
When a yeti is wandering, it will periodically choose a new destination to walk to and
change its course accordingly. Once a villager enters a yeti’s view, the yeti will run after
the Villager while the Villager remains in view. Once the Villager leaves the yeti’s view,
the yeti will return to wandering with its current wander destination set to where it last
saw the Villager.
Page 50 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Villager Controller
Module:
Object System
Description:
The Villager controller class is an object data component that provides the object with the
ability to be automatically controlled to function as a villager.
Requirements:
 Maintain health levels.
 Maintain a single strong friendship.
 Collect extra resources if possible.
 Maintain minor secondary friendships if possible.
Public Interface:
Function Names
Update
Description
Update the thought process of the Villager after an elapsed
amount of time. This will result in the Villager deciding
what future actions need to be performed.
Implementation Details:
Villagers try to manage their tasks into a standard schedule based on the time of day. In
the morning, Villagers prefer to wake up, eat and drink food that was gathered the
previous afternoon, and mingle with other village members. During the afternoon,
Villagers try to gather resources to make food and water to have during the evening and
the next morning. When evening arrives, Villagers have their second meal of the day and
try to advance their strong friendship. Finally, Villagers will tend to sleep during the
night.
When performing tasks, the daily schedule may slightly waver between Villagers due to
task priorities. Priorities are used to relate importance levels to spending energy on
certain actions. The number one priority that a villager has is to perform actions that will
result in maintaining its health such as gathering resources to cook. The second priority
of a villager is to advance its desired strong relationship. It is through the completion of
this task that challenge will be provided to the user. Two tasks are tied for a villager’s
third priority, and a villager’s attributes will determine which one is more important.
Villagers with a higher body attribute will tend to gather more resources that can later be
used or given as gifts. Villagers with a higher mental attribute will tend to be more social
while trying to maintain minor secondary friendships. If a villager starts to get off track
of its daily schedule, it will only worry about ensuring that its highest prioritized tasks are
accomplished until it manages to get back on track.
Weather conditions also play a large role on how Villagers will act on different days. As
the weather gets worse, Villager’s will tend to remain indoors and perform more social
Page 51 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
interaction. As the weather gets better, travel to the resource locations will be safer and
faster so Villagers will tend to gather more resources.
The final component of Villager control is determining emotional attraction levels
towards other village members. Every time a new event is added to a villager’s memory,
any other Villagers that are referenced by the event will have their attraction levels
modified. Events that help this Villager’s chances of achieving its prioritized tasks will
increase this Villager’s attraction levels towards the appropriate Villagers involved in the
event. Events that hurt this Villager’s chances of achieving its prioritized tasks will
decrease this Villager’s attraction levels towards the appropriate Villagers involved in the
event.
Page 52 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Static Mesh
Module:
Object System
Description:
The static mesh class is an object data component that provides the object with the ability
to draw a static mesh as its visual representation.
Requirements:
 Draw a static mesh at the object’s location.
Public Interface:
Function Names
Set mesh
Draw
Description
Set the mesh that needs to be drawn.
Draw the mesh.
Implementation Details:
The internal storage will consist of a handle to an actual static mesh in the display library.
Page 53 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Dynamic Mesh
Module:
Object System
Description:
The dynamic mesh class is an object data component that provides the object with the
ability to draw an animated mesh.
Requirements:
 Draw an animated mesh at the object’s location.
 Handle body animations separate from facial expressions.
Public Interface:
Function Names
Set mesh
Transition to animation
Transition to face
Update
Draw
Description
Set the mesh that needs to be drawn.
Transition to a different body animation.
Transition to a different facial expression.
Update transitions and animations after an elapsed amount
of time.
Draw the mesh at an offset in time from the previous
update.
Implementation Details:
The internal storage will consist of a handle to an actual animated mesh in the display
library.
Page 54 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Particle System
Module:
Object System
Description:
The particle system class is an object data component that provides the object with the
ability to draw a particle system.
Requirements:
 Draw a particle system at the object’s location.
Public Interface:
Function Names
Set particle system
Update
Draw
Description
Set the particle system that needs to be drawn.
Update the particle system after an elapsed amount of time.
Draw the particle system at an offset in time from the previous
update.
Implementation Details:
The internal storage will consist of a handle to an actual particle system in the display
library.
Page 55 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Village Terrain
Description: Responsible for creation and drawing of the game village (map or level).
Dependencies: DisplayMgr, TextureResourceMgr, FXResourceMgr, GeometryObject
Classes:
 VillageMgr
 VillagePiece
Page 56 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: VillageMgr
Module: Village Terrain
Description: The village manager creates a randomly generated village based on the
village name. The VillageMgr stores all of the procedurally generated geometry for the
village and so it is responsible for drawing the village terrain.
Requirements:
 Create the village.
 Create and place all static objects in the village; this includes trees, rocks, igloos,
the forest, the snow mine, and the ice fishing hut.
Public Interface:
Function Names
LoadVillage
CreateVillage
DrawVillage
Description
Loads a village from file.
Creates a new village.
Draws the village.
Implementation Details: The village terrain is broken up into pieces. During drawing, a
range of terrain pieces is drawn depending on the camera’s location.
Page 57 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: VillageTerrainPiece
Module: Village Terrain
Description: A village terrain piece is a square section of the larger village terrain. By
splitting up the terrain into sections, it becomes easier to assign different looks to
different parts of the level.
Requirements:
 Store a list of texture handles used to texture the terrain.
 Store an FX Handle used for rendering the terrain piece.
 All pieces should be the same dimensions.
Public Interface:
Function Names
Init
Draw
Description
Initializes the terrain piece height data, and texture coordinates.
Draws the terrain patch to the screen.
Page 58 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Miscellaneous Application Classes:
Class: MusicMgr
Module: Music Manager
Description: MusicMgr is a singleton class that abstracts the specifics about soundtrack
resources (filename for example). The clients in the application will play music for the
game through this manager by using enum values instead of actual filenames. In addition,
it will provide optional play-list functionality.
Requirements:
 Load and save audio handles for all songs in the game. This data will be specified
in a text file.
 Map the audio handles to enum values for the clients to reference.
 Provide different methods for interaction with the audio handles for the client to
choose from.
 Provide optional play-list functionality. This includes storing a list, or multiple
lists of songs to be played in order.
Public Interface:
Function Names
GetAudioDataHandle
AdjustMusic
AdjustMusicVolume
LoadPlayList
AdjustPlayListState
Description
Returns a handle to a song. This is
preferable for looping songs.
Plays music from inside the manager
instead of returning a handle to the client
for him to utilize.
Sets the default volume for all music
playing now and in the future.
Accept a list of songs to play in order. Give
the client a handle to a play-list.
Start, pause, unpause, or start a play-list.
Page 59 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: SoundFXMgr
Module: SoundFX Manager
Description: SoundFXMgr is a singleton class that abstracts the specifics about audio
file resources (filename for example). The clients in the application will play sound
effects through this manager by using enum values instead of actual filenames.
Requirements:
 Load and save audio handles for all sound effects in the game. This will be
specified in a text file.
 Map the audio handles to enum values for the clients to reference.
 Provide different methods for interaction with the audio handles for the client to
choose from.
Public Interface:
Function Names
GetAudioDataHandle
AdjustSoundEffect
AdjustSoundEffectsVolume
Description
Returns a handle to a sound effect. This is preferable
for looping sound effects.
Plays a sound effect from inside the manager instead
of returning a handle to the client for him to utilize.
Sets the default volume for all sound effects.
Page 60 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: FXContentMgr
Description: The FXContentMgr’s purpose is to abstract specific .fx file names from the
application. An enumeration of values representing specific graphic effects, called FX
IDs, will be exposed to the application and the FXContentMgr will map those values to
specific FXObjects. FX IDs are used so that objects to be rendered do not have to specify
specific file names when specifying their render states, instead they can specify a
descriptive enum value.
Requirements: Given an FX ID, must return a handle to the appropriate FXObject. Each
FX ID must have a corresponding FXObject and .fx file.
Public Interface:
Function Names
GetFXHandle
Description
Given an FX ID, returns a handle to the corresponding FXObject.
Implementation Details: The FXContentMgr stores an array of handles to FXObjects,
which are allocated during the game’s initialization. FXObject handles are kept in
memory for the duration of the game.
Page 61 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: PathNameMgr
Description: The PathNameMgr encapsulates the directory structure used by the game,
so users don’t have to worry about what directory a particular data file is located in.
Users wishing to a load file will call the PathNameMgr to get the full path to the data file
that is to be loaded.
Requirements: A set of resource type identifiers must be exposed to the application;
these identifiers include:
 Textures
 Models
 Sound effect files
 Music files
 FX files
Given a resource type identifier, the class must provide the path to the corresponding
directory. Different builds of the game may require different resources, so the
PathNameMgr must be able to choose a different set of paths for different builds of the
game.
Public Interface:
Function Names
GetFullPath
Description
Given a file name string and a resource type identifier, it will return
the full path to the file.
Implementation Details: The actual paths may be stored in an external data file instead
of having the paths hard-coded in the game.
Page 62 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: GameTime
Description: Provides the application a timer object that is based on game-play time, as
opposed to real-world time. Separating real-world time from game time is crucial to keep
the game-play consistent from machine to machine.
Using game-time makes the slowing down or fast-forwarding of game-play trivial, which
can be useful for debugging purposes. It is also convenient when setting break points in
the debugger, because pausing the application can mess-up calculations based on time.
Requirements: Game Timers must be able to:
 Pause.
 Return the time elapsed since the last reset.
 Reset time elapsed to zero.
Public Interface:
Function Names
Update
GetTimeElapsed
GetMillisecondsPassed
IsActive
SetActive(bool)
Description
Called once every frame, it updates the timer by the input
value.
Returns the amount of time (using floats where 1.0 = 1
second).
Returns the time in milliseconds.
Returns true if the timer is not paused.
Pause timer with false, activate it by passing in true.
Implementation Details: Game Timers are to use the AutoList design pattern. Every
game update, the list of timers is iterated and updated with the time elapsed since the last
game update.
Page 63 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Key Component: Graphics
Description: The graphics component is responsible for the 3D and 2D rendering
necessary in the game. It abstracts the rendering of objects as well as graphics resources
such as textures and vertex buffers.
Modules:
 Display Manager
 FX Resource Manager
 Texture Resource Manager
 Vertex Buffer Manager
 Index Buffer Manager
 Animated Models
 Text Manager
 Scene Graph
 Render Manager
 Particle Manager
Miscellaneous Classes:
 Render to Texture
 FXConstant
 Renderable Geometry
Page 64 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Graphic Object Lifetime
When using Direct3D, resources that reside in video memory are subject to be lost in the
case that the Direct3D device is in the lost state, such as when it loses focus or another
Direct3D application assumes full-screen operation. When the Direct3D device is lost, a
call to Direct3DDevice::Reset( ) must be performed before resuming normal operation.
This is why this process is sometimes referred to as resetting the device.
It is necessary for the application to invalidate all graphic resources prior to resetting the
device and they must be recreated or restored after the device has been reset. Because of
this, all graphic resources in the Villager Kisses project must be allocated by a manager
class. These resource management classes provide only handles to their clients, and are
responsible for properly handling their graphic resources during a device reset. Allocation
of any Direct3D graphic resource that needs to be invalidated and restored when the
device is lost without using a resource manager is forbidden.
The following Managers allocate graphic objects for use by the project:
 Texture Resource Manager
 Vertex Buffer Resource Manager
 Index Buffer Resource Manager
 Model Manager
 FX Resource Manager
Page 65 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Using D3DXEffects for Rendering
All rendering in the Villager Kisses project will use the D3DXEffect interface to ensure
the proper render states are set prior to rendering an object and restored after the object is
rendered.
A D3DXEffect is defined in an external file with the .fx extension. This file may define
multiple techniques that may be used to render an object. Depending on the capabilities
of the machine, different techniques may be chosen. For example, for a machine with a
video card that does not support pixel shaders, a technique targeting the fixed function
pipeline may be used; similarly, on a machine capable of pixel shader version 2.0, a
technique that renders the object using a pixel shader may be chosen. The D3DXEffect
interface allows you to validate a technique prior to using it so you can be sure that it is
using features that are supported by the machine in which the game is running on.
All Direct3DDevice render, texture stage, and alpha blend states may be defined inside of
a technique. This frees the development team from implementing a render state manager
to ensure that the proper states are set prior to rendering an object.
Vertex and Pixel Shaders may also be defined in an .fx file and used by a technique.
Either High-Level Shading Language (HLSL) or Shader Assembly Language may be
used.
The D3DXEffect framework also allows the user to define shared variables that may be
used by multiple D3DXEffect objects. A practical use of this feature would be the current
light direction and color. This variable could be changed once and it would affect all
D3DXEffect objects referencing the variable.
Throughout this document, the concept of the D3DXEffect interface is often referred to
as FX, because of the .fx files. This is why the manager for D3DXEffect objects is called
the FXMgr.
For more information and official documentation on the D3DXEffects and their
capabilities, see the DirectX9 Summer Update SDK.
Page 66 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Pixel Shader Targets
Villager kisses will support a minimum of two graphics hardware targets:
 Fixed-Function Pipeline video cards (No programmable pixel shaders).
 Pixel Shader 1.3 capable video cards.
Some graphic effects may not be implemented for fixed-function pipeline, in which case
a base rendering technique will be used. When implementing rendering techniques in .fx
files, the technique should specify its pixel shader target through an annotation. Shaders
targeting PS 1.4 or PS 2.0 hardware may be implemented, but PS 1.3 is preferred because
of the higher number of machines that support it.
Page 67 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Rendering Loop
Objects to be draw will be determined by a scene graph class. The scene graph will
determine the order that objects should be drawn to the screen. It will then ask the
Rendering Module, called the RenderMgr, to render the object. The Scene Graph will
specify the geometry and FX ID of the object. The FX ID corresponds to a D3DXEffect
object previously allocated by the application. Given this information, the RenderMgr
had enough information to render the object to the screen.
Object Rendering
Scene Graph first sorts a graph of all objects, first by FX ID, then by Geometry ID.
For every FX Node
Scene Graph stets
active FX ID
Render Manager
stores active FX ID
For every Geometry
Node
Scene Graph Sets
the active
Geometry Object
Render Manager sets active
Geometry Object, calls it's
PreDraw( ) function
For every Object Node
Scene Graph calls the
Render Manager to
Draw each leaf object
Render Manager gets shader
specific parameters from the
Object, calls active Geometry
Object's Draw( ) function
Page 68 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Display Manager
Description: The Display Manager encapsulates Direct3D’s display device interface,
IDirect3Ddevice.
Dependencies: Direct3D
Classes:
 DisplayMgr
Page 69 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: DisplayMgr
Module: Display Manager
Description: Encapsulates the Direct3D device.
Requirements:
 Create device in full screen and windowed mode.
 Be able to switch between full screen and windowed mode at runtime.
 Handle Alt + Tab.
 Handle desktop display mode changes while in windowed mode.
 Store the capabilities of the machine, such as pixel shader version.
Public Interface:
Function Names
Create
Destroy
GetDevice
ResetDevice
ToggleFullScreen
StoreDesktopResolution
GetBackBufferFormat
GetWidth
GetHeight
GetDeviceCaps
GetVertexProcessingType
GetPixelShaderVersion
Description
Creates the D3D device.
Releases the D3D device.
Returns a pointer to the D3D device.
Handles a display device reset.
Goes from full screen to windowed and vice versa.
Stores the desktop resolution, call when you get a
WM_DISPLAYCHANGE message.
Returns the format of the back buffer.
Returns the width of the back buffer.
Returns the height of the back buffer.
Returns the D3DCAPS of the device.
Returns the vertex processing type, software, hardware, or
mixed mode.
Returns the pixel shader version supported by the device.
Page 70 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: FX Resource Manager
Description: Allocates and manages any FX resources in the game. FX files are files
used by ID3DXEFFECT, and they are files used to specify how to render a 3D object.
User stores FX
Resource
Handles
FXMgr allocates
FXResource and
passes back handle
FXResource
Figure 2 Relationship between the FXMgr, its clients and the FXResourceObjects
Dependencies: Display Device, Vertex Buffer Manager, Index Buffer, and Texture
Manager
Classes:
 FXResourceMgr
 FXResource
Page 71 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: FXResourceMgr
Module: FX Resource Manager
Description: Allocates and manages FX resources.
Requirements: Allocate any FX resources needed by the game. Only one instance of an
FX is allowed. For example, two clients that request an effect of the same file name
should get the same handle.
Public Interface:
Function Names
CreateFXFromFile
CreateFXFromFileInMemory
InvalidateAll
RestoreAll
Description
Creates from file on disk.
Creates from file in memory.
Prepares all FX objects for a device reset.
Restores all FX objects after a device reset.
Implementation Details:
Page 72 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: FXResource
Module: FX Resource Manager
Description: Encapsulates the ID3DXEFFECT class
Requirements: Properly handles the lifetime of the ID3DXEFFECT objects
Public Interface:
Function Names
Init
Invalidate
Restore
Delete
SetFileName
SetFXData
GetFileName
GetFXData
GetResource
GetActiveTechnique
Description
Initializes the FXResource.
Prepares for a device reset.
Restores object after device reset.
De-allocates the FX Resource.
Sets the name of the fx file to use, only takes effect after a call
to Init.
Set with an fx file in memory.
Returns the name of the underlying .fx file.
Returns pointer to .fx file in memory.
Returns the underlying D3DXEffect object.
Returns the handle to the best technique available that will run
the current machine.
Implementation Details: The FXResource uses the D3DXEffect interface and exposes it
to the user.
Page 73 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Texture Resource Mgr
Description: The Texture Resource Mgr is responsible for allocating textures resources
for the game. Its other main responsibility is to make sure all of the game’s texture
resources are recreated successfully during a D3D device reset.
Dependencies: DisplayMgr
Classes:
 TextureResourceMgr
 TextureFileResource
 TextureHLSLResource
 TextureRenderTargetResource
Page 74 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: TextureResourceMgr
Module: TextureResourceMgr
Description: The texture resource manager allocates texture resources. It passes handles
to texture resources to its clients. The resource manager will pass back the same handle to
two users that request the same texture.
On a device Reset, it is responsible to do the necessary work to make sure that all textures
are valid after the reset.
The Texture Resource Mgr can allocate textures from file, textures from HLSL
procedural functions, and render target textures.
Requirements:
 Allocate any texture resources needed by the game.
 Handle a device reset for all of the texture resources.
Public Interface:
Function Name
Description
GetTextureFromFile
GetTextureFromHLSLFile
Passes back a handle to a texture from file resource.
Returns a handle to a texture from HLSL function. The
D3D_TEXTURE_TYPE be a rectangular, cube, or
volume texture. The width, height, and depth of the
texture can be specified in the function call, or in the
HLSL file.
Returns a texture mean to be used for rendering into
instead of the back buffer.
Prepares all resources for a device reset.
Restores all resources after a device reset.
GetTextureRenderTarget
InvalidateAll
RestoreAll
Page 75 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: TextureResource
Module: TextureResourceMgr
Description: Base class for all texture resources
Requirements: Define a common interface for all texture resources.
Public Interface:
Function Names
GetResource
Init
Invalidate
Restore
Delete
GetTextureType
SaveTexture
GetWidth
GetHeight
GetTextureFormat
Description
Returns a pointer to a D3DbaseTexture.
Initializes the resource.
Prepares resource for a device reset.
Restores the texture after a display device reset.
De-allocates the texture resource.
Returns either rectangular, cube, or volume texture type.
Saves the texture to disk.
Returns width of texture.
Returns the height of the texture.
Returns the D3DFORMAT of the texture.
Page 76 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: TextureFileResource
Module: TextureResourceMgr
Description: Resource class to textures loaded from file.
Requirements: Makes a texture from a file on the disk.
Public Interface: Inherits from TextureResource.
Function Names
SetFileName
GetFileName
Description
Sets the name of the file to use for this resource.
Returns the name of the file associated with this resource.
Implementation Details:
Page 77 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: TextureHLSLResource
Module: TextureResourceMgr
Description: Resource class for textures made from HLSL functions.
Requirements: Makes a texture from a procedural HLSL function.
Public Interface: Inherits from TextureResource.
Function Names
SetFileName
GetFileName
Description
Sets the name of the file to use for this resource.
Returns the name of the file associated with this resource.
Implementation Details: Uses the D3DXFillTextureTX set of functions to fill the
texture and the D3DXEffect Interface for extracting parameters from file.
The file containing the function can be used to specify the type of texture (rectangular,
cube, or volume) as well as the width, height or depth of the texture by using annotations.
Below is an example HLSL file defining a procedural texture for a simple texture:
//Red.hlsl
float4 RedTexture(float3 pos:POSITION):COLOR
{
return float4(1,0,0,1);
}
int RedTextureDesc //use annotations to specify texture parameters
<
string function = "RedTexture";//entry point
string type = "rectangular";
int width = 128;
int height = 128;
>;
Page 78 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: TextureRenderTargetResource
Module: TextureResourceMgr
Description: Resource class for render target textures.
Requirements: Makes a texture that is to be rendered into.
Public Interface: Inherits from TextureResource.
Function Names
SetFormat
Description
Sets the D3DFORMAT associated with this texture.
Page 79 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Vertex Buffer Manager
Description: The Vertex Buffer Manager is responsible for creating and managing all of
the vertex buffer resources needed by the game.
Dependencies: DisplayMgr
Classes:
 VBResourceMgr
 VBResource
 DynamicVBResource
Page 80 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: VBResourceMgr
Module: Vertex Buffer Manager
Description: Allocates and manages the lifetime of any vertex buffers needed by the
game.
Dynamic vertex buffers are meant to be locked and filled once every frame. Their
memory is not restored on a device reset, only reallocated.
Requirements: Must handle managed and dynamic vertex buffers.
Public Interface:
Function Names
CreateVB
CreateDynamicVB
InvalidateAll
RestoreAll
Description
Returns a handle to a vertex buffer.
Returns a handle to a dynamic vertex buffer.
Prepares all resources for a display device reset.
Restores all resources after a display device reset.
Implementation Details: Every vertex buffer is assumed unique, therefore no two
handles reference the same vertex buffer resource.
Page 81 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: VBResource
Module: Vertex Buffer Manager
Description: The vertex buffer resource class.
Requirements: Encapsulates a managed vertex buffer.
Public Interface:
Function Names
Init
Invalidate
Restore
Delete
SetFVF
GetFVF
SetNumVertices
GetNumVertices
SetVertexSize
GetVertexSize
GetResource
Lock
Unlock
Description
Initializes resource.
Prepares resource for a display device reset.
Restores a resource after a display device reset.
Releases the resource.
Sets the Flexible Vertex Format of the vertex buffer, only takes
effect after a call to restore.
Returns the FVF of the vertex buffer.
Sets the number of vertices in the vertex buffer, only takes
effect after a call to restore.
Returns the number of vertices in the vertex buffer.
Sets the size of a single vertex, only takes effect after a call to
restore.
Returns the size of a single vertex in the buffer.
Returns a pointer to the D3DVERTEXBUFFER.
Locks the vertex buffer.
Unlocks the vertex buffer.
Implementation Details: Uses the D3DVERTEXBUFFER type.
Page 82 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: DynamicVBResource
Module: Vertex Buffer Manager
Description: The dynamic vertex buffer resource class
Requirements: Encapsulates a dynamic vertex buffer
Public Interface:
Function Names
Init
Invalidate
Restore
Delete
SetFVF
GetFVF
SetNumVertices
GetNumVertices
SetVertexSize
GetVertexSize
GetResource
Lock
Unlock
Description
Initializes resource.
Prepares resource for a display device reset.
Restores a resource after a display device reset.
Releases the resource.
Sets the Flexible Vertex Format of the vertex buffer, only takes
effect after a call to restore.
Returns the FVF of the vertex buffer.
Sets the number of vertices in the vertex buffer, only takes
effect after a call to restore.
Returns the number of vertices in the vertex buffer.
Sets the size of a single vertex, only takes effect after a call to
restore.
Returns the size of a single vertex in the buffer.
Returns a pointer to the D3DVERTEXBUFFER.
Locks the vertex buffer.
Unlocks the vertex buffer.
Implementation Details: Uses the D3DVERTEXBUFFER type.
Page 83 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Index Buffer Manager
Description: The Index Buffer Manager is responsible for creating and managing all of
the index buffer resources needed by the game.
Dependencies: DisplayMgr
Classes:
 IBResourceMgr
 IBResource
 DynamicIBResource
Page 84 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: IBResource
Module: Index Buffer Manager
Description: The index buffer resource class.
Requirements: Encapsulates a managed index buffer.
Public Interface:
Function Names
SetNumIndices
GetNumIndices
SetIndexFormat
GetIndexFormat
Init
Invalidate
Restore
Delete
Lock
Unlock
GetResource
Description
Sets the number of indices, takes effect after a Restore call.
Gets number of indices.
Sets the index format (16 or 32 bit), takes effect after a Restore
call.
Gets the index format.
Initializes the index buffer.
Prepares resource for a device reset.
Restores the resource after a device reset.
Deletes the resource.
Locks the index buffer.
Unlocks the index buffer.
Returns a pointer to D3DINDEXBUFFER.
Implementation Details: Uses the D3DINDEXBUFFER type.
Page 85 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: IBResource
Module: Index Buffer Manager
Description: This is the index buffer resource class. Index buffers are used in
conjunction with Vertex Buffers. When an index buffer is used, the indices represent the
vertices to be rendered from the vertex buffer.
Requirements: Encapsulates a index buffer.
Public Interface:
Function Names
SetNumIndices
GetNumIndices
SetIndexFormat
GetIndexFormat
Init
Invalidate
Restore
Delete
Lock
Unlock
GetResource
Description
Sets the number of indices, takes effect after a Restore call.
Gets number of indices.
Sets the index format (16 or 32 bit), takes effect after a Restore
call.
Gets the index format.
Initializes the index buffer.
Prepares resource for a device reset.
Restores the resource after a device reset.
Deletes the resource.
Locks the index buffer.
Unlocks the index buffer.
Returns a pointer to D3DINDEXBUFFER.
Implementation Details: Uses the D3DINDEXBUFFER type.
Page 86 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: DynamicIBResource
Module: Index Buffer Manager
Description: This is the dynamic index buffer resource class. Dynamic Index Buffers are
meant to be locked every frame. Their values are not restore during a display device
reset.
Requirements: Encapsulates a dynamic index buffer.
Public Interface:
Function Names
SetNumIndices
GetNumIndices
SetIndexFormat
GetIndexFormat
Init
Invalidate
Restore
Delete
Lock
Unlock
GetResource
Description
Sets the number of indices, takes effect after a Restore call.
Gets number of indices.
Sets the index format (16 or 32 bit), takes effect after a Restore
call.
Gets the index format.
Initializes the index buffer.
Prepares resource for a device reset.
Restores the resource after a device reset.
Deletes the resource.
Locks the index buffer.
Unlocks the index buffer.
Returns a pointer to D3DINDEXBUFFER.
Implementation Details: Uses the D3DINDEXBUFFER type.
Page 87 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Animated Models
Description: Villager Kisses will use animated models for the Villager and Yeti
characters. The implementation of animated models will make use of the
D3DXAllocateHierarchy and D3DXAnimationController interfaces.
D3DXAllocateHierarchy is used to allocate the model resources, and
D3DXAnimationController is used to animate the model. A separate
D3DXAnimationController is needed for every instance of a particular animated model
in the game, while the hierarchy may be shared.
The Model Manager module is responsible for the allocation of Model Resources and
ModelHandles. It provides clients with ModelHandles.
The ModelHandle stores a handle to a ModelResource, and it stores it’s own unique
animation controller. The ModelHandle provides the interface for animating the model.
The Model Resource has the frame hierarchy used by all animated handles using the
same base model, as well as handles to the textures.
Dependencies: Any Dependencies
Classes:
 ModelMgr
 ModelHandle
 ModelResource
Page 88 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: ModelMgr
Module: Animated Models
Description: The model manager provides ModelHandles to its users. A ModelHandle is
the interface that clients use to draw and animate 3D models.
Requirements:
 Manage the lifetime of ModelHandle and ModelResource objects.
 All models are from the .x file format.
Public Interface:
Function Names
GetModelFromFile
InvalidateAll
RestoreAll
Description
Returns a handle to the specified model.
Invalidates all of the model resources.
Restores all of the model resources after a display device reset.
Implementation Details: Depending on the models made by the artists, modification of
the 3DSMax .x exporter may be necessary in.
Page 89 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: ModelHandle
Module: Animated Models
Description: The ModelHandle is a handle to a ModelResource object. In order for
different instances to be in different animation states, the ModelHandle class stores a
D3DXAnimationController object.
Requirements:
 Provide an interface to animate models
Public Interface:
Function Names
Description
ChangeAnimationState Transitions to the specified animation state.
Page 90 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: ModelResource
Module: Animated Models
Description: The ModelResource class stores the frame hierarchy of an animated model.
Requirements:
 Allocate model hierarchy.
 Allocate textures for model.
Public Interface:
Function Names
Init
Restore
Invalidate
Delete
SetFileName
Description
Initializes the model.
Restores the model.
Invalidates the model.
Deletes the mode.
Sets the name of the file on disk that defines the model and its
animations
Implementation Details: ModelResource makes use of D3DXAllocateHierarchy.
Page 91 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Text Manager
Description: The Text module is used to draw 2D text on the display screen. Uses for 2D
text in the game include drawing menus, displaying game statistics, and displaying the
credits screen.
Dependencies: Display Device, Vertex Buffer Manager, Index Buffer, and Texture
Manager
Classes:
 TextMgr
 Text
Page 92 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: TextMgr
Module: Text Manager
Description: TextMgr is a singleton class. Its job is to accept requests for drawing 2D
text on the screen, and then draw all the text in one pass as efficiently as possible.
Requirements: Renders any text string onto the screen. The user may specify the font of
the text, its scale, text color, and position. Below is a list of features that the TextMgr
must support:
 Italic Text
 New line support
 Bounding box for the text to be drawn into
 Word wrapping
 Left, right, and center text alignment
 Draw all the text for a frame all at once, in the most optimized manner.
 Diffuse color support
 Multiple fonts
 Font scaling
Public Interface:
Function Names
DrawText
DrawAllText
Description
Takes a single Text object, and buffers the request to draw it.
Tells the manager to draw all the text it has buffered up to since the
last call to DrawAllText.
Implementation Details: It is possible that ID3DXFont will be used internally to render
the text.
Page 93 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Text
Module: Text Manager
Description: Text encapsulates all the variables involving text which will be supported
by the TextMgr.
Requirements:
 Support saving a string, diffuse color, font style, scale, screen position, and
italics-state.
 Provide functions which allow clients to query what the variables in the Text
object are currently defined as.
Function Names
SetText
GetText
SetItalic
IsItalic
SetFont
GetFont
SetColor
GetColor
SetScale
GetScale
SetPosition
GetPosition
Description
Sets the text string.
Returns the text.
Pass true to set the italic state.
Returns true if the text is in the italic state.
Set the font of the text.
Returns the current font.
Set the text color.
Returns the text color.
Set the scale of the text.
Returns the scale of the text.
Sets the position of the text in the screen.
Returns the position of the text.
Page 94 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Scene Graph
Description: The scene graph is designed to render the scene as efficiently as possible,
taking that responsibility away from the Object Manager and other related modules. Due
to the particular needs of our project, the scene graph will be fairly simple and will only
sort by FX Id, and Geometry Id. Many scene graphs use a system where each node in the
graph represents a Render State or Texture, which is then applied to its children. This
doesn’t work very well for us, since we have a very limited number of unique objects,
and because we used batched render states with the FX files.
Dependencies:
RenderMgr, FXConstant
Classes:
 SceneMgr
 SceneGraphNode
 ObjectNode
Page 95 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: SceneMgr
Module: Scene Graph
Description: Singleton class that builds the scene graph.
Requirements: Render all objects passed into it in an efficient manner.
Public Interface:
Function Names
AddObject
Render
Description
Inserts the given Model,FX pair into the scene graph, and returns a
handle to that object.
Navigates the tree and renders the scene.
Implementation Details:
The first level of sorting is by FX ID, which is done with an STL vector. The FX
ID is used as an index into the vector, which contains lists of SceneGraphNodes. The list
at each vector entry is kept sorted at all times. (Depending on testing, this may change to
be sorted once right before rendering).
When Render() is called, the SceneMgr loops through each entry in the vector. If
the list has entries in it, the SceneMgr sets the FX ID in the RenderMgr, then loops
through the list. At each entry, it will set the Model ID in the RenderMgr only if the
Model ID is different. Then it will set the FXConstant vector and the object’s Transform
in the RenderMgr. It will then tell the RenderMgr to render the object, and continue
looping.
Page 96 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: ObjectNode
Module: Scene Graph
Description: This is class represents a standard object in the scene graph
Requirements: Contain the data required to render an object.
Public Interface:
Function Names
Render
Comparison Operators
Description
Set the Transform, a vector of FXConstants and the Model if
needed.
Used to sort by model ID.
Implementation Details: A very simple class, this simply stores a 4x4 Matrix, a FX ID,
a Model ID, and a vector of FXConstants.
Page 97 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: ObjectNodeHandle
Module: SceneGraph
Description: A handle to an object in the scene graph
Requirements: Provide management and lifetime functions.
Public Interface:
Function Names
SetTransform
SetModelID
SetFXID
SetConstants
Description
Set the transformation matrix for this object.
Set the model ID for this object (and re-sort the list).
Set the FX ID for this object (and reinsert into scene graph).
Update the FXConstants for this object.
Implementation Details: Most functions in the handle merely update a member of the
class it is a handle to, but the SetFXID function will remove the object from the scene
graph and reinsert it. SetModelID will change the ID, but will re-sort the list by model,
unless testing determines this is not efficient. (See SceneMgr description for details).
Page 98 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Render Manager
Description: The purpose of the Render Manager module is to provide a standard
interface for drawing graphics objects to the screen.
Dependencies: DisplayMgr, FXContentMgr, FXConstant
Classes:
 RenderMgr
Page 99 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: RenderMgr
Module: Render Manager
Description: The purpose of the RenderMgr class is to provide a standard interface for
drawing graphics objects to the screen. Four pieces of data are needed for the RenderMgr
to render a 3D object:
 A world transformation matrix
 An FXObject
 The object’s geometry (3D model)
 An optional collection of parameters to be used by the vertex or pixel shaders
Requirements:
 Properly render objects with the correct technique and textures.
 Properly handle multi-pass techniques that may need render to intermediate
Render Target Textures.
Public Interface:
Function Names
SetActiveFXID
SetActiveGeometry
SetTransform
Render
Description
Sets the FX ID to be used for all subsequent render calls.
Sets the Geometry Object to be used for subsequent render calls.
Sets the Transform for all subsequent draw calls.
Renders an object to the screen, must pass in an vector of
FXConstants.
Page 100 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Quad Manager
Description: Handle the rendering of 2D quads on the screen, generally used for the User
Interface.
Dependencies: DeviceMgr, D3DXSprite
Classes:
 QuadMgr
 Quad
Page 101 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: QuadMgr
Module: Quad Manager
Description: Allow the drawing of 2D shapes in screen space.
Requirements: Draw 2D textured rectangles in screen space with scaling.
Public Interface:
Function Names
Render
InvalidateAll
RestoreAll
BeginScene
EndScene
Description
Render the given Quad to the screen. Must be called between
BeginScene and EndScene.
Release all device dependant objects
Restore all device dependant objects
Get ready to render quads.
Finished rendering quads.
Implementation Details: This will most likely use the D3DX Sprite Interface, but if that
proves to be inefficient or too hard to use, it will be done by editing a dynamic vertex
buffer.
Page 102 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Quad
Module: Quad Manager
Description: Simple structure for storing information about a quad
Requirements: Store Texture, vertex data, color, and position data.
Public Interface:
Function Names
SetTexture
SetSourceRect
SetDestRect
SetColor
Description
Set the current texture to use.
Specify the uv’s of where to sample from on the texture (0-1).
Specify the position on the screen of where to draw (0-1).
Specify a ARGB value used to tint the texture.
Implementation Details: The only complication in the structure results from the use of
the D3DX Sprite interface, which requires that the source rectangle is in texels, and that
the scaling is done with a matrix. This means that the actual size of the texture will have
to be taken into account when setting the destination and source rectangles. If this proves
to be too difficult or expensive to compute, a dynamic vertex buffer may be used instead.
Page 103 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Module: Particle Manager
Description: Particle systems serve as scalable aesthetic additions to the game that
should operate as efficiently as possible. They are similar to regular objects in the game,
except they do not affect game-play, and since they are just decorative, they may be
scaled down as necessary. The particle manager is responsible for all particle systems.
Each particle system is responsible for all of its particles.
Dependencies: NONE
Classes:
 ParticleMgr
 ParticleSystemInitializer
 ParticleSystem
 Particle
Page 104 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: ParticleMgr
Module: Particle Manager
Description: The ParticleMgr is a singleton class that is responsible for maintaining all
the ParticleSystem objects in the game. In addition, it must adjust the particle systems’
level of detail based on the user’s settings.
Requirements:
 Save a list of pointers to all the ParticleSystem objects in the game. Perhaps save
unused (dead) particle systems in a container for reuse.
 Spawn particle systems, and return handles to the client.
 Update functionality.
 Draw functionality.
 Scale aesthetics functionality.
Public Interface:
Function Names
Spawn
Update
Draw
AdjustParticleAesthetics
Description
Spawns a particle system, and returns a handle to the client.
Update all the ParticleSystem objects.
Draw all the ParticleSystem objects.
Adjust the level of detail for particle systems.
Page 105 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: ParticleSystemInitializer
Module: Particle Manager
Description: The ParticleSystemInitializer object is what the client defines and passes to
the ParticleMgr to spawn a ParticleSystem object. The data within this object is
guaranteed to evolve constantly over the course of the year.
Requirements:
 Enum value representing a pre-made particle system (for client-end convenience).
 Starting physics data for particles.
 Starting physics data for particle system.
 Optional function pointers for all areas of functionality: update, draw, death for
both particle and particle systems, and emission function for system.
 Resource data for drawing functionality at particle and particle system level.
Implementation Details: Data encapsulated in the ParticleSystemInitializer is likely to
expand and change.
Page 106 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: ParticleSystem
Module: Particle Manager
Description: The ParticleSystem is in charge of maintenance for all the Particle objects
in the system. In addition to this, it contains extra functionality, which ranges from
particle emission rates and particle system movement, to data which allows the system to
act as a standalone rendered object. It is owned by the ParticleMgr.
Requirements:
 Save all the particles it owns in a list. Save unused particles in a separate
container for recreation (NOTE: this will not work as well if Particle objects have
derived classes).
 Update functionality.
 Draw functionality.
 Death functionality.
 Allow clients to manipulate some of its internal variables (such as position,
velocity, emission rate, emission physics) at run-time.
 Standalone update, drawing, and death functionality (optional for the client to
use).
Public Interface:
Function Names
Spawn
Update
Draw
OnDeath
AdustSystem
Description
Creates the system.
Updates all the Particle objects. Updates itself if there is a
system update function.
Draws all the Particle objects. Draws itself if there is a system
draw function.
Called if the system has been given death functionality.
Modifies functionality within the system while it is still alive.
Implementation Details: The implementation for the ParticleSystem object is likely to
change, but possible design patterns include (list not exclusive):
1. A templatized particle system, where client-defined template parameters to
specify functionality.
2. Use client-defined function pointers for all areas of functionality.
Page 107 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: Particle
Module: Particle Manager
Description: A Particle object represents the finest level of granularity in the particle
management system. It encapsulates basic data like position, and drawing functionality.
It belongs to a distinct ParticleSystem.
Requirements:
 Clear and initialization functions which do not require new memory.
 Positional data.
 Displacement data (velocity, acceleration, etc.).
 Update functionality.
 Draw functionality.
 Death functionality.
Public Interface:
Function Names
Clear
Initialize
Update
Draw
OnDeath
Description
Eliminates all data.
Reset the data.
Update the particle.
Draw the particle.
Called when the particle dies.
Implementation Details: The implementation for the Particle object is likely to change,
but possible design patterns include (list not exclusive):
3. A templatized particle, where client-defined template parameters specify
functionality.
4. Derived implementations of the Particle may specialize in one area of
functionality (drawing for example). The problem here is that only one area of
functionality can utilize the derived classes.
5. Use client-defined function pointers for all areas of functionality.
One, none, or a combination of all three design patterns may be chosen in the future.
Page 108 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Miscellaneous Graphics Classes
Class: Render To Texture
Description: The RenderToTexture class is used when a scene needs to be drawn to a
texture instead of the back buffer. This class is used in conjunction with the
TextureRenderTargetResource class.
Requirements: This class must prepare the display device for rendering to a texture and
it must reset the display to its previous state after rendering to the texture is done.
Public Interface:
Function Names
Begin
End
Description
Prepare the display device for rendering to the specified texture.
Resets the display device to its previous state.
Implementation Details: Two display device states need to be set and reset while
rendering to a texture: the current render target, and the view-port. The view-port must
not be bigger than the render target texture. The texture render target should be cleared
inside the Begin function.
Page 109 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: FXConstant
Module: FX Manager
Description: The FXConstant class is an interface that the objects can use to specify
values to be set in the D3DXEffect object referenced by an FXHandle. An array or
std::vector of FXConstants is used by the RenderMgr to set values prior to rendering.
Requirements: Provide an interface for specifying values to set in an D3DXEffect object
prior to rendering.
Public Interface:
Function Names
SetName
GetName
GetNameLen
SetDataPointer
GetDataPointer
GetNumBytes
Description
Sets the name of the value to be set.
Returns the name of the value to be set.
Returns the number of characters in the string.
Set the address of the value you want to set the FX value to.
Returns the pointer to the value.
Returns the number of bytes pointed to by the data pointer.
Implementation Details: Data pointers are defined to be void* to simplify the interface.
Page 110 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: RenderableGeometry
Description: The RenderableGeometry class is an interface class that defines a common
interface for rendering geometry on the screen. It frees the RenderMgr class from having
to handle the drawing of meshes or vertex buffer differently from one another.
Below is a diagram that shows the relationship between this base class and the necessary
child classes that will need to be implemented:
Geometry
Model Mesh
Vertex Buffer
Dynamic Vertex
Buffer
Vertex Buffer
with Index Buffer
Dynamic Vertex Buffer
with Dynamic Index
Buffer
Requirements: Define a common interface for rendering any geometric object.
Public Interface:
Function Names
PreDraw
Draw
PostDraw
Description
Called before drawing, this is to set any textures or streams.
Draws the object to the screen.
Do any post drawing stuff, such as resetting any textures.
Implementation Details: RenderableGeometry is a pure interface class.
Page 111 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Key Component: Audio
Description: The Audio component is responsible for all audio functionality in the
application. This includes both the music and the sound effects. Specifically, it provides
resource management for audio files, provides functionality for audio files, and abstracts
the specifics of actual sound effects and musical resources for the application.
Modules:
 AudioMgr
Page 112 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: AudioMgr
Module: Audio Manager
Description: AudioMgr is an abstract base singleton class. It provides a public interface
for audio clients, and a protected interface for all actual implementations of the
AudioMgr to use.
Requirements:
 Provide functionality hiding which implementation of the AudioMgr is chosen.
 Provide interface functionality for loading audio files, manipulating them for
audio functionality, and unloading them.
 Provide interface functionality for querying the actual implementation class’
details (name and description).
Public Interface:
Function Names
static Initialize
GetAudioMgrName = 0
GetAudioMgrDescription = 0
Load = 0
IsLoaded = 0
Unload = 0
AdjustAudioState = 0
AdjustVolume = 0
AdjustPriority = 0
AdjustAudioGroup = 0
Adjust3Dstate = 0
Update3Daudio = 0
Description
Hides the creation of an actual class instance that
derives from the AudioMgr.
Returns name of implementation class.
Returns description of implementation class.
Loads an audio file.
Determines if an audio file is loaded.
Unloads an audio file.
Adjusts state of loaded audio file
(play/pause/stop).
Adjusts volume of playing audio file.
Adjusts priority of playing audio file.
Adjusts state and/or priority and/or volume of an
entire group of audio files (all/all static/all
streaming/all sequenced).
Specify the location (optional) and/or velocity
(optional) of a 3D audio file.
Updates the 3D calculations for the engine, and
takes the position and velocity of the listener.
Protected Interface: We require a protected interface for a very important reason. The
audio file objects will have private data that must be modified by the audio manager.
However, it is poor design to have the audio file objects friend each specific
implementation of the AudioMgr, so it will only friend the AudioMgr base class, and the
Page 113 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
AudioMgr base class will provide protected inline functions to modify the audio file
objects. Then each of the derived classes in the future will be able to have the same
functionality.
Function Names
SetAudioChannel
SetAudioResourcePtr
CreateAudioDataHandle
Description
If a channel must be saved with an audio file handle, this
records it.
If a resource pointer must be saved with an audio file, this
records it.
This takes an audio file, and returns and audio file handle.
Implementation Details: There are few implementation details since this class merely
specifies an interface for derived implementations to adhere to.
Page 114 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: AudioData
Module: Audio Manager
Description: This class encapsulates the full definition for any audio resource across the
general set of platforms that we could predict to encounter. It currently contains filename,
looping status, dimensions (2D/3D), type (static/streaming/sequenced).
Requirements:
 Save the definition of the audio resource
 Provide extra private variables, which may or may not be used by specific
implementations of the AudioMgr. Right now this includes a void* recommended
to save any resource pointers
 Provide an operator < so that this may be sorted by a std::map
Public Interface:
Function Names
SetFilename
SetLooping
SetAudioDimensions
SetAudioType
GetLoaded
Operator <
Description
Sets filename of audio resource.
Sets if the resource will loop or not.
Specify whether the sound is 2D or 3D.
Specify if the sound is static, streaming, or sequenced
Returns whether or not this specific AudioData object has
been loaded. Another AudioData object that is identical being
loaded does not count.
Determines whether one AudioData object is ‘less’ than
another AudioData object. It is an arbitrary procedure, but it
will hopefully be optimal considering the likely differences in
objects.
Implementation Details: No Set accessor functions will work after the object has been
loaded.
Page 115 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: AudioDataHandle
Module: Audio Manager
Description: This is a handle to an AudioData object. It also stores additional
information necessary for AudioData functionality.
Requirements:
 Be a handle to an AudioData object
 Provide extra private variables that may or may not be used by implementations
of the AudioMgr. Right now, this includes an integer that is recommended to
store the channel an audio resource is playing on. This is convenient if not
completely necessary since multiple handles may reference the same AudioData
and will need to save the channel that the resource is playing on. Thus, if it is
saved, it could not be saved with the actual AudioData itself
 Provide a set of convenience functions to gain functionality from the AudioData
Public Interface:
Function Names
Load
Unload
AdjustAudioState
AdjustVolume
AdjustPriority
AdjustPosition
AdjustVelocity
Description
Loads a new AudioData (passed in) object.
Releases the target (AudioData*), making the handle available
for a new resource (AudioData).
Play/Pause/Un-pause/Stop a loaded handle.
Adjust volume of playing/paused handle.
Adjust priority of playing/paused handle.
Adjust position of playing/paused 3D sound.
Adjust velocity of playing/paused 3D sound.
Page 116 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Key Component: Input
Description: The Input component of the game tracks all of the user input that the game
application receives. It supports both buffered input and non-buffered input. The Input
component for Villager Kisses is built on top of DirectInput8.
Modules:
 Input Manager
Page 117 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Class: InputMgr
Module: Input Manager
Description: The Input component of the game tracks all of the user input that the game
application receives. It supports both buffered input and non-buffered input.
Requirements:
 Support for buffered and un-buffered input
 Accept input from the mouse and keyboard
Public Interface:
Function Names
Update
TurnOnBufferedInput
TurnOffBufferedInput
IsKeyDown
GetAbsoluteMousePosition
GetRelativeMousePosition
IsMouseWheelScrolledUp
IsMouseWheelScrolledDown
IsLeftMouseButtonDown
IsMiddleMouseButtonDown
IsRightMouseButtonDown
Description
Gathers input (buffered or not).
Turns buffered input on.
Turns buffered input off.
Determines whether the specified key is down.
Returns absolute position of mouse in normalized
coordinates.
Returns relative position of mouse this input frame
in normalized coordinates.
Returns whether the mouse wheel (middle mouse
button in most cases) has been scrolled up in this
input frame.
Returns whether the mouse wheel (middle mouse
button in most cases) has been scrolled down in this
input frame.
Returns whether left mouse button is down.
Returns whether middle mouse button is down.
Returns whether right mouse button is down.
Implementation Details: DirectInput8 will be used as the underlying API to retrieve
input.
Page 118 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Project Milestones
Page 119 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Implement FXContent and FXConstants, FXResource,
and FXObject classes
Description: Implement the FX related classes. FXResource and FXObject have already
been implemented, so only small touch-ups may be necessary for those two classes.
Implement the FXContent and FXConstants classes from scratch.
Dependencies: No outstanding dependencies.
Acceptance Criteria:
 All the functionality outlined in this document for the FXContent, FXConstant,
FXResource, and FXObject classes implemented.
Scheduled Time (week/day): Oct 13 – Oct 17
Contributor(s): Gilberto Rosado
Page 120 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Implement RenderableGeometry set of classes
Description: Implement the RenderableGeometry class hierarchy. This class acts as an
interface for rendering 3D objects. It provides a common interface for rendering 3D
objects whose vertex data is stored in meshes, vertex buffers, or any other container.
Dependencies: VBResource, IBResource, Texture Resources.
Acceptance Criteria:
 RenderableGeometry base interface class implemented to specification.
 Vertex Buffer child class implemented.
 Vertex + Index Buffers child class implemented.
 Dynamic Vertex Buffer child class implemented.
 Dynamic Vertex + Index Buffers child class implemented.
 Animated Mesh stub child class implemented (until Animated Mesh is done).
Scheduled Time (week/day): Oct13-Oct17
Contributor(s): Gilberto Rosado
Page 121 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Implement RenderMgr
Description: Implement the RenderMgr class as specified in this document.
Dependencies: FXContentMgr, FXConstant, RenderableGeometry
Acceptance Criteria:
 RenderMgr should properly interface with the SceneMgr class.
 RenderMgr should properly render all scenes, multi-pass techniques included.
Scheduled Time (week/day): Oct 16 – Oct 22
Contributor(s): Gilberto Rosado
Page 122 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Implement a Procedural Texturing and Modeling Library
Description: Implement a wrapper for the math library to make it look like HLSL math
function syntax. This wrapper will be used to implement procedural textures in C++. The
TextureResourceCpp class will be implemented as well.
A collection of standard procedural functions is to be implemented. These functions
include the noise, fBM, and the turbulence functions.
This functionality will be used in creating the Village.
Dependencies: None
Acceptance Criteria:
 Implement the TextureResourceCpp class and create a simple procedural texture
using the new math wrapper and procedural functions.
Scheduled Time (week/day): Oct 23 – Oct 24
Contributor(s): Gilberto Rosado
Page 123 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Village Terrain
Description: This milestone requires that the terrain is generated and rendered. The
terrain should have some height differences, but object placement of objects such as
igloos are not necessary at this point. Texturing is also not required at this point.
Dependencies: None
Acceptance Criteria:
 Terrain generated with height map.
 Save terrain data to file.
 Load terrain data from file.
 Render terrain mesh.
Scheduled Time (week/day): Oct 27 – Oct 31
Contributor(s): Gilberto Rosado
Page 124 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Village Object Placement
Description: Properly place objects in the village.
Dependencies: Village Terrain
Acceptance Criteria:
 Properly place Igloos, Ice Fishing Hut, Forest, Snow Mine, trees and rocks around
the level.
Scheduled Time (week/day): Nov 3 – Nov 5
Contributor(s): Gilberto Rosado
Page 125 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Village Lighting
Description: Implement terrain lighting.
Dependencies: Village Terrain
Acceptance Criteria:
 The terrain should be lit properly according to the time of day in the game; that is
light varies with direction and color depending on the time of day in the game.
Scheduled Time (week/day): Nov 6 – Nov 7
Contributor(s): Gilberto Rosado
Page 126 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Village Terrain Texturing
Description: Texture the village terrain and objects with some procedural textures. This
will give the terrain a varied look to it.
Dependencies: Village Terrain.
Acceptance Criteria:
 Snow textures
 Wood textures
 Rock textures
Scheduled Time (week/day): Nov 12 – Nov 21
Contributor(s): Gilberto Rosado
Page 127 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Ice Reflection Graphics Effect
Description: Implement a reflection effect for the ice. The Villagers should reflect onto
the ice surface.
Dependencies: any dependencies
Acceptance Criteria:
 The Villagers reflect off the ice.
Scheduled Time (week/day): Nov 10 – Nov 11
Contributor(s): Gilberto Rosado
Page 128 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Model Loading and Texturing
Description: Load models from the .x file format; render them to the screen with
texturing. This task will require implementing the ModelMgr and Model Resource
classes. The ModelHandle class will need to be created, but the animation functionality
does not have to be implemented.
Dependencies: Texture Resources
Acceptance Criteria:
 Load model geometry from .x file.
 Properly texture the model. Test with a model that uses more than one texture.
Scheduled Time (week/day): Oct 13 – Oct 17
Contributor(s): Alexander Van Berg
Page 129 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Model Animation
Description: Animate models defined in the .x file format. A model with multiple
animations must be used. Transitioning from one animation to the other must happen in a
pleasing manner.
The animation algorithm used will be palette index skinning using an HLSL vertex
shader.
This task will require the complete implementation of the ModelHandle class.
Dependencies: Model Loading
Acceptance Criteria:
 Properly load an .x file model that defines two or more separate animation
sequences.
 Models should be able to transition to any of the defined animations at run-time.
 Models should properly blend their animation from one animation set to the other.
A smooth transition should be made that is pleasing to the eye.
Scheduled Time (week/day): Oct20 – Oct24
Contributor(s): Alexander Van Berg
Page 130 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Model Instancing
Description: Allocate more than one instance of the models. Two or more objects using
the same ModelResource should be able to be in different animation states with one not
influencing the other.
This task requires that the relationship between the ModelResource and ModelHandle
class is properly defined.
Dependencies: Model loading and animation.
Acceptance Criteria:
 Create two or more objects that use the same model resource. There should be one
copy of the model shared by all objects.
 Models should all animate independently of each other. That is, one model should
be in one animation sate, and another model in a different animation state, yet
both of them reference the same model resource.
Scheduled Time (week/day): Oct 27 – Oct 31
Contributor(s): Alexander Van Berg
Page 131 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Particle Management Framework
Description: Set up the principle classes involved in the particle system framework:
ParticleMgr, ParticleSystem, ParticleSystemInitializer, and Particle. Spawn one system,
and maintain it until its death. Rendering is not necessary at this point.
Dependencies: NONE
Acceptance Criteria:
 Define the principle classes up to 70% completion.
 Spawn and maintain one particle system.
Scheduled Time (week/day): Nov 3 – Nov 9
Contributor(s): Alexander Van Berg
Page 132 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Particle Drawing
Description: Begin drawing the particles. This includes an optimized rendering of 2D
images and models. The models may not be necessary in the immediate game design, but
it is essential to plan for the future.
Dependencies: ModelMgr
Acceptance Criteria:
 Draw all the particles as billboards, axial billboards, transformed 2D billboards,
and possibly even decals.
 Draw the same particles as models instead.
Scheduled Time (week/day): Nov 10 – Nov 16
Contributor(s): Alexander Van Berg
Page 133 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Particle Functionality Definitions
Description: Define in whichever manner is chosen, 80% of the needed
functions/templatized classes/etc., which will be used to govern spawning, updating,
dying, and emitting.
Dependencies: NONE
Acceptance Criteria:
 Support for all particle functionality is provided.
 Evidence of this should be varied physics in the particle systems.
Scheduled Time (week/day): Nov 17 – Nov 23
Contributor(s): Alexander Van Berg
Page 134 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Particle System Definitions
Description: Define at a minimum the four particle systems in the game. Tweak them
appropriately.
Dependencies: NONE
Acceptance Criteria:
 Snowflake particle system.
 Fire particle system.
 Smoke particle system.
 Heart particle system.
 Cold breath particle system (optional – not in GDD).
Scheduled Time (week/day): Nov 24 – Nov30
Contributor(s): Alexander Van Berg
Page 135 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Scene Manager
Description: Implement Depth and Geometry sorting in the SceneMgr. Geometry sorting
will be added to the current tree, while Depth sorting will be accomplished with a
separate tree for transparent objects.
Dependencies: ModelMgr (for the Model ID’s)
Acceptance Criteria: Sort transparent objects for drawing back to front, sort objects by
model for more efficient batching.
Scheduled Time (week/day): Oct13 – Oct 17
Contributor(s): Lewis Mohr
Page 136 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: GameMgr Structure
Description: Pseudo-code the GameMgr and define all basic structures needed to run the
GameMgr.
Dependencies: None
Acceptance Criteria: Anyone should be able to look at the pseudo-code and begin
replacing it with real code.
Scheduled Time (week/day): Oct13 – Oct 17
Contributor(s): Lewis Mohr
Page 137 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: UI Structure
Description: Pseudo-code the UI and define all basic structures needed to run the UI.
Dependencies: None
Acceptance Criteria: Anyone should be able to look at the pseudo-code and begin
replacing it with real code.
Scheduled Time (week/day): Oct 20 – Oct 24
Contributor(s): Lewis Mohr
Page 138 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: UI Parsing
Description: Replace the pseudo-code for the UI parsing and start actually parsing files.
Dependencies: None
Acceptance Criteria:
 Recursively load menu tree.
 Load Descriptor objects.
 Allow Nesting of objects.
 Allow file derivation from named objects.
Scheduled Time (week/day): Oct 27 – Oct 31
Contributor(s): Lewis Mohr
Page 139 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: UI Objects
Description: Implement any needed UI Objects for the menus
Dependencies: Each object may require the use of functions from any of the managers in
game, but it is extremely easy to un-comment these function calls later. Therefore, while
the objects use many other milestones, this milestone does not directly depend on them
for success.
Acceptance Criteria: All currently known UI objects should work and be definable in a
menu script file.
Scheduled Time (week/day): Nov 3 – Nov 7
Contributor(s): Lewis Mohr
Page 140 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: GameMgr Finale
Description: Replace and implement remaining pseudo-code in GameMgr, debug and
polish.
Dependencies: The GameMgr may require the use of functions from any of the
managers in game, but it is extremely easy to un-comment these function calls later.
Therefore, while the GameMgr uses many other milestones, this milestone does not
directly depend on them for success.
Acceptance Criteria:
 Properly handle state changes.
 Properly call game-play functions.
Scheduled Time (week/day): Nov 10 – Nov 14
Contributor(s): Lewis Mohr
Page 141 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: UI Finale
Description: After this week, the UI should be complete, waiting only for pretty graphics
and arrangement of objects in the script files.
Dependencies: None.
Acceptance Criteria:
 Bug-free
 Fast
 Usable
Scheduled Time (week/day): Nov 17 – Nov 21
Contributor(s): Lewis Mohr
Page 142 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: UI Templates
Description: Work on the UI Templates, implementing any needed menus
Dependencies: UI Art
Acceptance Criteria: This is an ongoing task, but:
 Should have all basic menus required to get to each game state functionally
implemented.
 Basic UI objects should have final art.
Scheduled Time (week/day): Nov 17 – Nov 21
Contributor(s): Lewis Mohr (code), Ryan Juckett (art)
Page 143 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Dropping Items
Description:
Allow Villagers to drop inventory items into the world.
Dependencies:
 Movement grid data component with a quad tree of children.
 Drop action component.
Acceptance Criteria:
Items should be removed from the inventory and inserted into the object’s parent’s
movement grid.
Scheduled Time (week/day): Oct13 – Oct 17
Contributor(s): Ryan Juckett
Page 144 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Burning Items
Description:
Burn carried items in a fire.
Dependencies:
 Burn action component.
Acceptance Criteria:
Burnable items in a villager’s inventory must be able to be removed from the inventory
and destroyed while adding power to the fire.
Scheduled Time (week/day): Oct 20 – Oct 21
Contributor(s): Ryan Juckett
Page 145 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Grill and Melt Items
Description:
Place grillable items on a griller to produce food, and place meltable items on a melter to
produce food.
Dependencies:
 Cook action component.
 Melt action component.
 Attachment of grillers and melters to a fire.
Acceptance Criteria:
Grillable and meltable items in a villager’s inventory must be able to be removed from
the inventory and placed on a griller or melter depending on the item type. The item
must then be transformed into the appropriate food or drink based on a combination of
the fire level and the griller or melter level.
Scheduled Time (week/day): Oct 22 – Oct 24
Contributor(s): Ryan Juckett
Page 146 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Time System
Description:
Village time should advance year, date, month, day, hour, minute, and second
appropriately.
Dependencies:
 Game logic time
Acceptance Criteria:
Village time should update relative to game logic time based on a village time scale.
Scheduled Time (week/day): Oct27 - Oct 28
Contributor(s): Ryan Juckett
Page 147 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Weather System
Description:
Village weather should change based in a predictable manner at any given time based on
the village name. Weather should track a base weather type in the base weather type
coordinate system, a wind speed, and a wind direction.
Dependencies:
 Village time
 Village name
Acceptance Criteria:
Village weather should vary over time in a smooth manner.
Scheduled Time (week/day): Oct29 – Oct 31
Contributor(s): Ryan Juckett
Page 148 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Dispense Items
Description:
Objects that dispense fish, snow, and wood need to be able to produce the appropriate
items based on different parameters.
Dependencies:
 Village weather
 Village time
Acceptance Criteria:
Dispenser objects should dispense the appropriate items based on the conditions
described in the game design.
Scheduled Time (week/day): Nov3 – Nov 7
Contributor(s): Ryan Juckett
Page 149 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Energy System
Description:
Get the energy system, including attribute, health, need, and energy levels, functioning
for Villagers.
Dependencies:
 Village time
 Village weather
Acceptance Criteria:
Need levels should increase over time. Health should decrease over time based on
attributes and needs. Energy should decrease with use.
Scheduled Time (week/day): Nov 10 – Nov 14
Contributor(s): Ryan Juckett
Page 150 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Collision
Description:
Objects need collision volumes that work with the physics system defined by their
parent’s movement grid. Movement grids will integrate object movement while handling
object collision with the world and object collision with other objects.
Dependencies:
 Movement grid
Acceptance Criteria:
Objects should not fall through the world or be able to move through each other.
Scheduled Time (week/day): Nov 17 – Nov 21
Contributor(s): Ryan Juckett
Page 151 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Path Finding
Description:
Implement an A-star algorithm to work across a movement grid. The generated paths
then need to be able to get modified to find new destinations in an efficient manner.
Dependencies:
 Movement grid
 Collision
Acceptance Criteria:
A villager should be able to chose a destination in its parent’s movement grid and
successfully walk there.
Scheduled Time (week/day): Nov 24 – Nov 28
Contributor(s): Gilberto Rosado, Ryan Juckett
Page 152 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Milestone: Villager Survival
Description:
Villager AI should plan and execute tasks that will help keep them healthy.
Dependencies:
 Path finding
 Resource gathering
 Cooking and melting
Acceptance Criteria:
Villagers will generate a list of tasks that they want to do and then try and execute them.
Scheduled Time (week/day): Dec1 – Dec 5
Contributor(s): Ryan Juckett
Page 153 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
C++ Source Code Syntax Rules
The following are the syntax conventions that team members should follow in their
coding:
Type of Variable
Pointers
Iterator
Handle
Globals
Statics
Member Variables
Defines, macros, enums, constants
Locals
Function parameters
Static Members
Function Names, Class Names, Methods
Syntax
Suffix with P
ex.
int* intP = new int;
Suffix with I
ex.
list<int>::iterator lI = m_list.begin( );
Suffix with H
ex.
TextureHandle texH =
TextureMgr::CreateTexture( );
Prefix with g
ex.
int g_int;
Prefix with s
ex.
static int s_int;
Prefix with m, lower case, then camel
ex.
int m_memberInterger;
All caps
ex.
#define PI 3.14
Start lower case, then camel
ex.
int localInt;
Same as locals
Same as member variables
Start upper case, then camel
ex.
void MyFunction( );
class MyClass
{
void CreateClass( );
};
Templates and interface classes have no
prefix or suffix
Use File and Function Headers
Keep code at max between 80-100 columns
Page 154 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
HLSL and FX Source Code Syntax
Files of type .fx are to be used to create an FXObject with. Vertex and pixel shaders are
to be defined in .hlsl files.
There should be no vertex or pixel shaders in an .fx file unless that vertex or pixel shader
is composed mostly of making calls to other shaders. For example, an .fx file that defines
a reflective object with bump map may define a pixel shader that calls a function to
compute the bump normal, then use that normal to compute the reflective color.
Type of Variable
Shared variable
Global variable to be set
per object
Output variable
Syntax
Prefix with gs
ex.
float3 gs_lightColor; //global shared light color
Prefix with go
ex.
float go_glowAmount;
Prefix with out
ex.
void Diffuse(float3 N, float3 L, out float out_dc)
{
out_dc = saturate( dot(N, L ) );
}
Page 155 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Menu Skin Specification
General File Layout
--------------------------* Header
All text before the header is skipped. A valid header is
of the form:
<EKSkin Width="800" Height="600">
Where the parameters 800 and 600 can be any integer value above 0.
These values specify the scale to use wile reading in the rest of
the file.
* Objects
Objects a placed between '<' and '>' characters. The object type
should be directly after the '<'. If an invalid or unsupported type
is specified, it will be skipped over. After the type all parameters
are specified (separated by white space) in the form:
ParameterName="ParameterValue"
The '>' goes after all needed parameters are specified. Invalid and
unused parameters are skipped over, and unspecified parameters are set
to default values.
* Comments
Any text that is not within an object tag <> will be skipped over
and can be used as comments.
Object List
--------------------------* Button Objects
General Parameters:
- HitBoxPosX
- HitBoxPosY
- HitBoxWidth
- HitBoxHeight
(pixels relative to screen)
(pixels relative to screen)
(pixels relative to screen)
(pixels relative to screen)
Page 156 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Contains 4 Image objects
-Disabled
-Normal
-Highlighted
-Selected
* Image Objects
General Parameters:
- ImgFileName
- ImgScrnPosX
- ImgScrnPosY
- ImgScrnWidth
- ImgScrnHeight
- ImgFilePosX
- ImgFilePosY
- ImgFileWidth
- ImgFileHeight
- ScaleStyle
(img path relative to this skin's directory)
(pixels relative to HitBoxPosX)
(pixels relative to HitBoxPosY)
(pixels relative to screen)
(pixels relative to screen)
(pixels relative to image)
(pixels relative to image)
(pixels relative to image)
(pixels relative to image)
(Method to scale the image)
* Cursor Objects
General Parameters:
Must contain 2 named image objects:
Normal
Normal Down
May contain other named Image objects such as
TextEdit
TextEdit Down
Grab
Grab Down
Etc.
* Drop Down Box Objects
General Parameters:
Derived from Button
Contains a ListBox
* Edit Box Objects
General Parameters:
Derived from Button
Contains a Text Display Object
* Key Link Objects
General Parameters:
Page 157 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
- Key
- Target
GAM400
Semester 7
(DirectInput keyboard scan code in hex with no prefix)
(mnu path relative to this skin's directory)
* List Box Objects
General Parameters:
- BoxHeight
(height in items)
- BoxPosX
- BoxPosY
(pixels relative to screen)
(pixels relative to screen)
- ItemHitBoxPosX
- ItemHitBoxPosY
- ItemHitBoxWidth
- ItemHitBoxHeight
(pixels relative to BoxPosX)
(pixels relative to BoxPosY)
(pixels relative to screen)
(pixels relative to screen)
- ItemTextPosX
- ItemTextPosY
(pixels relative to BoxItemHitBoxPosX)
(pixels relative to BoxItemHitBoxPosY)
- ItemTextSize
(height in pixels relative to screen)
- ItemUnselectedNormalTextColor
- ItemUnselectedMouseOverTextColor
- ItemUnselectedMouseDownTextColor
- ItemSelectedNormalTextColor
- ItemSelectedMouseOverTextColor
- ItemSelectedMouseDownTextColor
- ItemDisabledTextColor
(RGBA in hex format with no prefix)
(RGBA in hex format with no prefix)
(RGBA in hex format with no prefix)
(RGBA in hex format with no prefix)
(RGBA in hex format with no prefix)
(RGBA in hex format with no prefix)
(RGBA in hex format with no prefix)
Contains the following nested objects:
SliderBar
Image
(For Disabled)
Image
(For Normal)
Image
(For Highlighted)
* Text Display Objects
General Parameters:
- TextPosX
- TextPosY
- TextSize
- NormalTextColor
- DisabledTextColor
- TextString
(height in pixels relative to screen)
(RGBA in hex format with no prefix)
(RGBA in hex format with no prefix)
(Initial text string)
Page 158 of 159
Copyright © DigiPen
Villager Kisses
Technical Design Document
GAM400
Semester 7
Page 159 of 159
Copyright © DigiPen