DPS905 Hic Sunt Dracones

GAM670/DPS905 | Weekly Schedule | Student List | Project Requirements | Teams and their Projects | Student Resources

Razed by Fire

Project Marking Percentage

Group work:      25%        (25 <= xx <= 50)
Individual work: 75% +      (50 <= xx <= 75) 
-------------------------
Total           100%

Information

Our code uses the June 2010 DirectX SDK. You'll need to uninstall the August 2007 SDK, and install the June 2010 SDK. Download the code from svn trunk, and compile.

All resource files required for running the game (audio, models, textures) can be found in \branches\resources

Audio files (.xwm) are encoded in the xWMA format, which offers 30x compression ratios over regular WAVE files. The audio engine is perfectly capable of playing .wav files without any modification, but you should encode them using the xmaencode tool located in the DirectX SDK Command Prompt before committing to the repository.

Right now audio files are only played globally. Jon will be implementing X3DAudio within the next few days.

Repository

Repo path

• old path

  svn://zenit.senecac.on.ca/dps901_103rep8

• new path

  svn://zenit.senecac.on.ca/dps905_111rep5

Trunk Status

Current repository status information can be found by typing "!svn" in the IRC chat channel

Team Members

Group Email

• Daniel Hodgin
• Jon Buckley
• Kaitlyn Callow
• David Perit

Meetings

• IRC
  • Sundays at 9pm in channel #HSD on irc.FreeNode.net

Phase 1

Proposal

For our second run at this project we will be adding more functionality to the game. More in depth COLLADA loading, more refined particle systems, refined XAudio, and visibility performance increases.

Old history from DPS901

Phase 1

Proposal

Our game is a third-person action shooter where the user is a dragon that is flying over villages and attempting to reign havoc. In reaction to the attacks soldiers gather in increasingly greater numbers and try to fight back against the dragon. The dragon will be able to destroy both the villages and the soldiers by shooting fire at them. The rate that villages & soldiers appear at will increase over time making it more difficult to kill enough to keep their numbers down.

A bar at the top of the screen will represent how close the number of soldiers is to reaching the amount required to 'fight you off'. Once the bar is full you the game ends and your score is awarded. The goal is to kill soldiers at a fast enough rate to lower the bar and survive the longest while destroying all the villages that you can.

Some technical design challenges include adding controller support for mouse, keyboard and maybe joystick and algorithms for choosing where and when to create new buildings or villagers.

The initial version of our game will include:

• villages as simple cubes
• soldiers as simple rectangles
• flat level ground for the world
• ability to look around with a mouse and steer with keyboard. Movement is on x and y planes but not z, the dragon is at a fixed elevation in the air. The process of essay writing will be much easier with MarvelousEssays.Com as there are a lot of highly professional and talented writers who are always eager to help you out with any sort of academic assignments regardless of the complexity levels. The process of essay writing will be much easier with MarvelousEssays.Com as there are a lot of highly professional and talented writers who are always eager to help you out with any sort of academic assignments regardless of the complexity levels. I do know what I�m talking about! I do know what I�m talking about!
• a 'shoot' mechanic to attack cubes and rectangles

Later versions -could- include (time permitting):

• increasing numbers of soldiers with bar showing representation of numbers
• dynamic village and soldier placement
• multiple attacks using a 'rock paper scissor' concept with certain attacks needed for certain targets. Make the user need to think about their attack choice
• some visceral feedback to user (such as: slight screen bob with dragon's wings, more dramatic elongated perspective when flying forward to make it feel faster, screen shakes and bobs to various things like attacks, etcs)
• extra terrain details
• line of sight checks
• collision detection

Likely Improvements To Engine

primary focus areas

graphic improvements	Daniel, Kaitlyn
game logic, camera, world	James
improvements to audio, specifically to use OOG files	Jon
particle effects	Kaitlyn
collision detection, enemy management	Steven
add stock objects (sphere, torus, etc.), more primitives	Steven
import model script	Daniel

other possible

computer a.i. logic

comprehensive camera motion

Game Mockups

• Objects

• Interface

• Possible Map of the World of the Game

Phase 2

Information

Class Diagram

Collision Detection

For collision detection, we used axis-aligned bounding boxes (AABB). These build an imaginary box around a visible object, as defined by:

• minx
• miny
• minz
• maxx
• maxy
• maxz

These specify the minimum and maximum bounds of the bounding box in world space. From these, collisions (or general overlap) may be determined via the separating axis theorem. This theorem can be applied to three-space using the name separating plane theorem and states that "if two convex objects are not penetrating, there exists an axis for which the projection of the objects will not overlap." In implementation, this can be done as such:

typedef struct Rect3D {
    float minx;
    float miny;
    float minz;
    float maxx;
    float maxy;
    float maxz;
};

// AABB Collision Detection in C
int doesOverlap(Rect3D a, Rect3D b) {
    return !( a.minx > b.maxx || a.maxx < b.minx
        || a.maxy < b.miny || a.miny > b.maxy
        || a.maxz < b.minz || a.minz > b.maxz );
}

Note that AABB vs. AABB collision is one of a vast number of cases. For a more comprehensive listing, see Real Time Rendering. Also, for performance increase one may wish to investigate spatial partitioning.

Screenshots