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.
<!–[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.
(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.”
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., 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.