ECE4893A/CS4803MPG: Multicore and GPU Programming for Video Games

Fall 2007

Homework #2: Direct3D First Person Shooter

Due: Thursday, Oct. 11 at 23:59:59 (via T-square)

New stuff:

• A note from Mukil Kesavan: "I created this new VC++ project template that can be used to compile Prof. Lee's examples with all the libraries and linker dependencies set correctly. Some people were having trouble getting the sample code to compile so I thought sharing this might be useful (would let folks concentrate on the actual problem at hand). There are instructions in the attached zip file on how to install the VC++ patch." Thanks Mukil! [Note from Aaron: The best way to set things up seems to vary from installation from installation; your mileage may vary. This patch is provided as-is, with no guarantees.]

Late policy: The homework will be graded out of 100 points. We will accept late submissions; however, for every day that is it is overdue (including weekend days), we will subtract 20 points from the total. For instance, it you turn it in late but turn it in by Friday, Oct. 12 at 23:59:59, we will take off 20 points. (We understand that sometimes multiple assignments hit at once, or other life events intervene, and hence you have to make some tough choices. We'd rather let you turn something in late, with some points off, than have a "no late assignments accepted at all" policy, since the former encourages you to still do the assignment and learn something from it, while the latter just grinds down your soul.)

We set the due date for Thursday since making a homework be due at midnight on Friday seemed cruel.

Staring with Prof. Lee's example Direct3D code as a base, write a simple "first person shooter" game with the behaviors described below:

• A single enemy (we'll only have one to keep the programming simple), which is randomly placed somewhere in the room at the start of the game (but not somewhere too close to the player), moves toward the player. You will need to experiment to find a good speed for the enemy; for the game to be playable, the enemy should not move too fast. The model you use for the enemy should "face" the direction it is going. (If you have time and want to try coding up more complex behaviors, such an enemy that can only "see" in a certain angular segment in the direction they are facing and who havs to turn to "search" for the player, go for it, but it is not required for full credit on this assignment.)
• The enemy moves in two dimensions (like the player) and appears to rest on the floor (i.e. no flying enemies.)
• The player may fire a projectile by pressing the space bar. The projectile starts from the player's location and moves in the direction that the player was facing at the time it was fired. (Note that for the game to be playable, the projectile will have to move much faster than the enemy.) To keep the programming simple, only one projectile may be "in play" at a time. The projectile disappears when it collides with a wall or the enemy, at which point a new projectile may be fired. We recommend representing the projectile using a small sphere. The collision detection with the wall need not be complex; one can declare a collision when the center of the projectile falls outsides the set of bounds determined by the walls.
• When the enemy collides with the player, the game restarts. A collision is declared to have occured when the enemy is within a certain distance of the player. You can determine a reasonable distance by considering the dimensions of your enemy model.
• When a projectile collides with the enemy, the enemy is destroyed and a new enemy is "spawned" at a random location in the room, To avoid the player dying too soon, the enemy should not respawn too close to they player (as was the case at the start of the game). A collision of the projectile with the enemy is declared when the center of the projectile is within some appropriate distance of the enemy.
• The enemy should be represented with a complex model of some appropriately terrifying and/or amusing menace. In Prof. Lee's example code, he used objects that were easily generated within Direct3D. For your enemy, you should find an appropriate model off the web and use that. A huge number of free Direct3D (.x format) models with nice textures and material properties can be found at www.turbosquid.com. If you click on the search button at the top, you can search by variety of criteria including file type. There are a lot of models you can buy, but don't bother with any of those since there are pleanty of free ones. The trickiest part is reading the model in; fortunately, detailed instructions on how to read and render .x format models with Direct3D (along with code snippets you should feel free to use) may be found at www.toymaker.info/Games/html/3d_models.html#3. It mentions the "hard way" and the "easy way." You should use the "easy way."

• You should keep Prof. Lee's walls, ceilings, and floor where they are, but you should replace them with new appropriate textures of your choosing, and hang something on the wall other than the Mona Lisa.
• You can remove the bouncing ball, spinning teapot, etc. from Prof. Lee's code, since they'll just confuse the player.
• You don't need to turn on and off the lights with different keys. Place a set of lights that you find interesting and leave them as is throughout the game.

• Any sound effects, since the class is not focusing on sound. (If you want to learn how to do this on your own and put some in, go for it!)
• Any intro screens. You can just jump right into the game.
• Any score keeping mechanism.
• Any fancy behavior when an enemy or the player is killed. The enemy can just disappear when it is hit by a projectile; it does not need to dissolve or explode. Similarly, when the enemy contacts the player, you don't need any 007-style dripping blood screens.
• Any serious "tuning" or "playtesting." This assignment is to get you accustomed to some issues in game programming, but is not intended in any way as an exercise in game design. (That said, you should probably lean towards making the game "too easy" instead of "too hard," since that will make it easier for us to make sure everything works.)
• Decent collision detection. We're telling you to do something very simple in this assignment, so there may be times where it looks like things aren't colliding and you code will say they are or vice-versa. (Later on in the class, we'll study more accurate but computationally intensive algorithms for collision detection).

Discussion board: We have set up a "HW #2" discussion board where students can discuss the homework and in particular ask questions that the professors, TA, and other students can help answer. (Try to avoid posting significant chunks of code on the discussion board; those are probably best directly e-mailed to the professors and the TA.)

Deliverables: Package everything needed to compile and run your game (3D data file, textures, code, etc.) and upload them to T-square as a zip file, StuffIt file, or gzipped tar file. Include "HW2" and as much as possible of your full name in the filename, e.g., HW2_Aaron_Lanterman.zip. (The upload procedure should be reasonably self explanatory once you log in to T-square.) Be sure to finish sufficiently in advance of the deadline that you will be able to work around any troubles T-square gives you to successfully submit before the deadline. If you have trouble getting T-square to work, please e-mail your compressed file to lanterma@ece.gatech.edu, with "MPG HW #2" and your full name in the header line; please only use this e-mail submission as a last resort if T-square isn't working.

When you submit your homework, please tell us an approximate number of hours you spent working on it, as well your thoughts on the homework, particularly suggestions for improving it in the future. (If you don't have any suggestions, that's OK, just tell us an approximate number of hours.) This will help us with future offerings of the class.

Ground rules: You are welcome to discuss high-level implementation issues with your fellow students, but you should avoid actually looking at one another student's code as whole, and under no circumstances should you be copying any portion of another student's code. However, asking another student to focus on a few lines of your code discuss why a you are getting a particular kind of error is reasonable. Basically, these "ground rules" are intended to prevent a student from "freeloading" off another student, even accidentally, since they won't get the full yummy nutritional educational goodness out of the assignment if they do.