3D Animation Workshop: Lesson 78: Web 3D Gaming | WebReference

# 3D Animation Workshop: Lesson 78: Web 3D Gaming

## Lesson 78 - Web 3D Gaming - Part 2

The action of the character and the plunger can be divided into four states. The WAITING state is how the game first begins, with the plunger held aloft. (Refresh the previous page to check this out, if necessary.) When the user presses the mouse button down, the WINDUP state begins. The arm retracts until either the button is released or the maximum rotation is reached. When the mouse button is released, the state is changed to THROWING. The arm accelerates forward with the plunger. At approximately one-quarter of a second after the THROWING state begins, the program switches to the AIRBORN state. In this state, the plunger is freed from the hand, moving and rotating with the velocity imparted to it by the arm at the instant of release.

There are a couple of other states to consider as well. The target can either be moving or not moving at any particular time. More importantly, the girl will be either sitting on her perch or being dunked. The dunking state is triggered by hitting the target or by the automatic win option. The pre-dunking state is restored at the next press of the mouse button.

The program can therefore be reduced to certain essential elements. It must be able to receive mouse input from the user to trigger the state changes. More importantly, it must be able to assess the current situation each time a frame is to be rendered, determine where everything should be and what current states should be set as of that moment, position everything in the scene, and then render. Because this is a true physical simulation, the program must be able to store the current velocities and positions of the arm and plunger, and also the current accelerations acting on them. For example, once the plunger leaves the hand, its trajectory is constantly affected by the downward acceleration of gravity. The arm is also accelerating as it moves forward in the throwing motion, just as a spring does when it recoils. I have almost no physics background it all, but I was amazed how easily I was able to understand the physical principles used in the game.

The control center of the program is a single function, called updateGame(), that is called prior to every screen render. This function calls a list of other functions in order, and looks like this:>

``````
void updateGame() {

if (isTargetMoving)
moveTarget();

performSimulation();

setThrowingArmRotation();
animateFollowerArm();
if (curThrowerState != AIRBORN) {
makePlungerHeldByWarhol();
}
else {
// Places the plunger based on simulated trajectory
// calculated in performSimulation()
makePlungerFollowTrajectory();
}

if (curThrowerState == THROWING) {
if ((curTime - startThrowTime) > THROW_TO_RELEASE_TIME)
releasePlunger();
}
if (didPlungerHitTarget()) {
startDunk();
// This makes the plunger bounce backwards
plungerPos[2] = targetCenter[2];
plungerVelo[2] *= -0.5;
plungerAngVelo *= -0.5;

// After the first target hit, the
// target starts animating:
if (isTargetMoving == false)
setTargetMoving(true);
}
if (isNowDunking) {
animateDunk();
}
}
``````

Let's consider this process step by step. The first step is to check the state of the target. If it is moving, the moveTarget() function is called to figure out the current rotation angle of the target. The back and forth motion is achieved by applying a simple sine wave to the rotation angle.

The next step, using the performSimulation() function, is the most important part of the picture. The essence of the simulation is to take the physical state of the arm and the plunger as of the time that the last frame was rendered, determine how much time has passed since the last frame, and then compute the physical state for the current frame. To take a simple analogy, if we know where a car was an hour ago, and we know its direction and how fast it is moving (its velocity), we can figure out where it should be right now. The process is slightly complicated by accelerations, because the velocity need not be constant. For example, the throwing arm does not rotate forward at a constant rate, but rather at accelerating one. But the computations in the code were remarkably easy to understand.

 To Continue to Part 3, or Return to Part 1, Use Arrow Buttons

Created: Oct. 26, 1999
Revised: Oct. 26, 1999

URL: http://webreference.com/3d/lesson78/part2.html