Technical Design Document

Game: D'bora

Team: Nova

Class: GAM300F 2014

Team:

Joel Sitte : Producer

-Audio Integration, Automation, Replay

Wesley Pesetti : Associate Producer

-LUA Integration

Alex Wilkinson : Physics Developer

-Physics System

Jordan Logan : Graphics Developer

-Direct3D Integration

Oland Pelton :Engine Developer

-Input System, Emitter System

Alex Troyer : Technical Director

-Core Engine Design, Meta Systems

Erik Zeiger : Engine Developer

-Memory Manager

Shane Pierce : Graphics/UI Developer

-Direct2D Integration, UI Systems

Ryan Masserman : Lead Designer (Game Design Student)

-N/A

Anastasia Groves : Sound Design Lead (Music and Sound Design Student)

-N/A

Ryasa Harris : Sound Effects Designer (Engineering and Sound Design Student)

-N/A

Architecture Overview
The engine architecture for this project will be component based. There is an overarching manager that controls a bunch of systems, where the systems then manage a bunch of different components attached to objects.

All the main systems in the game are Graphics, Physics, Lua, Audio, Game State Manager, and Space Manager.

Graphics, Physics, Lua, and Audio all have their own sections so for more information go to those.

The Game State Manager essentially keeps track of a script it uses to manage a state that the game is running in. For example, the GamePlay state handles everything that is related to the game play of the game while the Menu state handles menu actions.

For Spaces, there is an entire article on those: Spaces.

One part of the engine that ties a lot of the pieces together is the Meta System. This allows for type reflection at run time, binding to Lua, and tons of other features.

Events allow for communication between different systems and objects where you can broadcast to an Game Object's components or to anything registered. For more information, refer to the Events article.

Game Objects are a main piece to the engine. You are able to attach different Components to an object at any time and even remove them. There are some checks done at initialization for dependencies on components so it is a good idea to know these ahead of time. A lot of the heavy work of Game Objects is taken by the Meta System since it handles serialization of the all the components automatically as long as it is registered correctly. To create a Game Object, that should be done through a Spaces where the Game Object will live in.

3D Graphics
The 3D graphics will be using DirectX 10/11 for the graphics API.

Rendering
The main rendering pipeline is done through a deferred rendering algorithm.

All graphics objects are placed in the scene graph of the space that the object is part of. The scene graph is traversed to create a render list that contains all the info that is need to render the object. This is where the transparent objects are split from the none transparent objects by placing them in a separate render list. Inside the render list are render nodes that contain all objects that have the same model and textures. This is to minimize the number of state changes.

Upcoming Changes:
 * Tiled Deferred rendering to reduce the number texture access while also culling some lights out.

Models
Models are loaded from a custom file format that is created by the art pipeline tool. They are then loaded into the model manager where they can be accessed by the name of the file that the model was loaded from.

Currently the vertices for the models have
 * Position
 * Normal
 * UV
 * Tangent

Lights
The illumination model used is the basic Phong Illumination model.

Some other possible illumination models to use are:
 * Cook-Torrance
 * Ward
 * Physically based Phong

Transparency
Transparency is being done after the deferred rendering with a basic forward rendering. Transparency is calculated with pre multiplied alpha.

Currently there is no light rendering, this is soon to change though one of the following techniques.


 * Forward+ rendering: This should work well with Tiled Deferred rendering.
 * Light Probes: will give some light but not best
 * Texture space light calculations: Creative Assembly does this

Debug Draw
Debug draw is done with an immediate mode architecture that will only draw when debug draw is enabled.

The current features for debug draw are:
 * Draw Point
 * Draw Line
 * Draw Wireframe Cube
 * Draw Wireframe Sphere

All said features can specific color of the lines

To turn on debug draw press: ctrl + d

Upcoming changes:
 * Categories: With the amount of debug draw calls that are being made, the screen is getting cluttered. So there will be tags that can be added to a debug draw call. We can then turn on and off different categories.

2D Graphics
The 2D graphics system uses Direct2D.

With Direct2D we are able to use vector art as well as traditional sprites for anything in HUD / UI space. Our font rendering as well uses Direct2D to as the renderer.

PivotTransform
The UI design is based on being able to change pivots and alignments of all objects in 2D space. Therefore every UI object requires a PivotTransform component.

With pivot transform The UI can be aligned to positions inside a bounding area. For instance we can easily align an object to be 10 pixels from the bottom of the screen and 10 pixels from the right side of the window at any resolution or aspect ratio.

Panel
Panels hold a collection of panels and other misc components like buttons and labels. The important thing is that these define there own coordinate space for any objects that they hold. The panel's width and height is now the bounding box for the objects inside the panel. If the panel moves, all the objects inside the panel move with it, and they are unaware of the change.

Forms
Forms are like panels except they only hold panels. They also have a background. They are meant to be the top level of any menu.

Audio Implementation
This engine utilizes an integration of FMOD Studio to manage all audio assets as well as play them in game.

There are a variety of components in engine to allow for use of audio assets including:

SoundSystem

This is the core system for the audio system. It is responsible for loading the FMOD projects included with the build, individually loading sound assets (also called events by FMOD), as well as managing components called SoundSpaces

SoundSpace

This component is responsible for all instantiations of FMOD events and allows the user to adjust the volume, mute, and parameters of music or sound effects. When the user interfaces with the sound system through LUA script they are interfacing with the sound space for that level.

SoundInstance

This component is a wrapper around the FMOD event instances to allow for easy manipulation of the event instances including playing, pausing, setting and getting parameters, restarting or fading the tracks.

SoundFileHandle

This component contains the event descriptions that are used to create sound instantiations.

The procedure for integrating the FMOD studio builds into the latest project is located here.

Physics Body
The core component to be attached to an object if it wants to run through the Physics engine. It holds data such as the object's velocity, acceleration, density, bounciness, and friction.

Colliders
A collider determines the shape of the object's collision. Currently implemented is a Sphere, an Axis Aligned Cube, an Oriented Cube, a Horizontal Arc, and a Generic Rigid shape.

Broad Phase
Our broad phase is a AABB Tree that outputs a list of possible collisions. Every collider when initialized, will add itself to the tree in the physics system.

Collision Detection
For advanced collision detection, we have implemented the Gilbert Johnson Keerthi Algorithm along with the Expanding Polytope Algorithm. This allows for detection between any two convex 3d shapes.

Collision Resolution
After checking for collisions a simple 3d positional correction is done to separate overlap. Then an impulse based collision resolution calculation occurs to change the objects' velocities.

Multiplayer Implementation
Multiplayer will be local co-op on a shared screen with gamepad support for player control. A player can drop out of the game at any time, but if attempting to join will be made to wait until the current encounter is cleared. Each gamepad will have an associated object, each connected to a managing system, which will query the status of every unconnected gamepad every few seconds to see if an attempt to connect a new controller was made. A camera controller is used to keep all players inside of the view. A special component can be attached to any object, which registers it with the camera controller system and contains information necessary for consideration when the camera moves to keep all objects within its field of view. The camera has a small deadzone of movement where it won't attempt to follow players (to prevent small rapid movements from becoming nauseating) and its pan speed is a function of distance that increases exponentially, so small adjustments are made slowly, but sudden adjustments over a long distance will be made quickly. The camera angle will not change, and will remain top-down. A bounding circle is computed that includes the bounding circles of all objects with camera focus components attached to them, and the camera zooms out to fit. There is a minimum level of zoom, but no cap on maximum, instead, individual "rooms" will be of a size where should players force the camera to a max outward zoom, objects will still be easily visible.

Coding Methods
Coding Standards

Debugging
Debugging in this project mainly uses a command prompt that can be accessed through the command line parameter "--Console" when starting the game up. Here is where errors for Lua will show up as well as any printing from inside the project, Lua, or through our assert system.

While running the game, press F3 to display debug information where you can see FPS, a bar graph of how long each system is taking per frame, and a total running number of game objects in each space. By pressing F7, you can see individual objects in each space and their position in the world.

Pressing Control + D turns on debug drawing functionality which is used for drawing collision on an object and used in other situations like AI.

We also have an assertion system that can be view by going to this article: Logging

Archetype Editor
We will need a tool in order to create and modify archetypes in engine. Here we will be able to modify all properties on the archetype and add and remove components.

Room Editor
Seeing as we are going to create Rooms for our game and then piece them together, we need a way to create these rooms.

The approach for this is that we will create the layout of the room through a grid system in game where we place the floor down and then the walls are created from going around the floor.

While the floor placement is grid placed, the object placement should be free from the grid and moveable on all axes.

In the room editor, you should also be able to create objects from archetypes and modify the different properties of those objects from the archetype as well.

Art Pipeline
The Art Pipeline is a small console program that will convert FBX files and textures files if need into a custom binary format that can be easily read. The files will be converted by the FBX SDK while textures will use the DirectXTex library since it can open any format. The art tool will make sure that the models are centered and scaled to the right scale. The design of the tool is to be a fire and forget design to reduce the amount of user error.

Scripting
We will be using Lua to do all our scripting where the plan is to do all our gameplay code in there. To bind C++ code to Lua, this article goes over that: How to use the Meta System

For more examples of scripting and how to use it can be found in this article: Scripting

Tools and Editor Instructions
Editor Tutorial

Art Pipeline Tutorial