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, 2008 Set: 18 Apr Demonstration: Week commencing 19 May Electronic Submission: 10 am, 19 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 Light Cycles, itself based on the very retro game Surround. It was made famous by the popular 1982 Disney movie Tron (said to be one of the first studio films to exentensively use computer graphics, and starred popular B-movie actor Jeff Bridges) and the corresponding arcade game by the same name. Light Cycles has itself inspired a number of games, most notably the ubiquitous Snake, played on mobile phones everywhere. While superficially simple, a winning strategy can be quite complex and there is plenty of scope for extension now that machines have more than 64K of RAM. Game Rules Wikipedia has a brief overview of Light Cycles within the larger article of Tron. (arcade game) Briefly, you play the driver of a Light Cycle : a machine which leaves an infinitely long trail of light behind it. The object of the game is to force an opponent also driving a Light Cycle to crash into a wall or a light trail. This picture demonstrates the blue Cycle crashing into the light trail left by the yellow Cycle (and the yellow Cycle crashing into the wall, unless the world wraps around). In the (slightly) more recent variant called Snake (or Nibbles, etc.), the Light Cycle is a snake which is fixed length, but grows as it eats objects (like fruit, or numbers) which are sequentially placed in a random 1

2 location in the world. After a certain number of objects are eaten (e.g. the numbers 1-9), a new level is generated. Two players can play co-operatively, where they attempt to finish the level without crashing into each other and points are accumulated together. Or, they can play competitively, competing to eat the objects for points, or causing the opponent to crash like in Light Cycles. Your task:light Cycle/Snake 3D Your task in Project 2 is to adapt the traditional, two dimensional Light Cycles game into a three-dimensional form. The game will take place upon the fractal landscape you have developed in Project 1. In some ways, your task will be easy, as you are free to use very simple (retro) shapes to define game entities such as Light Cycles and light trails (and fruit/numbers, if you choose to implement them). The game mechanics are also quite simple, with only two (long) entities, and 4-connected motion. There will, however, be several challenges, including: 1. how to create and render objects such as the Cycles and trails 2. how to elegantly provide a camera which sensibly displays the scene while tracking the player 3. how to display two perspectives for two players simultaneously 4. how to implement landscape deformation and edible objects 5. how to effectively manage OpenGL so that the game takes place without substantial lag Specification and Marking Criteria A project that meets all of below will receive 20 marks. Modelling players and in game entities [5 marks] The game should take place on a Plasma Fractal landscape, using your implementation from Project 1. Using OpenGL, you will need to create and render polygonal objects corresponding to two players and the trails that they leave behind them. As well, you will need a set of objects to be eaten, and something to represent projectiles (you might find calls like glutsphere, glutcylinder, etc. to be useful); simple objects should suffice. If your scene is complex, you might find it difficult to manage memory, especially video memory: your project should not have excessive slow down or freezing. In addition, you must calculate vertex normals instead of surface normals (see slide 89 of the readings for an example). Vertex normals should be calculated as the average of the surface normals for all faces incident on the vertex. An example in OpenGL will be made available to demonstrate this. Players (Light Cycles/Snakes) clearly visible and distinguishable (e.g. yellow Cycle vs. blue Cycle) [1 mark] In game entities (projectiles and edible objects) clearly visible at appropriate stages in the game [1 mark] Vertex normals are calculated correctly [1 mark] The game should take place in real time, without noticeable slow downs or freezes [2 marks] Cameras and viewpoints [7 marks] You must implement two simultaneous displays in OpenGL, suitably dividing the screen (e.g. left half right half, or top half bottom half). To do this, you will need to set up two cameras and perspectives: some 2

3 reading of the OpenGL Redbook (for example) will be necessary. Each display will provide a visualisation for one player. The camera should be positioned in some 3 4 overhead angle behind the player that allows the player and landscape directly around the player to be seen at all times. You could place the camera under user control, à la numerous first person shooters; but with two players sharing one keyboard, gameplay might be difficult. The camera should start appropriately positioned behind the player [1 mark] The camera should follow the player as they move through the landscape, remaining in the rear position [2 marks] The player should be visible at all times and the camera should never pass inside the terrain [2 marks] Two visualisations should be displayed simultaneously on the screen [2 marks] Gameplay [8 marks] Each player will use the keyboard (or mouse) to control their Light Cycle or snake as it moves through the landscape. The player should not be able to halt, but you can allow them to alter their speed if you choose. A player should die (lose a life, end the game, etc.) if they crash into the trail left by either the opponent or themself. This would happen when the motion of the player causes the Cycle or snake head to intersect a trail. You can consider the border of the landscape to be a wall (or cliff into the abyss) for the purposes of crashing, or wrap around and have the player appear on the opposite side. Players might have multiple lives, if you wish. Once you have a standard implementation of Light Cycle, you should extend it to Snake, where the trail is length limited, and grows when the player eats objects which randomly appear one by one in the landscape. Scoring can be either co-operative or competitive. If the snakes are continually gaining in length from eating objects, the game will necessarily come to an end when a snake dies. If you choose, you can make a new level generate after a fixed number of objects are eaten. As an add on to the standard Snake/Light Cycle, you must implement landscape deformation: the player should be able to shoot a visible projectile forward at some fixed angle, which then falls parabolically using standard forward kinematics and explodes when it intersects the terrain. The projectile should deform the terrain in some sensible manner which would allow the player to pass under a trail in the explosion radius, and optionally destroy a Cycle or snake head within the explosion radius. The following website has a useful java applet for visualisating projectile motion. stuff/applets/projectilemotion/jarapplet. html After a projectile deforms the terrain, the geometry will change. This means you will need to recalculate vertices, normals, etc. The colour of the terrain should also somehow reflect the change in height. Players should respond to keyboard control to move independently through the landscape, leaving a trail [2 marks] Players should die when they crash into a trail, and die or wrap around when their motion takes them through the landscape border. One or more crashes should cause the game to end. [2 marks] An edible object should appear at the start of the game, and new ones should be generated at a random location on the landscape when one is eaten. [2 marks] 3

4 Players should be able to fire projectiles which move according to forward kinematics (parabolically), and suitably deform the terrain [2 marks] 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. 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 wish to use this joint space, please contact the Head Tutor, Jeremy (jeremymn@csse...) with a list of your group s user names. Further information regarding the repository will be made available via the 380 webpage. Assessment Your project 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 scheme detailed above. Marking will be the same regardless of the number of participants, for either individual or group submissions. Electronic submission Your code must compile and run on the machines in lab 1.08 installed with Visual Studio 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 item possibly change include paths (to e.g. glut.h) 3. compile the program by selecting Build Project from menu, and finally 4. make sure the project runs. Either click the green arrow, or navigate to the directory with the executable (.../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 of your source code, headers and project files required to run your programs using the submit system by the due date, using the following command: submit *.c *.h LightCy.vcproj readme.txt group.txt Note: your project must be named LightCy.vcproj, and building the project must generate an executable file named LightCy.exe in the.../debug directory. 4

5 Note: Please dont 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, and (4) How you managed projectiles. Brief descriptions are sufficient and concise descriptions are preferred over long, verbose descriptions. 5