Perplexed Technical Design Document

Technical Design Document GAM400

Perplexed Michael Moore

Perplexed Technical Design Document

Infinite Sadness

Version 1.0

May 23, 2006

Summer 2006

GAM400A

Michael Moore

Technical Overview……………………………………………….……………………..3

Cross-Platforming…………………………………………………………….…...3

Minimum Requirements…………………………………………………….…….3

Preferred Requirements……………………………………………………….…..3

Third Party Tools………………………………………………………………….3

Risks……………………………………………………………………………….4

Gameplay…………………………………………………………………………………5

Game Objects……………………………………………………………………...5

Physics…………………………………………………………………………….5

Scoring/Victory……………………………………………………………………5

Coding Standards………………………………………………………………………..6

Main Game Loop………………………………………………………………….6

Rendering Loop………..………………………………………………………….6

File Formats……………………………………………………………………….6

Comments…………………………………………………………………………7

Naming Conventions……………………………………………………………...7

Installer……………………………………………………………………………8

Source Control…………………………………………………………………….8

Artificial Intelligence…………………………………………………………………….8

Networking……………………………………………………………………………….8

Graphical User Interface………………………………………………………………...8

Graphics…………………………………………………………………………………..9

Culling…………………………………………………………………………….9

Particle Effects…………………………………………………………………….9

Lighting……………………………………………………………………………9

Translucency………………………………………………………………………9

Camera…………………………………………………………………………..10

Text………………………………………………………………………………10

Audio…………………………………………………………………………………….11

Libraries………………………………………………………………………….11

Sound Effects…………………………………………………………………….11

Music……………………………………………………………………………..11

Milestones……………………………………………………………………………….12

Pitch Proposal……………………………………………………………………12

Engine Proof……………………………………………………………………..12

First Playable…………………………………………………………………….12

Pre-Alpha………………………………………………………………………...12

Alpha……………………………………………………………………………..12

Beta………………………………………………………………………………13

Final……………………………………………………………………………..13

Timeline…………………………………………………………………………………13

Signoff…………………………………………………………………………………...14

Technical Overview

Cross-Platforming

For this project we will only be developing for the PC platform.

Minimum Requirements

Operating System: Windows 98 or higher

Processor Speed: 400 MHz

Video Card: NVIDIA GeForce 2 or Higher

RAM: 64 MB RAM

CD – ROM: 6x CD – ROM

Mouse and Keyboard

Preferred Requirements

Operating System: Windows XP

Processor Speed: 1.8 GHz

Video Card: NVIDIA GeForce 6600

RAM: 512 MB RAM

CD – ROM: 56x CD – ROM

Mouse and Keyboard

Third Party Tools

No third-party tools or engines will be used in the creation of this project. The game engine will be written from-scratch at the start of the project using OpenGL.

Risks

· Particle Effects/Special Visual Effects for the polish are expected to be difficult to program as no one on the team has any experience implementing them.

· Because Adam who is writing the 3D engine has not written a 3D graphics engine before, there could be problems implementing texture mapping or the advanced OpenGL extensions we are wanting to implement.

· Chris may not get very far in writing the random level generator and while the contingency plan is to have Adam take over the implementation of it second semester it may be difficult for him to pick up right away.

· Senioritis may take hold and may contribute to lack of motivation during second or even this semester.

Gameplay

Game Objects

Game objects consist of the puzzle pieces and the arena itself. The shape of the arena itself will change into different interesting shapes that you have to build using the puzzle pieces. In the first few stages the arena will be shaped in a 3x3x3 vox grid. The pieces will also be simple at first, and will be quite small (in the first few levels no pieces will have more than 4 connected cubes (Tetronimos)). The later levels will introduce 5 connected cubes (Pentanimos) and even more connected cubes. Some examples of the later arenas will be a pyramid, different diamond type shapes, a 4x4x4 cube and a 5x5x5 cube.

Physics

3D rotations and translations will be controlled by different keys on the keyboard and should be simple to implement. Collision detection will be required within the arena to ensure that no two pieces can occupy the same space. Since every piece is entirely consistent of cubes, collision detection should be as simple as checking against a three dimensional array of bools that represent the voxes in the arena.

Scoring / Victory

In Puzzle Mode the high score will be the highest level the player has completed. If the player completes all the levels (yet to be determined), a victory screen will be displayed.

In Action Mode there is no victory condition, only a high score given for the number of randomly generated puzzles that were completed in the allotted time.

In Zen Mode there is no victory condition, only a high score given for the number of randomly generated puzzles completed during that game execution.

Coding Standards

Main Game Loop

The main game loop checks for GetMessage() to return false and then exits. The important calls include checking for keyboard and mouse commands (KB::Update() and MM::Update()) and the render managers Prepare() and Render() functions (also known in some other games as Update() and Draw()).

Rendering Loop

3D arena and puzzle pieces will be drawn first using gluPerspective() and after all 3D calculations have been done they will be saved by pushing back the perspective and modelview matrices and calling gluOrtho() to start overlaying 2D GUI. Wrapper functions are provided by the engine to provide the GUI programmer with a convenient interface.

File Formats

All 3D models needed by the game will be hard coded into a module in the 3D engine. For all textures and 2D sprites, we will use the Targa (.tga) file format. The targa format was chosen as it allows for a 32 bit pixel format (aligned on word boundaries), with one byte allocated to red, green, and blue, and also an alpha channel for transparency. We will use Adobe Photoshop for editing the alpha channel and saving to the targa format.

Comments

Comments are expected to be internally in every function for most lines of code. Here is an example code snippet:

void CGame::PositionAndRotate(float xPos, float yPos, float zPos, float xAngle, float yAngle, float zAngle, Cube2 cube)

{

glPushMatrix();

// position the cube

glTranslatef(xPos, yPos, zPos);

// perform the rotations

glRotatef(xAngle, 1.0, 0.0, 0.0);

glRotatef(yAngle, 0.0, 1.0, 0.0);

glRotatef(zAngle, 0.0, 0.0, 1.0);

// draw the cube

glBegin(GL_LINES);

DrawCube(cube);

glEnd();

glPopMatrix();

}

This function doesn’t need a function header as the functionality can be inferred from the function name and parameter list. The 3 operations of translating and rotating the cube are clearly marked and also the code for drawing the cube. This is the type of comments we expect to find in the code for the project.

Naming Conventions

We don’t like really strict naming conventions, so we will mostly let ourselves keep the coding style we have gotten accustomed to. We will however, keep the most standard of naming rules:

· All constants (whether using #define, const, or enum) will be written in ALL CAPS. If the constant name is composed of 2 or more words an underscore (_) will be placed between them

· All file names will begin with a C, except for ones not written by the programmers and also with the exception of winmain.cpp.

· All classes will start with a C (exception again given to classes that we have not written ourselves)

Installer

Adam will write the installer second semester using either the Innu installer or Microsoft .net Install Shield—which ever proves easier to use.

Source Control

We will be using Tortoise SVN as our source control program.

Artificial Intelligence

Due to the genre and design of our game (Puzzle genre), no artificial intelligence will be required for this project.

Networking

Also due to the game design and scope of our project, there will be no networking required for this project.

Graphical User Interface

See the section entitled “Render Loop” for an explanation of how the 2D GUI will be drawn over the 3D interface.

The Title screen will transition to the other gameplay screens by left-clicking on the corresponding icons. Pieces to be chosen from the object tray can be picked either by pressing ctrl + wasd or ctrl + arrows or simply by clicking and dragging them outside of the tray.

The GUI will be worked on immediately by Chris at the start of the project.

Graphics

Adam will be responsible for writing and maintaining the 3D graphics engine for this project. The 3D graphics engine will be written using the OpenGL graphics library. No vertex or pixel shading will be used in the graphics engine and we will strictly be using the fixed function pipeline functions provided by OpenGL. 3D objects will be rastered using glBegin() and glEnd() however Adam will look into the vertex buffer extension for optimizing. All models will be hard-coded into the project. Models are constructed in Models.cpp.

Culling

All triangles in our engine will be ordered counter-clockwise as by default all clockwise are culled. Culling in OpenGL will be enabled by calling glEnable(GL_CULL_FACE).

Particle Effects

Particle effects can be accomplished by calling glBegin() with GL_POINTS to draw single pixels. More on how to do this will be researched later in between semesters.

Lighting

We will make good use of lighting in OpenGL and will experiment with different levels of attenuation for specular highlighting. Wrapper functions will be written for moving and manipulating relevant lighting parameters.

Translucency

Translucency will be present in both the 2D GUI and the 3D environment. In the 3D environment, objects can be transparent by calling glEnable(GL_BLEND) ,glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA), and glColor4f(). The fourth parameter in glColor4f will be the alpha (opacity) value of the object. In 2D, translucency can be accomplished by the targa class, and by calling glDrawPixels(GetWidth(),GetHeight(), GL_RGBA, GL_UNSIGNED_BYTE, GetImage()).

Camera

The camera system has already been implemented. We use spherical coordinates to keep the camera on a sphere and always looking at the point (0,0,-5), in which the arena is always centered on. The camera is controlled using the gluLookAt() function.

Text

Adam will write a text class for rastering 2D text onto the screen for the GUI. All text characters will actually be small .tga files. Adam has some art experience and will create the font using Adobe Photoshop.

Audio

Libraries

We will be using the FMod library to do all audio. Adam has written a sound class as a wrapper around the FMod library.

Sound Effects

We will need to find sound effects off the web for the following game operations:

· Placing a game piece inside the arena

· Game piece collisions

· Completing a level

· Running out of time

· Winning the game

· Selecting a menu option

Music

We are hoping to get a friend of ours, Luke Lenhart to compose a repeatable 30 second music clip in .ogg format for our game. If we can’t get him to do that, there will not be any music for our game aside from the juke box if time permits.

Milestones

Pitch Proposal

The pitch proposal will be presented by Adam in front of the class. Chris will run the controls for the power point presentation.

Engine Proof

By engine proof we would like to have:

· The in-game HUD completed

· A title screen

· Basic camera controls working

· Basic controls for rotating and moving game pieces working

First Playable

By first playable we would like to have:

· Three playable puzzles that are able to be solved

· Three playable game modes

· All Menu screens completed

· Random level generation 66% complete

· Particle effects 30% complete

Pre-Alpha

By pre-alpha we would like to have:

· Sound Effects

· 10 playable levels

· Random level generation 77% complete

Alpha

By Alpha we would like to have:

· 15 playable levels

· Particle effects 50% complete

· Texture mapping

· Random level generation 85% complete

Beta

By Beta we would like to have:

· 25 playable levels

· Random level generation 90% complete

· Skybox

· Vertex buffer extension

Final

By Final we would like to have:

· 30 playable levels

· Random level generation 100% complete

· Game completely done and polished

Project Timeline

- See the Microsoft Project file “Perplexed.mpp”

Sign Off

By signing my name below, I verify that I have read and understand all material in this document and agree that this is the game that I want to create. I will do the best that I can to create the game based on the design presented, and I will accept any changes and modifications to these rules based on the decisions of the designer during development.

Adam Henderson (Producer)

____________________________________

Chris Glass (Designer)

Perplexed Technical Design Document