This assignment is due
by Sunday, December 11, 2016 by 11:59pm.
At long last, you look around. Every enemy has been defeated and you
are left standing. You did it, you are truly the Ruler of Olympus
and have conquered the mountain. You make your way back into the city and
head towards the Guild Hall. As you wind through the streets,
a crowd slowly gathers and follows you to the center. When you get to
the Guild Hall, the robed woman is already waiting outside. Once you
begin climbing the stairs, the woman removes her hood and greets you.
Before you can finish your thought, she gestures towards the
spires and fireworks shoot out from each one. When the flames subside,
you recount the spires and notice one is much greater in height than
the others. The woman speaks.
"Yes, I have been following you for some time now. We had
known at a very young age you would be the one to claim Olympus. The travelers you met along the way were
not by chance, but messagers sent forth to aid you and help convince
you of your powers. Now, fulfill the prophecy and accept this key to
the Guild Hall."
To thunderous applause and cheers, you take the key and process into
the Hall.
Part I - Accept Your Throne
Inside the Guild Hall, there is a great feast prepared. You are ushered
to the head of the table underneath the central shield hung on the
wall. You remember this shield as the shadow passing through a flame,
but it has changed. The shadowy figure is no more and you see yourself.
The flame has been extinguished and a great aura radiates around your
silhouette. All these people surely expect you to do or say
something. They quiet down and slowly take their seats. Not knowing
what to do, you take out your book and begin scribbling furiously. When
you are finished, you walk to the raised platform and post the new
Guild Hall rules.
For this final assignment, your Guild will implement...whatever you
want! The final project for the course is an open-ended, student
specified project that demonstrates skilled usage of the graphics
techniques we've discussed over the course of the semester in lecture
and homeworks. Most students choose to create a short interactive
game, although some students write visualization tools or projects
more directly related to other work (such as research). Although the
constraints of the project are relatively open-ended, the project
itself must contain an intelligent and meaningful application of a
number of skills, described in more detail below, including animation,
lighting, texturing, and shader programming. It is
recommended that you implement the configurable components of your
application (objects in the scene, gameplay parameters, etc.) from
file, so that you can greatly extend the usability of your program by
simply providing multiple configuration files. (For a shooter, this
might include a texture for a skybox, models for the enemies, health,
etc.) It also allows you to more quickly experiment with different
material and lighting properties - don't worry about constantly
recompiling; just change a text file and re-run. This is the
final project! Feel free to use all the tools you've developed so far
in the semester, including (but not limited to): minimaps, HUDs,
menus, picking, billboarding, particle systems, stenciling, cloth,
collision detection, and Bézier curves - which, as you know,
can work very well for smooth, guided animation (objects moving along
a Bézier curve make for hard targets to hit!), Bézier
Patches, and everything else! Unfortunately, in contrast to
the previous two points, there's limited time for the final project;
make a plan, divide work up among your team members early and meet
often, and most importantly, start simple! Get the basics working and
expand from there. This is particularly true with gameplay - even
simple mechanisms can be particularly bug-prone and occupy a lot of
your time. Sadly this is not a game design course (though there is one
next semester!): your priority is incorporating the different
graphical skills you've learned over the course of the semester, and
making something fun and sophisticated is a secondary objective.
All projects must contain a number of required components, to
demonstrate that students have learned and can apply in a practical
context the main techniques that we have discussed in the course. If
you have questions about whether any aspect of your project satisfies
the conditions listed here, please contact the professor. The
required components cover five major aspects that are prevalent in
realtime graphics applications: (1) user interaction, (2) animation,
(3) texturing, (4) lighting, (5) shader programming; plus sound
additionally.
Section A - User Interaction
The final project must contain some non-trivial component of user
interactivity. This should be a non-issue for most projects. The user
must be able to influence the state of the application via keyboard
and/or mouse interaction, and must be able to influence the camera
position (directly or indirectly, should the camera be attached to a
virtual object). Interactivity must be more sophisticated than a
single button press - as a realtime application, the resulting
feedback from user interaction with your program is the primary means
of communication between your virtual world and the user. Your
program's ability to respond to interaction must be sophisticated
enough to showcase and communicate everything that your application
has to offer. Additionally, your program must allow the user
to view the scene from at least two different cameras. These
could be both displayed simultaneously (via viewports and stenciling),
or the user can have the option of switching between them.
Section B - Animation
Your project must include some component of structured animation. This
means that you must use some form of hierarchical modeling (if you are
using the provided Object models, then this will suffice for
modeling). If you have the resources to implement pose-based animation
(or skeletal animation), this will satisfy the animation requirement -
but it must be more sophisticated than the back-and-forth-oscillating
Waddles animation used in class (i.e., must move between poses based
on events in the virtual world, with speeds varying accordingly -- the
Camel fully galloping would be great!).
Section C - Texturing
The final project must use at least two different texture
applications in some meaningful way. This means that filtering
must be enabled if it makes sense, including the use of mipmaps if the
object is expected to be far from the camera. Textures can be
transparent; texture coordinates can be manually specified or part of
an OBJ; particle systems can (and should!) be used to satisfy one of
the texture requirements. A skybox (or any environment color besides
black, for that matter) can give your scene a totally different feel
as well. A skybox would count as a single texture application (even
though it is made up of 6 individual textures). NOTE: in
addition to textures, you should also make strong use of OpenGL
materials -- you can combine a material with a high specularity and a
marble texture to get a more authentic feel, for instance. In
situations where a texture doesn't fit, use non-textured materials -
sometimes they may look best! There are several texture repositories
to browse linked on the Resource
page.
Section D - Lighting
Your application must include a meaningful application of lighting. It
must include at least two lights, and one of them must be
animated or dynamic in some way. (Light position can be tied to
objects in the scene; brightness can be tied to user events such as
objects colliding; color could be tied to the player's performance or
health - maybe a flashing red light slowly becomes brighter as the
user's health diminishes.) Remember that lights exist not only to
communicate shape and depth but also contribute substantially to the
feel of the scene! Experiment with light positions, colors, and
intensities to get a particular look and feel. Generally, you can get
good results with slightly off-white lights of complementary colors -
check out COLOURlovers
for some nifty color palettes, as well as tools to help you choose
sets of complementary colors.
Section E - Shader Programming
Your final project must contain custom shader programs to enhance the
visual quality of your presentation and increase your ability to
communicate information to the user. Your program must contain at
least two shader programs (that is, two pairs of vertex shader +
fragment shader), and these shader programs must be meaningfully
different from the code examples posted on the webpage. In other
words, no copy+paste of the available shader code, and your shader
code must produce meaningfully different results. Your shaders can
provide a large variety of interesting behaviours; by having
player-characters flash a certain color when low on health, or
altering the color of the rendered frame after consuming a powerup, by
slightly randomizing vertex positions to create a glitchy object
appearance, or through more traditional shading models, such as
reading specularity color from a texture (specular mapping). One of
your shader programs must contain a non-trivially different vertex
shader and one of your shader programs must contain a non-trivially
different fragment shader. We have covered many different applications
of vertex and fragment shaders - pick and choose your favorites.
You're encouraged to use some multipass rendering techniques but the
shader programs chosen is up to you.
Section Y - Sound
Your final project may contain sounds using OpenAL/FMOD. These sounds
can be triggered to some event or ambient. There's a lot of fun stuff
that can be done with audio!
Section Z - Easter Eggs
For added fun, add in some sort of hidden easter egg that can be
found in your program. Perhaps it's some secret combination of
movements, or being in a certain location and performing some action,
or whatever you want. Don't make it easy to find (e.g. a bright red X
on the ground you need to move on top of) but perhaps make it easier
than some of the previous achievements have been to find. For good
measure, add to your README.txt how to find your easter egg
if you add one so I can verify it exists. I'll try to find it without
reading the walkthrough.
With peace in the land, Guilds are no longer needed to train and
protect the portal within the city. You've set the Guilds free.
I looked at my kingdom
I was finally there
To sit on my throne as the Prince(ss) of
Bel Air
Olympus.
Part II - Guilds & Proposal
Students must submit a project
proposal via hardcopy in class November 18th, containing a list of team members
and a brief description of the intended project. The description only
needs to be a couple of paragraphs long, and should describe the
project at a high level and anticipated technical challenges, if any. Describe
what shaders you plan to implement, how you'll use lighting, etc. It should be
clear where each requirement will be in your program.
It is primarily intended for the professor to provide feedback and
recommendation, and establish requirements for the final submission.
Part III - Website
Update the webpage that you submitted
with A7 to include an entry for this assignment. As usual, include a
screenshot (or two) and a brief description of the program, intended to
showcase what your program does to people who are not familiar with the
assignment.
Part IV - Presentation
During the final exam slot on December 12, each Guild will present
their Kingdom. They will have five minutes to showcase their work and
demonstrate all the features available. There will then be two minutes
for other students to ask questions about your implementation. During
this time, the other Guilds will be critiquing your presentation (by
filling out a scoresheet) and at the end everyone will vote for their
favorite Guild that should be rulers of Olympus. As with Guild
Wars, each team will use their own laptop to present from. Be sure to
have the necessary connectors to hook up to the projector in the room. If needed, please
let the instructor know if you'll need to use his laptop to present from.
Documentation & Submission
With this and all future assignments, you are expected to appropriately
document your code. This includes writing comments in your source code
- remember that your comments should explain what a piece of code is
supposed to do and why; don't just re-write what the code says in plain
English. Comments serve the dual purpose of explaining your code to
someone unfamiliar with it and assisting in debugging. If you know what
a piece of code is supposed to be doing, you can figure out where it's
going awry more easily. Proper documentation also means
including a
README.txt
file with your submission. In your submission folder, always include a
file called
README.txt
that lists:
- Your Name / email
- Guild Name / Guild Members
- Assignment Number / Project Title
- A brief, high level description of what the program is / does
- A usage section, explaining how to run the program, which keys
perform which actions, etc.
- Instructions on compiling your code
- Notes about bugs, implementation details, etc. if necessary
- NEW: A description of the file format that your program
reads as input
- NEW: A rough distribution of responsibilities /
contributions of each student
- How long did this assignment take you?
- How much did the lab help you for this assignment? 1-10 (1 - did
not help at all, 10 - this was exactly the same as the lab)
- How fun was this assignment? 1-10 (1 - discontinue this
assignment, 10 - I wish I had more time to make it even better)
Grading Rubric
Your submission will be graded according to the following rubric.
10% |
User interactivity is well-implemented and
meaningful; allows the user to explore the various aspects of the
program. |
15% |
Project contains models which are animated
with some form of hierarchical animation. |
10% |
Project contains at least two different
texture applications, used as described above. |
10% |
Project contains at least two different
lights and materials, used as described above. |
50% |
Project contains at least two different
shaders, used as described above. |
2.5% |
Proposal submitted on time. |
2.5% |
Submission includes source code, Makefile,
and README.txt. Source code is well documented. Webpage
named <afsid>.html submitted and updated with screenshot from
latest assignment. Submission compiles and executes in the lab
machine environment.
|
Experience Gained & Available Achievements
Assignments +150 XP |
Web +150 XP |
School's Out
|
Submission
Please update your Makefile so it produces an executable with
the name keyToTheKingdom. When you are completed with the
Final Project, zip together your source code, textures, models,
shaders, anything needed to run your program, Makefile,
README.txt
, and www/ folder. Name the zip file,
GuildName_FP.zip
. Upload this file to Blackboard under KeyToTheKingdodm.
Everyone is expected to submit a
README.txt
file, although the files may be the same. Each team member must also
update their Hero's webpage. In your
README.txt
, be sure to specify who submitted the full source code (you all may do
so, but make sure at least one of you does).
This assignment is due
by Sunday, December 11, 2016 by 11:59pm.
|