Due Dates: Proposal due about Midterms. Project due the last day of classes. (See Schedule for details)
Ideas for 2008
I am interested in making a simulation of sunset on a hemispherical shaped display. If that sounds fun to you, talk to Dr. Jones. I am also interested in simulations of black holes colliding, galaxies colliding and star lifecycles. If those or similar problems sound interesting to you, let's talk as well. These ideas may lead into a longer term arrangement with my lab and other things which are developing in the CS Department.
Demos
Turn in your working executable final project via email to moc.liamg|ffats554sc#moc.liamg|ffats554sc by Midnight on Monday June 16. You will then need to prepare a demo of your project for the final exam period which is Wednesday June 18 from 9 am to 11 am in our classroom. Your demo needs to run somewhere in the TMCB. The project you demo and the project you turn in should be substantially similar. Meaning that you can tweak your project for the demo for no more than say 2 hours after you turn in your final project snapshot on Monday June 16.
If you tweak your project after the deadline for the demo, you need to let me konw what you changed and how long you spent. The amount of time should be less than 2 hours. This should be emailed to moc.liamg|ffats554sc#moc.liamg|ffats554sc
The demo should include the following:
1. A demonstration of how your game works.
2. Each person in your group should mention…
a. one thing they learned about OpenGL (or DirectX if you used that) programming while doing the project.
b. one thing they learned about software engineering while doing the project.
c. one thing they'd do differently if they were going to rewrite the project from scratch
The final exam period will also include a brief written Final Exam.
Overview
For your semester project, you will write a computer game using OpenGL. You can work either by yourself, or in teams of up to 4 people. The projects will also be graded based on the number of students working on the project. Thus, a project built by 4 people should be significantly better/more complex than a project done by a single student.
The game must include the features listed below. It will probably not be as elaborate as computer games currently on the market, but it needs to be fun and incorporate various aspects of computer graphics. In addition to the required elements, you are welcome to add additional features. Examples of features you may wish to consider are listed below.
I really want this to be a fun experience. Come up with ideas early in the semester of the project you wish to implement, then start on it early.
Project Proposal
Your project proposal needs to be turned in to me by the due date which is currently May 21 (see Schedule for updates). The proposal needs to include the following:
1. A list of the students who will be working on the project (if it is a group project).
2. A paragraph summarizing the overall project.
3. A discussion of the user interface.
4. Details of the project – describe here what the game will do, how you will do it, etc.
The purpose of this is to get you thinking about what you want to do and about how you will do it. You should get started on your project ASAP, since there are always last minute gotchas that you need to plan for. Think about the project enough so that you can describe design strategies, etc. in this proposal.
Dr. Jones' proposal is now available for reference. It may give you a good idea of what to include and write about.
Required Functionality
You will probably not have time in the semester to put everything into the game that you would like. Start with the basics, and get the game working, then add the bells and whistles as time permits. The following components are required of your project:
* 3D Objects — Your game must be made of 3D objects. Simply placing 2D objects into a flat environment is not sufficient.
* 3D Perspective Viewing — Your game will need to allow for viewing in 3D, and you must view in perspective. In addition, you must be able to change views – either user controlled or program controlled, as you play the game.
* Interactivity — Your game must include some element of interactivity in it. The user must be able to interact with the program via the keyboard or mouse (or fancier input devices, if you want).
* Lighting and Shading — You must include light sources (one or more) in your environment, and you must smoothly shade the objects in the scene.
Video games that are on the market today are comprised of very rich environments, characters, and objects. You will need to find or create objects that provide this richness for your game. You can either create your own objects (using GLUT, drawing the object and entering its coordinates), or you can use objects off of the web. The class web page contains a link to several objects (see below…). You are also welcome to use any other objects you can find.
Optional Features
There are many other graphics capabilities that you may want to consider including in your game. Some of these are listed here.
* Texture mapping — You may want to texture may some of your objects. This gives a much more realistic look to the objects.
* Collision Detection — Ensuring that objects do not interpenetrate each other adds a nice touch of realism to a game. If your game is such that collisions are important, you may want to consider this.
* Animation — Having a blob that slides around the environment is great, but having an animated monster that runs around – well, it’s just much cooler. Of course, it is also more complex.
* Speed Optimizations — If your game is extremely slow, you may want to consider adding an optimization or two. Some of the popular, yet fairly simple, techniques are view frustum culling, occlusion culling, and level of detail.
* Physically Based Motion — Incorporating gravity, friction, laws of momentum, etc., also give an added look of realism.
* Procedurally generated textures — For simulating fire, smoke, or clouds.
* Advanced Rendering Effects — OpenGL provides a mechanism for implementing several rendering effects. Multi-pass rendering, in which you vary some parameter through each pass, shadows, reflections, billboarding, and environments mapping are examples of effects you can produce.
* Sound — Sound adds an additional level of realism to a game environment.
* Networked Multi-Player Capability — If you want to get fancy, a cross-network multi-player game is a compelling way to go. Beware the famed network latency, however.
* Characters Interacting with the Environment — Some games may require that the characters pick up objects, annihilate or destroy objects, etc.
* Difficulty Levels — Some games may need to include multiple difficulty levels that get progressively more difficult as the user completes the previous level.
Prioritizing Game Weaknesses
Since you won't have time to implement or fix everything you'd like to during the semester, you'll have to pick and choose. Included below are our suggestions for how to prioritize those things according to what's important for this class.
Problems to worry about:
* My game is way too slow to play.
* Critical features of my game are flaky. (Like if your shots sometimes pass through the asteroids.)
* It's impossibly difficult to play my game.
* It's incredibly easy to play my game.
* My game's performance characteristics vary wildly. (The game slows to a crawl when there are more than 10 shots on the screen.)
Problems not to worry about:
* My game doesn't have any sound.
* I wouldn't pay 25 cents to play this game in an arcade, even in 1981.
* My friends laughed at my game when I showed it to them.
* The computer opponent in my game is dumber than a post.
* I don't have as many difficulty levels as I think I should. (Maybe there shouldn't be any, depending on your game.)
Helpful Links
FlipCode
GameDev.Net
Gamasutra
Stanford Video Game Resources page Lots of really good links. Check this one out
OpenGL Control Flow
