Java程序辅导

The University of Melbourne
Department of Computer Science and Software Engineering
433-380 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.
http://en.wikipedia.org/wiki/Artillery (computer game)
1
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 10.4. There’s a picture there as
well.
Two images which demonstrate the spline/lathe process can be seen at
http://www.4dtutorials.com/Lathe 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
• 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 alter-
nate 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 op-
ponent’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, op-
tionally, 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
component of the velocity vector is decreased over time to represent gravity. (You may wish to
include wind in your game, although this is not required.)
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.
http://galileo.phys.virginia.edu/classes/109N/more 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 pseu-
docode 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
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 380 2 *.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
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