The University of Melbourne Department of Computer Science and Software Engineering Graphics and computation.

Transcription

1 The University of Melbourne Department of Computer Science and Software Engineering Graphics and computation Project 2, 2007 Set: 16th April Demonstration: week commencing 14th May Electronic submission: 10am, 14th May Marks: This Project counts towards 20% of the marks for this subject Participants: This Project can be done either individually or in groups of no more than three people. Assessment: Marking will be the same regardless of the number of participants, for either individual or group submissions. Aim This Project is based on Project 1. The purpose of the Project is to expose you to a variety of graphics and computational techniques. The Project is loosely based on the retro game Scorched Earth. Scorched Earth claims to be the mother of all games although this slogan seems to have been a reference to the Gulf War, and not to the game s actual quality. It has been reviewed as one of the best 2-player games you ll ever play, and a design that truly stands the test of time. For some people, it may be addictive. You have been warned. Scorched Earth is a simple, 2-player tank (or cannon) game. Players take turns to destroy each other using stationary artillery guns. Each turn, you adjust the power and angle of your gun, then launch your projectile. If you hit the other player, you win. If you hit the landscape, you leave a giant crater. Entire mountains can be levelled if you play the game for long enough! A popular variant, which actually predates Scorched Earth, is Gorilla. Two gorillas stand on tall skyscrapers, trying to kill each other with exploding bananas. Again, each player would enter the angle and velocity to throw the banana, and hope for the best. A non-violent interpretation you might choose to adopt for this project would be Valentine, where you launch hearts at your loved one (if you prefer to hug than to kill). Game rules Wikipedia contains an overview of this genre of computer game, which contains links to specific examples throughout the ages. (computer game) 1

2 Your task: Scorched Earth/Gorilla/Valentine 3D Your task in Project 2 is to adapt the traditional, two dimensional Scorched Earth game (or your chosen Valentine, Gorilla or other variant) into a three dimensional form. Regardless of your chosen theme (Gorilla, Valentine, etc), the game will take place on the fractal landscape you have generated in Project 1. In some ways your task will be easy, since you are free to program very simple (retro) shapes to define game entities, such as the tanks, gorilla or prospective valentine. There will, however, be several challenges, including 1. how to create and render objects such as the cannon, bananas or hearts. 2. how to smoothly change perspectives from one player to another. 3. how to implement parabolic motion of the thing you are throwing. 4. how to deform the terrains surface, when things you throw miss their target. You must use splines to create at least some of the game objects - for instance the cannon, the bananas, or the hearts. You must also use splines to generate smooth camera motion. You can use more than two players if you choose and you may optionally choose to randomly position players. Specifications and marking criteria A Project that meets all of below will receive 20 marks. Modelling players and projectiles (that you see during play) [5 marks] For building (at least one) of the objects involved in the game, such as the cannon, banana or heart, you need to utilise splines. This can be done by generating a spline curve in two-dimensions, and quantising it into a discrete number of points. These points would then be rotated an axis, adding vertices at regular intervals, to generate a three dimensional object. This technique is known as lathing. Another way to generate a shape from a spline is to extrude - basically, using a 2D spline as a cookie cutter to make a 3D shape. The Foley textbook has a section on translational sweeps and rotational sweeps (extrusions and lathes) on page 376, Section There s a picture there as well. Two images which demonstrate the spline/lathe process can be seen at NURBS and Bezier Splines.html Take note of step 9, which shows a 2D representation of a spline, and step 10, where the spline is lathed around the vertical axis. Note that you will be required to rotate the projectile launching device to reflect the current firing angle. This may be hard if you attempt to create a complicated player model. A spline based cannon will be easiest, even if it fires love hearts or exploding bananas. Using splines you will be able to create a great variety of cannon shapes. 2

3 Players (tanks/gorillas/valentines/etc) clearly visible and clearly distinguishable (eg, red tank vs. blue tank) [1 mark] Projectiles (cannon balls/bananas/hearts/etc) clearly visible at appropriate stages in the game [1 mark] At least one of the above game items modelled using splines [2 marks] The level of detail of the spline-based object(s) corresponds to the distance of the object(s) from the camera. When the object is viewed from afar it should be rendered with less quantisation of the spline, and thus, less polygons overall. [1 mark] Viewpoint changes via spline trajectory representation (between alternate turns) [6 marks] Each player, when they take their turn, starts with a viewport that allows them to see their own tank, and that faces in the direction of the other player s tank. Players should be able to move the camera so you can get a clear view of what you need to see. When a player s turn ends, the camera must make a smooth transition (using splines) to a similar viewport for the other player. Obviously, it will be possible for your opponent to be hidden behind a mountain. Where the opponent s tank is obscured by the landscape (but only where it is obscured), you will need to draw it using a flat colour (no lighting, texturing, or anything). To accomplish this, you will need to understand how depth testing (or z-buffering) works. At the start of each turn, the camera is appropriately positioned behind the player s tank, facing the opponent s tank [1 mark] The user can move and rotate the viewport and the camera so as to get a better view of the terrain and the enemys tank. This rotation could be accomplished using the mouse. The camera must never pass inside the terrain. [1 mark] When a projectile is launched, the camera targets the projectile instead of the player, so that the user can see where the shot lands. [1 mark] At the end of a player s turn, the camera follows a spline-based path from its current orientation to its new orientation [2 marks] Any part of the opponent s tank that is obscured by the terrain (but only that part) is drawn in flat colour [1 mark] Projectile motion and gameplay [4 marks] The player will use the keyboard (eg, Up, Down) or the mouse to control the elevation (and, optionally, the horizontal rotation) of their projectile dispensing device. The graphical objects on the screen will need to rotate accordingly. The player will then need some way to set the power of their shot (for instance, holding down the space bar until a desired power level is reached). Once in the air, the projectile should be governed by basic parabolic motion. This means that the projectile has a velocity vector, which is added to the projectile s position each frame. The vertical 3

4 component of the velocity vector is decreased over time to represent gravity. include wind in your game, although this is not required.) (You may wish to The following website has a useful java applet for visualising projectile motion. It demonstrates how the angle and release velocity affect the trajectory of a projectile. stuff/applets/projectilemotion/jarapplet.html Using the keyboard or mouse to aim the cannon/the gorilla s arm/cupid s bow and arrow, with correct 3D transformations to represent this graphically. In other words, you need to be able to see where you are aiming. [1 mark] Modelling projectile motion, with correct 3D transformations to graphically represent the flight of the projectile. [1 mark] Players take turns in order, and victory conditions are tested for appropriately [1 mark] Sufficient text or other displays are present to let the user know what is going on (eg, whose turn it is, who has won, which direction wind is blowing, etc) [1 mark] Deforming terrain through projectiles exploding [5 marks] The idea with deforming the terrain is that if projectiles miss their target, a crater will be formed by the cannon ball/banana/heart. Because the geometry will change, you will need to update your vertices, normals, and so on. You will need to think about how to handle numerous projectiles landing in the same place. Is there a limit beyond which you will not allow further deformation (eg, the plane Y = 0, representing sea level)? Or can the user plumb the subterranean depths of your fractal world? The choice is yours! Collision detection between the projectile and the landscape, and between the projectile and the opponent s tank [1 mark] Projectiles that hit the ground must leave a crater. [1 mark] Appropriate recalculation of vertices, normals, and (if relevant) display lists. [1 mark] Crater region is suitably discoloured to suggest warfare/bananas/love/etc [1 mark] The game maintains a reasonable frame refresh rate (sufficient to play the game) [1 mark] Newsgroup consultation You are encouraged to ask questions, answer questions where possible and share examples of pseudocode and/or small examples of code that highlight the correct invocation of OpenGL commands, GLUT commands or algorithmic techniques. You are not allowed to exchange complete methods or classes. Remember that copying code from the Internet or from your colleagues will be considered cheating. Note that via electronic submission, your code will be checked for similarity between submissions and with code available over the Internet. 4

5 Group CVS repository A cvs repository will be made available to enable Project groups at /home/studproj/380/ to share and store code in a central repository during joint development. If you want to utilise this shared space, please contact the Head Tutor, Athol (user name: abirtley) with a list of your groups user names, to add to a 380 group. Please also consult the 380 web site for possible additional information regarding the cvs repository. Assessment Your Projects will be evaluated on the functionality of your demonstration and your electronically submitted source code for a total of 20 marks, according to the marking structure described above. Marking will be the same regardless of the number of participants, for either individual or group submissions. Electronic submission You code must compile and run on the machines in lab 1.08 using Visual Studio installed on them and be implemented in C or optionally C++. Your projects must include a Microsoft Visual Studio or Visual C++ Express project file that can be successfully launched under Windows XP on the machines in the lab. Please check that your code works first in the labs, before submitting. If you have coded under a different development environment, you will probably need to 1. create a new project in Visual Studio 2. add your existing files to this project 3. possibly change include paths (to e.g. glut.h), 4. compile the program by selecting Build Project from menu, and finally 5. make sure the project runs. Either click the green arrow, or navigate to the directory with the executable (e.g. \Debug) and run it to make sure it works. For groups of more than one person, your Project must only be submitted by one member of your group. You must electronically submit all your source code, headers and project file required to run your programs using the submit system by the due date, using the following command submit *.c *.h Scorched.vcproj readme.txt group.txt Note: your project must be named Scorched.vcproj, and building the project must generate an executable file named Scorched.exe in the \Debug directory. 5

6 Note: Please don t submit the same program under multiple login names, we only want to mark it once! Important: if your project contains code from other sources, in particular from other web sites, you have to clearly indicate this in readme.txt. Identify which classes or methods are your own and which are from a different source. Remember that copying code from the Internet or from your colleagues will be considered cheating. We will be checking for similarity between submissions and with code available over the Internet. The group.txt file must (strictly) include a list of lowercase login names, one per line for all people in your Project group (or just one login for individuals). For example, >cat group.txt >login1 >login2 The readme.txt file must (briefly) describe your implementation. One paragraph of text under each of the following headings should be sufficient: (1) How to play the game (especially if you have implemented additional features) (2) How you modelled game objects, (3) How you handled camera motion, (4) How you modelled projectile motion, and (5) How you handled deforming the terrain. Brief descriptions are sufficient and concise descriptions are preferred over long, verbose descriptions. 6