ECE4893A/CS4803MPG – Homework #6

ECE4893A/CS4803MPG – Homework #6

ECE4893A/CS4803MPG: Multicore and GPU Programming for Video Games

Fall 2010

Homework #4: Shaded First Person Shooter

Due: Tuesday, Nov. 23 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,
we will subtract 30 points from the total. For purposes of assigning a
late penalty, Thanksgiving break, November 25 to 28,
will count as one “day,” since I
know many of you will have travel and family obligations. So if you turn
in your late homework after midnight on the 24 but before midnight on the 28,
the late penalty will be 60 points. A turn in on Nov 29 would have a late
penalty of 90 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.)


Team formation: This homework may be completed by “one-person teams”
(i.e. individually) or “two-person teams.”
If you are going to work as a two-person team, please
let me know who is on your team by the start of class on Thursday, November
11,
via an e-mail with the subject “HW #4 team: ” followed in the subject line
with the names of who is on your team.
Once you start actually writing any code as a team, you are bound
together as a team; you will not be able to “fire” a lackluster teammate,
since there
will be no way of determining who wrote what code by that point. If I don’t
hear from you about forming a two-person team by the start of class on
November 11, I will assume you are a one-person team.
More work will be
required of two-person teams,
so think carefully before deciding to form one.


The goal: 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 12 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.

Concerning the adaptation of Prof. Lee’s code:

  • 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.

  • Please keep the multiple light sources.


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.

Of course, we are hoping you will have fun with this assignment, so if
you want to add various enhancements and have time, go to town!


The 3-D shader part: If you are a one-person team, enhance
your game in one of the two ways listed below. If you are a two-person
team, you must implement both enhancements.

  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):

    I’m sure google searching will turn up more examples, and you can also look
    in the various XNA books that you’ll find at various bookstores.
    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 want
    to 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.
    (Instead of normal mapping, you are welcome to
    propose some sophisticated
    shader effect of your own devising. It must be similiar
    in complexity to normal mapping. Before embarking on
    an alternate path, be sure to discuss your proposal with Prof. Lanterman
    to make sure your proposed shader
    is sufficiently complex and get his approval.)
    You are welcome to borrow code from tutorials, blog posts, etc. you find
    online; just be sure to give appropriate credit in your comments.

    If you wish,
    you may choose to have the bump mapping effect only apply to one
    of the light sources. It is not that much more difficult to have bump mapping
    apply to all of the light sources; I am giving you the option of only doing so
    for one of the light sources in case you are working with a less capable
    GPU
    that may run out of registers or some hit up against similar limitation. One
    of the best ways to make sure the bump mapping effect is working is to
    turn various lights on and off, which Dr. Lee has commands for this
    built into his code. If
    your bump mapping only applies to one light, you should code in some sort
    of motion for that particular
    light – have it move around somehow – so that the bump
    mapping effect is easier to observe.


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 or warping (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.
(All teams, both one-person and two-person teams
must implement one 2-D postprocessing effect.)


Deliverables: One-person teams should
package everything needed to compile and run your game
(3D data file, textures, code, etc.), along with a README file briefly
describing
what techniques you implemented and any particular problems or issues you
might have run into,
upload them to T-square as a zip file or gzipped tar file.
Include “HW4” and as much
as possible of your full name in the
filename, e.g., HW4_Aaron_Lanterman.zip. (The upload
procedure should be reasonably self explanatory once
you log in to T-square.)


For two-person teams, one student should be the
“official uploader,” and should upload the materials described above. In
the comment box and in a README file included in code itself, give
the name of the student you worked with.
The “non-uploading” student should still “turn in” a homework, but their
homework will consist of
simply typing “Worked as a team with…” as appropriate
in the comment box,
and not upload the same file.
This will avoid us having to download large
duplicate files.
(The “non-uploading student” should
be sure to remind the “official” uploader to do the uploading; cries from
Student X along the lines of
“oh, Student Y said they’d upload it but they didn’t!” will not fall on
sympathetic ears.)


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 #4” 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.


Ground rules: Obviously, two-person teams can and should fully
collaborate with each other, but within that modification,
“teams,” whether they are one-person or two-person, should
act as “people” under our typical previous rules.
“Teams” are welcome to discuss
high-level implementation issues
with your fellow “teams,”
but you should avoid actually looking at
one another “team’s”
code as whole, and
under no circumstances should any “team” be copying
any portion of another “team’s” code.
However, asking another “team” to
focus on a few lines of your code to discuss
why you are getting a particular
kind of error is reasonable.