ECE4893A/CS4803MPG – Homework #2

ECE4893A/CS4803MPG – Homework #2

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

<!–[I’ve gotten some good questions on this homework; I’ve included some
clarifications and modifications in the writeup below in boldface.]

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.
    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
    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
    . It mentions the
    “hard way” and the “easy way.” You should use the “easy way.”

Concerning the adaptation of Prof. Lee’s code:

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

Your game does not need to have…

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