-------------
Team members:
-------------
Andy Kuo
Dave Merrill
Xinru Woo
-----------------------
Game name and platform:
-----------------------
Scorched Earth++, for Windows (95/98/NT/2000/ME) machines.
----------------
To run the game:
----------------
Double-click on the executable "se.exe" in the folder. There are no
command-line parameters.
-----------------
To play the game:
-----------------
The object of the game is to destroy all other tanks. The player views
the action by manipulating a free-floating camera, using the following
controls:
8: rotate up
2: rotate down
4: rotate left
6: rotate right
7: move forward in the direction the camera is currently facing
1: move backward in the direction the camera is currently facing
To control the tank:
w: rotate cannon up 1 degree
s: rotate cannon down 1 degree
a: rotate cannon left 1 degree
d: rotate cannon right 1 degree
r: increase power by 1 unit
f: decrease power by 1 unit
space: fire
Blocks are destroyed instantly by a hit. All blocks on top of the
destroyed block will fall straight down (which leads to unrealistic,
but strangely artistic worlds =P ).
A direct hit to a tank will kill it. If a block explodes close enough
to a tank, the tank suffers splash damage, inversely proportional to
the distance to the explosion.
Projectiles can be bounced off walls, the ceiling, and the floor.
------------------
Advanced features:
------------------
1. On-screen control panel: Using an orthographic projection,
certain characteristics of the current player are overlayed in the
game window. The control panel shows the cannon's rotation up and
down (pitch), and left and right (yaw). In addition, it displays
the current power of the shot, and the current life. All four
characteristics are represented iconically.
2. View frustum culling: Using the gluUnProject function to find
the object coordinates of the viewing frustum, we derive equations
for the 6 clipping planes. Then, when drawing the world, we ask
the camera object if each object if viewable before actually
messaging the object to draw itself. To detect if an object should
be clipped, we find the distance from the center of the object
to each clipping plane, and if the object is outside the plane by
a distance greater than the width of the object, we cull that object.
3. Procedural and physically-based modeling: We wrote a particle
engine to model two different kinds of particle systems: explosions
(from destroyed blocks and tanks) and smoke (from damaged tanks).
The engine consists of an abstract base class that supports a few
generic operations that apply to all particle systems. Each unique
particle system is subclassed from this base class, and provides the
implementation of the particle behavior. The explosion particles,
for example, are all the same size, and explode outward in all
directions from the explosion center. Smoke particles, on the other
hand, expand in size with time. They also generally move upward,
with slight side-to-side movements. All particles are 2D textured
squares that are rotated to always face the viewer.
Help on how to write a particle engine was obtained from:
http://nehe.gamedev.net/opengl.asp
4. Collision detection:
Oriented Bounding Box (OBB) Collision detection is used to initialize
the blocks in the world. Blocks are placed randomly about the room,
rotated about the y-axis. If colliding, the block is placed above the
block collided with (making sure its center of mass is above the
block immediately below it). This cycle of checking for collision and
shifting up the y-axis is invoked as many times as needed until no
collision is detected. The collision detection is also used to detect
collision between projectile, blocks and players. Detection is
implemented within the object itself. Namely it is implemented in the
BaseObject class, off of which all of the objects are subclassed. Any
new objects introduced into the world can have full collision detection
functionality and the object will be represented with an OBB for this
purpose. Collision detection code for objects rotated about any axis
exists in our game, but we only needed detection about the y-axis. Thus,
a number of the collision detection equations are commented out in an
effort to save time from doing unneccesary floating point calculations.
Equations for OBB collision detection were derived on our own, in
accordance to the OBB derivation analysis offered by M�ller and Haines
in 'Real-Time Rendering' text (pg 325-329).
5. Simulated dynamics:
The projectile follows a parabolic trajectory calculated by taking
ticks from the system clock. It also will bounce realistically off
of any of the 6 surfaces composing the inside of the game area.
(walls, floor, ceiling) Each time the projectile bounces off of a
surface, its kinetic energy is attenuated by a constant, just as in
the real world.
6. Sound:
The sound effects are pre-loaded, and are triggered by events in
the game (turret rotation/raising/lowering, projectile
firing/bouncing/exploding, and power increase). Each sound has
several versions, which are selected among at run-time to give a
realistic impression of distance between the player and the source
of the sound. If the player (i.e. the "camera") is close to the
source of a sound, the most loud, dry sound will be played. With
increasing distance between the camera and the sound source, the sound
selected will:
- be increasingly low-pass filtered
- be quieter
- have more reverberation applied to it
-----------------
External sources:
-----------------
- We used the GlutMaster adaptation of GLUT, obtained from
http://www.duke.edu/~stetten/GlutMaster/GlutMaster.html
- Textures for the walls, ceiling, and floor were obtained from
http://www.nepthys.com/textures/
(Textures for the blocks were created from scratch)
- Tank models and textures were obtained from
http://baskuenen.cfxweb.net/ooengine.htm
- Sounds were found on the web at: http://www.wavplace.com/sounds.htm
and at http://soundamerica.com/
- We used & modified the sound-playing code found at:
/usr/class/cs248/assignments/assignment3/sound-examples/