Programming assignment #3 - 3D Video Game
CS 248 - Introduction to Computer Graphics
Autumn Quarter, 2000
Game proposals due Tuesday, November 14 by 5:00pm
First demos on Monday, November 20
Final demos on Wednesday, December 6
Writeups due on Friday, December 8 by 5:00pm
Your assignment is to write 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. If you have any
questions about whether your idea meets the criteria for a 3D video game,
please ask the course professor or a TA. Your game proposal (due November 14),
and our feedback to you afterwards, should help you in developing your game
You are permitted (and encouraged) to form teams of 2-3 people and partition
the work among the team members. The work expected from each team will be
proportional to the size of the team. You can use the class newsgroup
su.class.cs248 to find prospective team members.
Each team should submit a single game proposal, jointly authored by all team
members. You may change the composition of your team at any time prior to
November 29 (one week before final demos). However, changes after the first
demos (on November 21) are strongly discouraged.
Within the overall framework of your video game, you are required to include
the following functionality:
- 3D 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.
- User input. Your game must allow players to interact with
the game via keyboard or mouse controls. Alternatively, you can use joysticks
or more elaborate user interface devices (provided that you can supply the
required devices for your program demonstration sessions; see below).
- 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. See Chapter 5 of the
OpenGL Programming Guide for details on implementing lighting and
- Texture mapping.
You must implement texture mapping for at least one of the 3D objects in your
video game. Chapter 9 of the OpenGL Programming Guide describes how
to implement a variety of texturing techniques. If you want, you can use your
paint program from Assignment #1 to create 2D texture maps in the .PPM
image format, and borrow part of the xsupport source code for loading
image files in this format. Alternatively, source code is provided in the
class directory to load SGI .rgb format images into a form readily
usable as OpenGL texture maps.
In addition to these basic requirements, your game should incorporate some of
the more advanced computer graphics techniques listed below, depending on the
size of your project team. In particular, you are required to implement at
least 2*N of these additional techniques, where N is the
number of people on your team (i.e. groups of three people need to implement
six techniques, individuals working alone are required to implement only two,
etc.). 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.
- 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
- Hierarchical scene graph. Many 3D graphics applications maintain
their constituent objects and sub-objects in a tree-like data structure called
a hierarchical scene graph. The scene graph provides a logical
organization for the objects in the 3D world, and allows for efficient
constructs and operations such as instancing, hierarchical transforms, nested
bounding volumes, and traversals of the scene graph for rendering or collision
detection. Object hierarchies are discussed in Chapter 7 of the textbook
and will be covered in Tomas Möller's lecture in class.
- 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 each frame. More details on view frustum culling
are in Section 7.1.2 of Möller and Haines's book, Real-Time
- 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
10, 100, and 1000 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. Levels of detail
are discussed in section 7.3 of Real-Time Rendering.
- 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). More information on occlusion culling is in sections
7.1.3 and 7.1.5 of Real-Time Rendering. (Don't confuse occlusion
culling with simple hidden-surface removal, which is required for your video
- 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. Chapter 20 of the textbook describes examples of
procedural modeling, including fractally-generated mountainous terrains and
L-grammars for generating models of plants. Procedurally generated textures
may be used to simulate effects such as 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. Chapter 11 of Real-Time Rendering
describes a number of collision detection techniques.
- 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 ball might bounce differently depending on its velocity,
elasticity, and the characteristics of the surfaces it hits. Realistically
animated characters in 3D graphics applications are sometimes controlled
via simulated dynamics.
- Motion capture animation. Motion capture data is
used with many modern 3D video games to allow characters to
move realistically. Pointers to some motion capture data files
and implementation ideas are on the assignment resource Web page.
- Advanced rendering effects. OpenGL makes it possible to
easily implement a wide variety of realistic rendering effects. Some
of these effects can be achieved by drawing the scene multiple times
for each frame and varying one or more parameters each pass through the
scene; these techniques are called "multi-pass rendering." Other
techniques combine traditional 3D graphics rendering with 2D image-based
graphics. Advanced rendering effects you can add to your video game
include soft shadows, reflections, motion blur, depth of field,
bump mapping, environment mapping, billboarding, and projective texturing.
See chapter 6 of Real-Time Rendering as well as the pointers on the
assignment Web page for examples and information on implementing advanced
multi-pass and image-based rendering techniques.
- Parametric curved surfaces. OpenGL can directly display only
simple convex polygons; however, you might create a 3D model for your video
game which includes smoothly curved surfaces represented mathematically by a
small number of parameters. Chapter 11 of the textbook and Chapter 12 of the
OpenGL Programming Guide describe how to represent and manage the
display of smooth surfaces such as NURBS. Be wary about performance if you use
NURBS in OpenGL; use them judiciously.
- 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; some pointers to relevant documentation and
sample sound effects are included on the assignment Web page.
- AI. Some video games include computer-controlled agents that
require a significant degree of artificial intelligence. Many of the
techniques taught in a basic AI course are applicable to video game
development, and some links to more detailed information on game AI are
included on the course Web page for the assignment. If you have any doubts
about whether a technique you are using qualifies as "AI" for this assignment,
- Networked multi-player capability. Networked multi-player video
games allow more than one player to play at once, either collaboratively or in
competition, using computer networks such as the Internet. If you add
multi-player capability to your video game, you'll need to deal with issues
such as network latency by using predictive techniques. Some pointers to basic
information on implementing networking in games will be provided on the
assignment Web page.
- 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!
A few hints
- This project is purposefully designed to be more open-ended than
the first two 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. Please take advantage of the opportunity to
consult the course professor and TAs with questions concerning development of
your particular video game. If there are computer graphics techniques not
covered in the course that you would like to implement, we will usually be able
to point you to an appropriate source of information. In order to assist and
inspire you, a web page is available at the URL:
This page includes pointers to OpenGL tutorials, information on game
development, useful utility programs, and sources for 3D models and other game
content. Additional examples of OpenGL code from the programming guide and
OpenGL and GLUT distributions are available in the class directory in
/usr/class/cs248/assignment3. Of course, you are responsible for
understanding and implementing your own video game code; copying of source code
from others is prohibited.
- Interactive 3D graphics programs such as video games
place special demands on computer hardware. If your 3D world is particularly
large or complex, or if you use certain OpenGL rendering features (such as
texture mapping), you will probably need special graphics hardware in order to
get real-time performance. Note that the SGI machines and many of the Sun
systems in Sweet Hall do not implement texture mapping in graphics hardware, so
games making intensive use of texturing will suffer performance limitations on
these systems. Modern PC systems with fast 3D graphics accelerator cards will
usually yield better texturing performance than the SGI machines in Sweet Hall.
The Firebird systems are equipped with NVIDIA Quadro graphics cards which
should deliver excellent 3D graphics performance. If you develop your game on
multiple platforms, it will probably be useful to add options to disable
expensive features (such as texturing) on request. The performance of your
video game is important, so do not implement too many expensive rendering
features if the gameplay is negatively impacted! There are some pointers on
the assignment Web page to sources of information on maximizing OpenGL
- 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 your source code.
- Models can be procedurally generated, as mentioned above.
- You can use a 3D modeling package and export the model in
a format your program can read.
The assignment Web page will contain pointers to several freely
available modeling packages.
- The GLUT library provides functions for drawing simple
3D shapes (sphere, cube, 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 use; we will provide some
example source code for loading models.
- You are free to develop your video game on any computer platform that
supports OpenGL, provided that you will be able to demonstrate your program at
the two required demonstration periods at Sweet Hall. If your program cannot
run on the Sweet Hall SGI (raptor) or Linux (firebird) machines, you will be
responsible for bringing a system on which to run your video game. Versions of
OpenGL for most common computing platforms are available for download at sites
pointed at from the assignment Web page.
OpenGL is window system independent,
so an additional toolkit is necessary to provide the necessary windowing and
input event management; for this we recommend using the GLUT package. GLUT is
used for all the examples in recent editions of the OpenGL Programming
Guide, and is available for most all common computing platforms. A simple
example program and Makefile using OpenGL and GLUT on the Sweet Hall SGI and
firebird machines is available in
/usr/class/cs248/assignment3/example. GLUT offers a very limited set
of user interface widgets (little more than menus). If you require more
extensive user interface functionality, we recommend trying the MUI, PUI, or
GLUI toolkits; they are easy to use, and are written entirely on top of GLUT
and OpenGL. Documentation is available on the Web (see the assignment Web page
for pointers). You are free to use other user interface toolkits of your
- In the course of designing and implementing your video game,
keep in mind that CS248 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! Finally, don't make your 3D world or game engine so
complicated that interactivity suffers. Your game must be playable!
Video game submission requirements
The game proposal.
Your first milestone is a proposal, due by 5:00pm on Tuesday, November 14.
Your proposal can be brief - 1 page is plenty. Be sure to list all team
members. The proposal should clearly state the premise of your game, describe
the 3D world you plan to build for it, outline the gameplay, and enumerate the
2*N techniques you plan to implement. If you envision facing any
special technical challenges (like predicting collisions between a basketball
and a hoop), list them. If you envision implementing any special bells and
whistles (like the ability to play against 5,000 networked opponents
simultaneously), list those too.
Submit your proposal by emailing it to
email@example.com. Submitting a proposal is required,
and late submissions will be penalized, but your proposal will not be graded.
Neither will you be held to either the list of advanced graphics techniques you
enumerate or to the composition of your team. The purpose of this proposal is
to motivate you to begin working on the project, and to give us a chance to
guide you. We will read and respond (by email) to every proposal. Hopefully,
most of these responses will be of the form, "Cool game idea! Full speed
ahead!". However, if we see you headed towards the shoals, we'll let you know.
On Monday, November 20 you will demonstrate your partially complete video game
to a member of the CS248 course staff.
To show reasonable progress,
your 3D world should be largely in place, although perhaps lacking in detail or
performance, your "gameplay" should be basically working, and at least some of
the required graphics functionality (3D viewing, user input, lighting, and
texture mapping) should be implemented. The 2*N "advanced" techniques
need not be in place, except that depending on your game, you might need to
have already implemented some of them in order to demonstrate your gameplay.
At the demo, we will give you feedback on your game, and we will discuss with
you your plans for finishing it.
Signups for these demos will be handled electronically, as in project #1. You
can demo on any platform you like, even a laptop. However, all demos must be
given in one of the two Sweet Hall basement graphics labs. There is no need to
freeze your code before the demos. All team members must be present at the
demo. Late demos will be permitted, but will be penalized in the usual way.
No writeup or submission of source code or other files is required following
these demos. In addition to giving you verbal feedback at the demo, we will
also grade you. Since you are not submitting code, these grades will based
only on what we see during the demo. However, these grades will be simple:
"check", "check-minus", "check-plus", depending on the quality of your
Final demos and writeups.
Your complete video game will be demonstrated on Wednesday, December 6.
Signups will be handled electronically, as usual. No code freezing is
required. All team members must be present at the demo. During the demo, make
sure you tell us what features you have implemented. Functionality you don't
show us or that doesn't work will not be given credit.
Final writeups and code and content submission is due on Friday, December 8 at
5:00pm. To submit your video game files, simply change the current directory
to your project #3 directory and run the submit script, as you did for
the first two assignments. Only one submission per team is necessary. Your
submission should include your entire game - source, executable, makefiles,
models, textures, etc. It should also include a README file which lists your
team members, describes how to build and run your video game, and explains the
2*N (or more!) advanced computer graphics techniques you implemented.
Also, your README file should include references to any external sources you
referred to for inspiration, and it should indicate how your 3D models and
other game content were obtained. Remember - no late demonstrations or writeup
submissions will be accepted.
Separately from your joint team submission, and privately, each team member
should send an email message to firstname.lastname@example.org by
5:00pm on December 8 specifying who worked on which features of your game, and
what percentage of the total work each team member did.
The video game competition.
After the demos are finished, probably around 4:00pm (on December 6), a jury of
computer graphics experts from industry and academia will join the CS 248
teaching staff to to evaluate your programs as part of a video game
competition. Any team may participate in the competition; however,
participation is not required. There will be one grand prize - an
all-expenses-paid trip to Siggraph 2001
in Los Angeles next summer, one second-place prize -
dinner for two at Il Fornaio
in Palo Alto and a choice of any PC video game offered by Electronic Arts, and
some number of runner-up prizes - probably PC video games offered by Electronic
Arts. If the grand prize is won by a team, it must be split among the team
members. All other prizes will be duplicated as necessary to cover the team.
The competition will be accompanied by an amazing party.
Good luck, and have fun!
Copyright © 2000 Marc Levoy
November 7, 2000 04:30:57 AM