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, 2009 Set: 8 Apr Demonstration: Week commencing 18 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 Pac Man, which is widely recognised as the game which lit the spark of video game mania. A prime example of this is the reported fact that it caused a coin shortage in Japan. Game Rules Wikipedia has a brief overview of Pac Man. Briefly, the player controls Pac-Man through a maze, eating pac-dots. When all dots are eaten, Pac-Man is taken to the next stage. Four ghosts (Blinky, Pinky, Inky and Clyde) roam the maze, trying to catch Pac-Man. If a ghost touches Pac-Man, a life is lost. When all lives have been lost, the game ends. Your task:pacland Your task in Project 2 is to adapt the traditional, two dimensional Pac Man game into a threedimensional 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 such as the Pac man, (pac-)dots, powerpills (larger dots), ghosts (sometimes called goblins) and fruit. The game mechanics are also quite simple, with 4-connected motion and straightforward objectives. There will, however, be several challenges, including: 1. how to create paths where the score dots reside, 2. how to create and render objects such as the Pac-man and ghosts, 3. how to elegantly provide a camera which sensibly displays the scene while tracking the player, and 4. how to effectively manage OpenGL so that the game takes place without substantial lag. Since the three dimensional version of the game will differ significantly from the traditional form, you are free to adapt the rules of the game to suit. In particular, you are not necessarily required to implement all of the entities and functions present in the game if you choose not to. For example, you may choose to only utilise dots and not larger dots (or powerpills) and only get the game working for one level. 1

2 Specification and Marking Criteria A project that meets all of below will receive 20 marks. Navigation graph generation (for use in motion) [4 marks] The underlying data structure for the fractal landscape was based on a some kind of grid. In this step, you must generate a navigation graph G from this data structure. The terrain must be sufficiently shaped (mountainous or jagged) so that occluded regions result; so that being in one location means you potentially cannot observe ghosts in another location on the terrain (this may require you to readjust Plasma fractal parameters). Since your resulting graph potentially might have millions vertices you will likely need to generate a coarser graph for the purposes of path generation - such as using every 10th or every 100th vertex in each coordinate direction of the xy-plane. A graph is generated from the terrain as follows: First, each node in the graph corresponds to a vertex in the grid that is Projected onto the xy-plane. Second, vertices in G are connected to allow for traversal for path finding; the resulting graph G is a planar graph. Since graph G is sparse, i.e. the complexity of the edges is O(n), you have to use adjacency lists for the edges. Implement the data structures for the vertices and the edges of G. Parameters of fractal landscape generator adjusted so that terrain is sufficiently shaped to allow for occluded regions [2 marks] Suitable representation of navigation graph G based on fractal landscape [1 mark] Utilisation of correct adjacency list representation for G [1 mark] Modelling players and projectiles (that you see during play) [9 marks] As stated above, since the three dimensional version of the game will differ significantly from the traditional form, you are free to adapt the rules of the game to suit. In particular, you are not necessarily required to implement all of the entities and functions present in the game if you choose not to. For example, you may choose to only utilise dots and not larger dots (or powerpills) and only get the game working for one level. You should aim to make the pacman look as similar to the original as possible, but obviously must be adapted to appear in three dimensions. One trick is to set up the perspective so that you are just behind and above the packman so that you can see the play. For building (at least one) of the objects involved in the game, such as the pac-man, the ghosts, or the fruit, 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 around 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 _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 Using splines you will be able to create a great variety of cannon shapes using the lathing technique. 2

3 Pacman and Ghosts clearly visible and clearly distinguishable (eg, different shaptes or colours) [2 marks] Dots (and possibly powerpills and fruit) visible [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] Score (game score displayed somewhere) [1 mark] Scoring and capturing evident (either by dots disappearing or pacman being killed). [1 mark] Player and ghost motion (for scoring, chasing and capturing) [7 marks] Pacman motion can be implemented using the arrow keys (up, down, left and right) to move the agent along the corresponding vertices within the navigation graph G. Note that the pacman must be able to arbitrarily move along vertices of the navigation graph G. You can use any suitable terrain following technique to move the agent from one vertex in the coarser navigation graph G to another, along the a path in the finer terrain grid. You will have use the x- and y-coordinate of each of the vertices in the terrain grid and find the corresponding z-coordinate in the grid to set the agents altitude. In order to avoid a collision of the agent with the terrain landscape, you may need to levitate above the ground (for example, at eye height). Select a height that is sufficient enough such that the agent does not collide with terrain. One suitable technique is to use interpolation techniques (see Lectures). Ghosts move faster than the pacman, when chasing. One trick, to make the game easier to play, is to make Ghosts move slower up hills. The pacman (player) can therefore avoid being caught by moving up hills, away from the paths. However staying on the ridges means you don t score, since there might be no scoring dots up there. Clearly, after ghosts have chased you, at some point they need to return to patrolling. By moving out of visibility and/or some appropriate distance threshold of the ghosts, players can also avoid being chased and ghosts return to the paths. You will probably need to set a distance threshold for being close enough to dots for scoring, so that it is easy to score using only the arrow keys for navigation. You can also imagine strategies for playing the game where you climb up onto the ridges and look below for ghosts, before descending and scoring dots along the paths. Last of all, your programs must maintain a reasonable refresh rate, at least fast enough to play the game. Correct navigation via arrow keys on keyboard [1 mark] Camera motion (correct three dimensional transformations) [2 marks] Ghost patrol (randomly between, along paths). [1 mark] Ghost chasing (ghosts go slower up hill than the pacman) [1 mark] Collision amanagement (interaction between Pac-Man and the ghosts or dots, for example) [1 mark] Maintaining a reasonable frame refresh rate (sufficient to play the game) [1 marks] Consultation via Discussion Forum You are encouraged to ask questions, answer questions where possible and share examples of pseudocode 3

4 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 or UG10 installed with Visual Studio and be implemented in C or optionally C++, unless prior permission is granted. 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 Pacman.vcproj readme.txt group.txt Note: your project must be named Pacman.vcproj, and building the project must generate an executable file named Pacman.exe in the.../debug directory. Note: Please do not 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, 4

5 >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