COS 426 - Computer Graphics

Spring 2011

Final Project: 3D Video Game

Overview

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.

Required Functionality

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 text strings.
• 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.
• 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 the player.
• 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 scene.
• 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 OpenAL.
• 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 techniques.
• 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.

Getting Started

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 each face.)
  • 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 use.
• 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).

Submitting

Please submit one .zip file per group containing your code, writeup.html, and all artwork used by your game. The writeup must contain:

• 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 here.

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.