COMS 4160 Assignment 4

Due: Dec 11, 11:59pm, Web site included (demos on Dec 12, Milestone due Nov 22, 11:59pm)

Turning in A4 (subject to change):

• Assignment 4 grading (and assignment 3 for that matter) will consist of a time period on Dec 12. Signup sheets will be provided about a week in advance. You must have a website for your game by your appointed time. You will arrive at the lab, log into a machine, go to your web site, download your game, and demo it.
• You must create a web site with everything needed to download and run your game. The site should be 1 or 2 web pages with a description, download area, and instructions for compiling and playing the game. Include in the download area a zip (or tar) of the entire website so it can easily be placed on a diferent server later on. This means all your links must be local (not absolute).
• You can create a web site using your cunix account by creating a directory called public_html in your home directory, or using your cs account by creating a directory called html in your home directory. The site is http://www.[cs.]columbia.edu/~your_login.
• If you have conflicts for grading, send e-mail with subject A4 conflict - your name. Only describe real conflicts, not preferences.

Milestone (due Nov 22, 11:59pm)

As with the previous assignment, this can be a challenging assignment. However, you now know OpenGL, so I assume it will be somewhat easier. As before, the milestone is worth 10 points and the assignment itself worth 120 points. The point of the milestone is not so much for grading purposes, but to get you to start early on the assignment, and especially to seek help from the instructor or TA if you have problems, before it is too late. In any case though, if any problems arise at any time, please seek assistance from the instructor or TA.

For the milestone, you should submit the following. In this case, you should set up a webpage, e-mailing cs4160@cs.columbia.edu a pointer to it (this will preview the final website you will set up).

• Briefly describe and name your game, stating what your goals are for the final submission of the project (3 or 4 sentences is enough).
  
  
• At least two images showing the current state of your game (with a brief one para) writeup. At this intermediate point, I would expect you at least have some of the scene in there, with perhaps some preliminary user interaction. As before, the main point is to provide an intermediate checkpoint to let you and us diagnose problems early. If you haven't progressed past assignment 3 or don't quite know how to start, this is clearly a sign of trouble and means we need to work together to make sure you get back on track. In this case, please seek help from the instructor or TA.
  
  
• For each of the requirements of the assignment below, discuss what you have already implemented, and how you plan to fulfil the remaining tasks. Keep this brief; a para or two suffices. The main point is for you to assess honestly where you are and that you have a plan of action to complete the assignment.

Write a game [120 points]

Goals

Write a game. Your game doesn't have to be anywhere near as cool or complex as Quake 3 (which was written in OpenGL), but it should be playable. The goal here is to learn about writing real-time interactive OpenGL applications, not to spend all your time creating more intelligent computer opponents. This is not in any way to suggest that you shouldn't be as creative as possible. But remember, pretty will only get you so far. Definitely prioritize functionality over originality.

You may write code that uses advanced features of the latest graphics cards. The lab has both nVidia FX and ATI Radeon 9800 Pro cards. These are only available on winXP. Make sure to include all the libraries and dlls. Assume nothing about teh machine that will be running your code. If you code for linux, you must use only standard openGL commands. You may bring your own laptop for the demo session.

For the purposes of this assignment, a 3D video game is an interactive 3D computer graphics application written in OpenGL that involves some concept of scoring and/or winning and losing.
The basic requirements are

• A help message printed at the start describing the goals of the game, and how to play it.
• The game should incorporate 3D viewing with perspective, with at least some user control of viewpoint, and should of course be populated with 3D geometric objects.
• User input via keyboard and mouse is required.
• Objects must be lit with smooth shading.
• You should have some form of collision detection, at the very least to prevent objects colliding, passing thru walls etc.
• There should exist a scoring system or some other identifiable concept of progress and feedback.
• You must have at several 'enemies' moving independently around the scene at all times. (Or until you kill them.) These are to be an integral part of the game's objective, and should move on their own, without any prompting from the user.
• You must have several animated scene elements that may or may not be part of the game play. For example, clouds passing overheard.
• You should at least have 'fake shadows' cast by the enemies and hero. These are just dark or black circles that appear on the ground under the object. Their shape isn't accurate, and they are not necessarily in the right location relative to the light source.
• A hierchical character with moving parts. For example, a person with legs that move when they walk, or a head that turns. The idea here is that the ModelView matrix of one part is dependent on the ModelView matrix of the whole body.

Additional Requirements: Besides the above basic requirements, you must have the following (not required for CVN students working alone):

• Accurately shaped and placed shadows for the moving characters. The shadows don't need to be cast on all the objects in the scene. It is sufficient for them to be cast on predetermined walls and floors.
• An object that can be picked up and moved around with the viewer (while visible) and then placed somewhere. This is to prove you can control objects independent of, as well as coupled to the viewer.
• A Movable light source. If you like, you can incorporate this with the above requirement. (E.G. a flashlight)
• You must have two distinct camera views. You may choose to allow switching between them, or displaying both at all times with a picture-in-picture effect. For a race car game, you'd want a view from the car, and one from overhead. For a Quake style game, you'd want a view from the player's perspective, as well as one from behind the player so you can see his character. Both views must be adjustable with mouse or keyboard controls.
• 2 player mode. In this mode, one player has half the keyboard, and the other player has the other half (and perhaps the mouse). The view on the screen must be split in 2, each half following one player's viewpoint. The 2 players can be competitors or allies.

The idea is to create a reasonably complex, and visually pleasing environment that has dynamic aspects, but can still run at playable speeds. You might find that carefully choosing material properties will get you further in this direction than texturing everything.

We would recommend that you create a basic game that works, and only then start improving it bit by bit.

You are limited to 1MB of textures. The idea behind this is that you can create very neat effects by using textures wisely. If you just throw up a 10MB image of a backdrop, your game performance will suffer, and you will not have demonstrated anything useful. You may use any format you like, as long as you provide the libraries and utilities on teh website.

You are limited to 5MB of object description files. Unlike in HW3, you may design as much as you like in a modeling program. This is ok since you'll have to implement object movement and collision detection on your own. Use whatever format is most convenient, but you must provide all the libraries and utilities.

Beyond these requirements, you are free to exercise your creativity. You may look at the optional features in the previous assignment for some ideas. Additionally, you may want to include sound effects and AI for the computer opponents, although this is not required and you should not be worried if your game is silent and the computer opponent is dumber than a post (a moving post).

This project could either be a lot of fun or something from hell. Some of you will clearly go overboard and write a game on which to base a startup company. While we certainly don't want to stop you, please remember that you don't need to go overboard. Get functionality working first, and then add glitz and extra features. Set some initial goals given your abilities, time available (1 month), other commitments, etc. The goal is to write an interactive OpenGL application, not the next killer game. And please START EARLY!!

The grading criteria will basically depend largely on the graphical complexity of your game (how many features you implement) and a general evaluation of the difficulty level and ease of game-play of your project. We will award approximately 90 points for a game that satisfies the basic requirements, essentially fulfils the graphical complexity requirements of assignment 3, and is interactive, easy and fun to play. The remaining points will necessarily be awarded on more subjective criteria, with more points for games of higher quality. Your README file should document all features that you think we might be interested in (and others necessary for playing the game).

Helpful hints

This is a more open-ended assignment. As such, there is no code framework, although your solution to homework 3 might be the best place to start. Also, see the helpful hints above, which provide links to game development resources. If you have questions, please feel free to contact us. Some comments that you might find useful are below. First, with respect to game design, you don't need to come up with an entirely new idea, and may reproduce an existing video game (provided it is in 3D, has collision detection, etc.) You could also take a 2D game and make it 3D. The following suggestions are for if you are stuck:

• 3D Space Invaders - In the 2D version, the player moves a rocket launcher horizontally along the bottom of the screen, shooting missiles at rows of enemy ships that descend from above. When a missile hits an alien ship, both disintegrate. The ship rows move back and forth, and each time they switch direction they move downward. If a ship lands, the game is over. The ships also drop bombs periodically that fall towards the ground. If a bomb hits the rocket launcher, that round of the game is over. (This is similar to the game Missile Command.) The 3D versions would have the player's view from below (as the launcher) with the alien ships approaching you straight ahead. Shooting at them would have the same effect as before, only you'll have to show them exploding in 3D.
• Asteroid - Asteroids is a simple game where you pilot a spaceship in an asteroid field, shooting asteroids to destroy them before they collide with you. Larger asteroids break into smaller asteroids as you shoot them. The smallest asteroids are simply destroyed when shot. You have a limited amount of shield power to protect you from asteroids. If you are in a real fix, you can jump into "hyperspace" to get you out of a tight spot. In 3D, the ships are coming at you, and are shooting spherical objects at you.
• Brickles- The player controls a rectangular paddle which can be moved in any direction on the screen to catch a ball that is reflected off the paddle and the wall (made of bricks). You can make the objective to get the ball to go into a certain goal on the wall, or to get the ball to hit every brick (you can either make the bricks disappear, or color them in a new color). The ball bounces off of the paddle and the walls and has a constant speed. You may want to have multiple goals and balls (maybe of different speeds and sizes) to make it more interesting.

Your game should be highly interactive; that is, your program should be constantly redrawing to generate moving objects, and requiring continuous input by the user or game player. By these criteria you should avoid card and board games. If you're at a total loss as to what to do, implement Astroids. It's a good starter game, and it is not difficult to get the basic functionality to work out. You can always add functionality and glitz.

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. Modern PC systems with fast 3D graphics accelerator cards will usually yield satisfactory 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 Web page above to sources of information on maximizing OpenGL performance.

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 links Web page above will contain pointers to several freely available modeling packages. 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.

Acknowledgements