ECE4893A/CS4803MPG: Multicore and GPU Programming for Video Games

Fall 2008

Homework #5: Shaded First Person Shooter

Due: Wednesday, Nov. 5 at 23:59:59 (via T-square)

Late policy: The homework will be graded out of 200 points. We will accept late submissions; however, for every day that is it is overdue (including weekend days), we will subtract 30 points from the total. (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.)

In this assignment, you will create a first-person shooter that employs a sophisticated rendering effect such as shadow mapping or normal mapping, as well as a post-processing effect. The main purpose of this assignment, besides getting practice with creating shaders and integrating them through an API, is to create something awesome that you can demo for potential employers.

This assignment is much more ambitious than the previous ones, so do not wait until the last minute to start it. We are giving you two weeks for a reason.

The basics: Staring with Prof. Lee's most excellent DungeonShooter code as a base (see the link under Session 20 on the main class webpage), develop a simple "first person shooter" game with the behaviors described below:

• A single enemy (we'll only demand one to keep the programming simple, but if you want to put in more, go for it), 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 has to turn to "search" for the player, have fun, 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.)
• 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 fired by the player 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. Please don't use the teapot, a cube, or a sphere; you know, use something cool.

• You should keep Prof. Lee's walls, ceilings, and floor where they are. You can use the existing textures or replace them with your own.
• Concerning the various spinning teapots, the Mona Lisas, etc. you can leave them in, take them out, or replace them with decorations of your own choosing however you see fit.

Your game does not need to have...

• Any additional sound effects, since the class is not focusing on sound.
• 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 your code will say they are or vice-versa.

The 3-D shader part: Enhance your game in one of two ways:

1. Have the enemy cast a shadow via the shadow mapping technique discussed in lecture. If you take this approach, you may want to adapt code from one or more of the following examples (be sure to give credit in your comments):
   • Riemer's Explanation of the Shadow Mapping algorithm
   • How To: Implement Shadow Mapping
   • Shadow Series 1: Basic Shadow Mapping
   • Shadow Mapping by Andrew Joll
   • Shadowing in XNA by Julian Spillane
   • Small pre-pre-beta shadow mapping library
   To keep things simple, you only need to have one of the lights cast shadows, and you only need to cast shadows on the floor. If you can do something more sophisticated, go for it, but it's not required.
2. Make the floor look much cooler by applying normal mapping to it. (Notice I'm suggesting the floor since applying normal mapping to a plane is much easier than appying it to an arbitrary surface.) This will involve re-writing Prof. Lee's multi-light shader to operate in a Phong style instead of a Gourard style; i.e. you'll need to shift much of the lighting computation from the vertex shader to the pixel shader. You can find some normal maps online (just do a google search on "normal maps") - look for images where the x, y, and z are coded as red, green, and blue. Or, you could try creating your own normal map somehow.

The 2-D postprocessing part: Add a cool non-trivial postprocessing effect to your game, something that makes sense within the context of the gameplay. It might be an effect that runs all the time, or when the player fires, or when the monster is hit, or when the player dies; or, if you've gone all-out an implemented some non-required gameplay enhancement, it might be associated with that enhancement. By non-trivial, I mean that it shouldn't just pixelwise change the colors without some sort of interesting inter-pixel interaction (i.e. don't do something like just swap red and green or get rid of all the blue). You are welcome to adapt code you find on the web or in books and such, as long as you give the original author appropriate credit in your comments.

Discussion board: As an experiment, we have set up a "HW #5" discussion board where students can discuss the homework and in particular ask questions that the professors 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.)

Who to ask questions of: Questions about the operation of the DungeonShooter code should be addressed to Prof. Lee. Questions about the requirements of the assignment should be addressed to Prof. Lanterman.

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 or gzipped tar file. Include "HW5" and as much as possible of your full name in the filename, e.g., HW5_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 #5" 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.