EECE 478: Game Project
Game Proposal: September 29th
Demo Day: December 2nd?
Reports Due: December 2nd?
Project:
Your project will be to design and develop a 3D computer game from scratch using
OpenGL. It will need to be interactive, three-dimensional, have some
sort of challenging goal or goals, and be fun to play. Originality is
encouraged, but not required.
The goal of this project is to give you a practical experience to
ground your understanding of computer graphics. To that end, you are
expected to engage in substantial, project-directed research about
techniques and tools that will allow you to create a full, end-to-end
graphical application that depends on a realtime 3D graphical engine.
By the end of the project you should be able to confidently create 3D
user interfaces to many different non-game computer applications and be
able to integrate 3D interaction into those interfaces.
Requirements:
The game will need to depend substantially on the three-dimensional
structure of the environment. This is not to say that there will need
to be a 3D world as such, just
that the three-dimensional nature of the environment must have direct consequences on
game play. In addition, the following must
be integrated into the graphics engine and demonstrated in the game
play:
- 3D viewing and objects, including a moving camera,
- lighting and material variations, and
- texture mapping.
In order to develop your game, you can use any resources that you can
find on the Web or through other sources for any aspect of the source
code. You may not use an existing game as a project framework and
modify it for your own purposes. If you use a scene graph library then
you must clearly identify the rendering capabilities of the library and
what aspects of the game rendering you implemented yourself. In order
to receive credit for an advanced feature, you must demonstrate that it
was not available
in the library you used. In general, the larger your team, the more
advanced funtionality you will need to demonstrate to impress the
judges.
You will be required to
document the sources and licenses for any software or models you
incorporate into your game and demonstrate that they are compatible
with the terms of use you plan to apply to your own source code.
You may develop your game on either Windows or Linux, as long as you
use OpenGL for your rendering engine. For the demos we will use host
machines equivalent to those in MCLD 303 in terms of processor power,
memory and graphics hardware. You may provide any optional input device
(e.g. game controller) that you are able to easily interface to the
demo machines in MCLD 303.
Advanced Features
In addition to the basic functionality described above, you will be
required to implement some of the advanced techniques
described below:
- Portability: Games
that work well on multiple platforms have a much greater potential
audience. If your game can run under Windows, Linux and/or Mac
environments, you have demonstrated an ability to write portable code.
Adaptability to different capabilities of a graphics pipeline is a
similar task and equally useful. Using a portable interactive
application development environment such as the SDL greatly enhances the ability to develop portable applications.
- Scripting Language: One
classic technique for accelerating the development of a complex
application is to create a high-performance core and then create all
(or most) higher-level functionality using a scripting language that
handles application and interface events, actions and logic. This
not only increases development efficiency but allows an application to
be easily extensible with multiple levels and/or user-extensible
features.
- View frustum culling: One of the
most fundamental tools for optimizing the speed of a graphics pipeline
is to ensure that no primitives are sent through the pipeline that will
not appear on screen (also known as reducing the polygon count). A simple method for culling primitives from the scene
is to ensure that primitives that do not intersect the view frustum are
not rendered.
- Occlusion culling: A more complicated (but
potentially more powerful) means of reducing the polygon count is to
ensure that objects that are hidden "behind" other opaque objects
(known as occlusion) are not
passed to the pipeline. Two popular techniques for occlusion culling
are binary space-partition (BSP) trees and portal systems.
- Hierarchical scene graph:
One means of reducing the amount of processing necessary to compute
both view frustum culling and occlusion culling is to construct a scene
graph that is organized as a tree, such that the bounding boxes of the
tree nodes include the
bounding boxes of all of the nodes and leaves below it in the tree.
- Transparent or translucent
objects: It is fairly simple to render collections of opaque
objects using the z-buffer algorithm, but it can be difficult to
introduce translucent objects into these scenes as they must be
rendered last and often in specific orders using alpha-blending
techniques.
- Level of detail: The
further away objects are from the view plane, the smaller they will
appear. It is often possible to reduce the rendering detail of an
object that is far away without significantly affecting the pixels on
the screen. This can be accomplished by having simpler models and/or
different textures and materials depending on distance from the camera.
It is also possible to use variable level of detail of some objects in
order to keep up frame rates when scene complexity becomes too great.
- Procedural modeling: In
addition to basic geometric modeling, it is possible to create certain
objects and textures with computational techniques. Examples are
fractal terrain, L-grammars for plants, or fractal smoke and fire.
- Physical simulation: The
numerical simulation of physical laws allows one to generate realistic
dynamics of simulated objects. Projectiles move along paths governed by
gravity and friction. Cars wheels lose traction and skid when lateral
forces exceed wheel-surface friction. Forces cause motion based on
kinematic equations, etc.
- Key frame animation: Most
computer animation in games and motion pictures is managed by
establishing fixed positions of objects (called key frames) and then smoothly
interpolating positions over fixed schedules. Very complicated
sequences of patterned motions can easily be built up by combining key
frame sequences and schedules.
- Motion capture animation:
Key frame sequences can be derived from specialized techniques that
carefully measure the body positions of actors or other performers
(even animals). Examples of motion capture data can be found on the net.
- Collision detection: When
you have a number of objects moving through a scene, you will need to
deal with potential collisions between objects and static scene
elements and even between two moving objects. There are basic
techniques for determining if and when objects collide, and techniques
for optimizing these calculations using hierarchical scene graphs.
- Shadows: Some simple
shadowing techniques can be acheived quite simply. Others require
multi-pass rendering. Either way, they add greatly to the sense of
realism of 3D scenes.
- Multi-pass rendering:
Certain advanced visual effects can be achieved by taking the output of
the rendering pipeline and feeding it back into texture maps. Other
effects can be accomplished by rendering the same scene multiple times
with slightly different parameters and blending the outputs. These
techniques are collectively referred to as multi-pass rendering and can
produce scene artifacts like reflection, soft shadows, motion blur,
bump mapping, environment mapping, billboarding and projective
texturing. Multi-pass techniques are expensive though, and should not
be introduced if they interfere with game play.
- Sound effects: It is
pretty hard to make a compelling game without good sound. You can even
get pretty good spatial localization of sound with manipulation of
stereo volume levels, and this can provide directional hints to aid
game play.
- AI: Games with
computer-controlled characters (or vehicles) are much more compelling
and competitive if the characters seem to be adaptive and "smart".
There are many ways in which this "articial intelligence" can be
injected into a game. It is especially compelling if multiple computer
characters coordinate their activities to form teams or squads.
- Networked gaming:
Simulated worlds or competitive games may be more compelling if you can
play against other players. If each player has a similar console and
network connection this can be done over trhe network. For simulated
worlds it may even be possible to support many users with a
client-server configuration.
Resources
The game project resources page contains
pointers to a wide variety of sources of information about designing
and developing games, software and models that can be used to build
games, and stories from the game development trenches.
Project Outline
The first part of the game development process is to decide a type of
game, a style of play, and the general parameters of game play. We are
requesting a one page summary of your plans, including some indication
of which of the above advanced techniques you plan to incorporate into
your game. This outline is due Sep. 29th at 5pm by email to
leei@ece.ubc.ca. It will not be marked, but will simply serve as a
guide to allow us to provide you with feedback on the difficulties you
may face and specific resources you may find useful.
Evaluation
The project will be graded based on three
components, the game demo
(50%), a group project report (25%), and the individual contributions
to a web-based project development log (25%). Together they will
constitute 50% of your
course grade (in essence, this is your final exam and term paper). The
demo will be judged by Dr. Iverson, the course TAs, and
(hopefully) representatives from industry. The parameters for the demo
day will be determined later, but expect to have no more than 5 minutes
for a specific, scripted demo. The judges will play with the games for
some time afterwards.
The project reports will be general engineering reports. You will
definitely benefit by keeping a detailed, individual project notebook
as well as a group notebook. They will not only help in the ongoing
development of the game, but will be invaluable in preparting your
final reports.