COS 426 - Computer Graphics
Final Project: 3D Video Game
Due Tuesday, May 10, 5:00 PM
Live demos will be scheduled Tuesday, May 10 and possibly other dates
For your final project, you will implement a 3D video game using OpenGL.
You are free to design and implement any sort of game you like, as long as
it incorporates the required functionality described below. For purposes
of this project, we consider a 3D video game to be an interactive 3D
computer graphics application that has a challenging goal, is fun to play,
and incorporates some concept of scoring or winning and losing. It is not
required that your game idea be original, but originality will be rewarded
with extra credit.
You are required to form teams of 3 or 4 people, and partition the work
among team members. 2-person groups may be allowed with permission of the
course instructor. The required workload is designed to be slightly
sublinear in the number of people in the group.
Within the overall framework of your video game, you are required to
include the following functionality:
- 3D perspective viewing and objects. Your game environment must be
a scene consisting primarily of 3D elements, as opposed to only "flat," 2D
sprite-based graphics. Your game should provide perspective views of your
3D scene where at least sometimes the viewpoint changes smoothly under some
combination of user and program control. To produce these views, you
should implement transformation, clipping, and hidden-surface removal of
your 3D scene using the OpenGL pipeline.
- Lighting and smooth shading. Your game must contain at least some
objects that are "lit" using OpenGL's lighting model. For these objects,
you'll need to define normal vectors and materials, as well as create one
or more light sources.
- User input. Your game must allow players to interact with the game
via keyboard or mouse controls. Alternatively, you can use more elaborate
user interface devices (see below).
- Computer control over some elements of the scene.
This may include a physics-based dynamical simulation or particle system,
some variant of "monster AI" to control computer characters, or
simply some elements in the scene that respond to the user's actions.
In addition to the basic requirements, you are required to implement at
least 2N of the advanced features listed below, where N is the size of
your team. Of course, you are encouraged to implement as many of these
techniques as you can, depending on the requirements of your particular
game engine, as well as using any other ideas you read about or invent on
your own. Extra effort will be rewarded with extra credit.
- Texture mapping. Implement texture mapping for at least
one of the 3D objects in your video game. This will require you to load
the texture images, figure out some way of computing or specifying texture
coordinates, and enabling texturing within OpenGL.
- Multiple views. Implement a second view of the game world,
in addition to the "main" view. For example, if the main view is first-person,
implement a global overview or an over-the-shoulder view, to be displayed
on the screen at the same time as the same view.
- On-screen control panel. Many 3D video games reserve part of the display
area for an on-screen control panel, which may include text or 2D graphical
elements for user controls, scoreboards, etc. Flight simulator games often use
2D graphical overlays on the 3D world for "Heads Up Displays (HUDs)." You
can implement a control panel for your game using a variety of techniques
in OpenGL, such as orthographic projection and the stencil buffer. Text
primitives are not explicitly supported with OpenGL, but GLUT and the
window system extensions (GLX, WGL, etc.) both provide commands to help render
- View frustum culling. In video games with complex 3D environments, it is
necessary to limit the number of 3D primitives drawn each frame in order to
maintain interactive rendering rates. One way to do this is to avoid
drawing any 3D objects which are outside of the viewing frustum of the camera.
You can pre-compute rough bounding volumes for hierarchical objects or
parts of your 3D world, and then test each bounding volume to verify that some
part of it intersects the view frustum before drawing its contained objects
- Level of detail control. Another way to limit the number of 3D primitives
drawn each frame is to implement level of detail (LOD) control in your
game. One simple method of LOD control involves creating multiple versions
of some of your 3D objects, varying in geometric complexity (such as 100,
1000, and 10000 polygons). Then, before drawing the objects each frame, you
can pick the most appropriate version of the object to render, depending on
such metrics as the distance of the object from the viewer, the complexity
of the current scene, or a user-selectable detail level.
- Occlusion culling. Yet another way to maintain good game performance with
complex environments is by performing occlusion culling. Similar to view
frustum culling, this technique involves using a conservative computation
to avoid drawing any parts of the 3D scene which won't be seen by the
viewer because they are hidden behind other objects. For static
environments such as buildings, you might pre-compute which regions of
space (such as rooms) are impossible to see from other regions (due to
occluding walls, for example). (Don't confuse occlusion culling with simple
hidden-surface removal, which is required for your video game.)
- Procedural and physically-based modeling. In addition to using
scanned or hand-modeled objects to populate the 3D worlds, some video games
use procedurally computed models, such as fractally-generated mountainous
terrains, L-grammars for generating models of plants, or particle systems
for fire, smoke, and clouds.
- Collision detection. Video games often contain moving objects which
trigger events when they collide, such as projectiles shot at a target.
Collision detection can also be used to prevent the user from passing
through walls or other objects. You can implement collision detection in a
variety of ways; the simplest might involve comparing bounding volumes of
objects to decide if they intersect or not.
- Simulated dynamics. Your video game implementation might include modeling
dynamic behaviors and physics for objects in the 3D world. For example, the
wheels of a vehicle might react realistically as they move over rough terrain,
or a door might swing open differently depending on the force exerted by
- Multipass rendering effects. OpenGL makes it possible to easily
implement a wide variety of realistic rendering effects. Many of these
effects can be achieved by drawing the scene multiple times for each frame,
varying one or more parameters each pass through the scene. Examples of
such effects include soft shadows, full scene antialiasing, motion blur,
depth of field, bump-mapping, reflections, refractions, and compositing.
- Parametric curved surfaces. The GLU (OpenGL Utility library)
contains routines for implementing curved surfaces, such as splines and
NURBS. Use these facilities to include smoothly curved surfaces in your
- Skinned characters. Implement linear-blend skinning for
some characters in your scene. You will need to augment the file formats
to include information about blending parameters.
- Vertex or fragment shaders. Use GLSL to implement custom
shaders to be evaluated at vertices or fragments (pixels). These might
implement procedural shading or geometry effects, or be used to implement
more advanced rendering techniques.
- Advanced image-based techniques. In an effort to increase graphical
realism and maintain fast performance, many video games mix traditional 3D
graphics rendering with 2D image-based graphics. Although 2D texture
mapping is an example of a basic image-based technique, more advanced
techniques such as environment mapping, billboarding, and projective
textures are possible. Other ideas for image-based techniques include
precomputing multiple 2D images ("sprites") of a object from different
orientations, and then choosing the most appropriate sprite to warp and render
in the 3D scene.
- Input devices beyond keyboard and mouse. Be creative: try
using Kinect, touchscreens, Wii-motes, etc. You will need to
supply the required devices for your live demo.
- Sound. Adding appropriate audio effects to your game can provide a
more compelling experience for the player. The details of sound effect creation
and implementation of audio playback in your game engine will depend on
your hardware configuration, but there are some cross-platform APIs such as
- Networked multi-player capability. Networked multi-player video games
allow more than one player to play at once, either collaboratively or in
competition. If you add multi-player capability to your video game, you'll
need to deal with issues such as network latency by using predictive
- Game level editor. Some video games are accompanied with
supplementary computer graphics applications which allow users to design their
own game levels (scenes). If you develop your own custom application to
construct levels while writing your game, you might consider packaging it
as a separate utility program for end-users to enjoy as well!
Live Demos and Contest
All teams must provide a live demo of their games on May 10. (We may
also schedule additional demo sessions if you can't make it that day.)
All games are automatically entered in the COS 426 Video Game Contest,
and fabulous prizes will be awarded. Everyone is encouraged to see
all the games, and cheer on your classmates.
Because all video games will be different, we do not provide sample code
for you this time. Feel free to use any of the code you have been given,
or have written, this semester. In particular, programs such as
meshview might provide a good starting point for displaying
content using OpenGL.
Rules for using external code, data, etc.
To generate compelling games, you are encouraged to use 3D models,
textures, and sample code that you may find in references and on the
web, subject to the following restrictions:
- You may use any artwork (3D meshes, textures, sounds) that you obtain
legally. Please note the source of any artwork you use in your writeup.
- You may use code distributed for any COS 426 assignment, or as shown
in any COS 426 lecture or precept.
- You may use, with attribution, any code written by any team member
for COS 426 or any other class.
- You may look at any sample code you find, but you must clearly
acknowledge the exact source (book chapter / page number, URL, etc.)
of any code you consulted, and state what part of your final code was
based on external work. In evaluating how much credit is to be awarded
for required features, we will take into account only the delta between
the external sample code and your final code.
- You may not use a ready-built game engine: the whole point of
this assignment is to have you code from the ground up.
Hints and Resources
- Most systems these days should be capable of running OpenGL programs,
but some computers have faster graphics cards than others. Feel free to
develop on any machine to which you have access (such as the machines in
the basement of Friend), but for the live demo session you will have
to either provide a machine or make arrangements well ahead of time with
the course staff.
- In the course of designing and implementing your video game, keep in mind
that COS 426 is a computer graphics course. Focus your efforts on the
computer graphics techniques underlying the game; don't spend the majority
of your time on game design or object modeling if the graphics engine will
suffer as a result!
- Most successful video games include richly detailed 3D models,
textures, sounds, and other content for representing the game world and
characters. You have several options available in creating the 3D models
for your video game:
- Simple models can be sketched on graph paper, and the coordinates
manually typed into an .off file.
- Models can be procedurally generated, as mentioned above.
- You can use a 3D modeling package such as Blender and export the model in .off
format. (Be aware that the .off files created by Blender may appear
"inside out": you may need to reverse the order of vertex indices in
- The GLUT library provides functions for drawing a few simple
3D shapes (sphere, cube, teapot, etc.)
- You can find a wide variety of 3D models available on the
Web (see the pointers on the assignment Web page).
These may need to be converted to a format your program can
- This project is purposefully designed to be more open-ended than the first
four assignments of the course. You will be expected to do a considerable
amount of learning on your own, particularly in gaining experience with
programming in OpenGL. The following resources may be useful:
- The Official OpenGL site
contains documentation, coding resources, and FAQs.
- The Khronos Group site
also contains OpenGL specifications, etc.
- nehe.gamedev.net contains
a variety of OpenGL tutorials and articles.
- Nate Robins's
OpenGL tutorial programs demonstrate basic OpenGL functionality by
allow the user to interactively modify parameters and see the effect
on the 3D scene.
- Ultimate 3D Links is a great
starting point for programs and data for 3D game content. In particular,
check out their links to
shareware 3D modeling programs as well as their numerous links to
collections of thousands of free 3D models and textures (follow the
index links "3D Objects>Free Objects" and "Textures>Free" on the left
side of their Web page).
Please submit one .zip file per group containing your
code, writeup.html, and all artwork used by your game. The writeup
- The names of all group members.
- The complete list of features implemented.
- A few screenshots from your game, both illustrating gameplay and
demonstrating the features you implemented.
In addition, each member of the group must (separately and
privately) submit a file named [your NetID]_contributions.txt with
a concise list of the features on which he/she worked and the contributions
made to the overall effort.
The Dropbox link to submit the final writeup is
Please note that, per university policy, the deadline to submit your final
project writeups is 5:00 PM on May 10, 2011 (Dean's date). Writeups that
are a bit (e.g. a few hours) late will not be penalized, but we
cannot accept "late days" or grant extensions to this deadline.
smr at princeton edu