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.