# Steering with Momentum

February 6, 2000
by Pat McClellan

I'm doing a driving game based on last week's Handyman article. I have the car driving round the track ok, except that it's not realistic - there's no inertia to give an acceleration effect, and no momentum, so it just stops dead when I take my finger off the accelarate key. Have you any tips?

Andrew

Dear Andrew,

I'm happy to help with the momentum, acceleration, drag (coasting) and braking. I'm going to leave it to you to figure out how to constrain the car to the track (assuming that's what you want to do.) I leave it to you because, frankly, I'm not sure how I'd do it. While the constraint of sprite property could keep the car over the rect of the track sprite, that doesn't keep it on the track itself. So, I think I'd try to do it mathmatically and use that instead of the constraining rect of last week's Steering behavior. For those of you who didn't read that article, I'd strongly suggest you do so now because I'll be using that behavior as a starting point for this article.

A sample movie is available for download in Mac or PC format. This is a D7 movie.

In last week's article, I spent a lot of time on the rotation angle of the moving sprite (the car). Rather than having to calculate the angle and X,Y change for each frame, I chose to create a lookup table. This take a little more time at the beginning, but can potentially speed up the frame to frame performance. In the beginSprite handler, we called the handler makeTrigList which built a list of X,Y values which are added or subtracted from the sprite's loc. In that behavior, we had a constant speed, so I just multiplied the speed as I was generating that list. However, if the speed is going to be variable (accelerating upwards and coasting or braking downward) then we'll want to leave speed out of the makeTrigList handler. I've indicated where I omitted it with a comment below.

```
on makeTrigList me
pTrigList = []
increment = (pi * 2)/pAngleSegments
f = 0.0
angle = 0
repeat while f < (pi * 2)
hFactor = sin(f)
vFactor = cos(f) * - 1

-- speed was omitted from the next line
hvList = [hFactor,vFactor]
f = f + increment
end repeat

end makeTrigList

```

To simulate momentum, we'll need to include acceleration, drag, and braking. We should also have a speed limit. All of these will be new properties in our new Steering w/ Momentum Behavior.

We'll need some new keyboard controls. J and L are still fine for the rotation. (I don't use arrow keys in Shockwave movies because some browsers reserve those keys for their own functionality -- like scrolling.) The I key will still work for applying forward thrust. But now, we need the K key for the brake. In order to thrust backwards -- which will either slow your forward motion or cause backward motion -- we'll use a keyboard combination, Control + I. All of these controls go into the exitFrame handler:

```
on exitFrame me
-- rotation controls
if keyPressed(37) then
rotate me, #clockwise
else if keyPressed(38) then
rotate me, #counterclockwise
end if

-- thrust, brake, coast, thrustBack controls
if keyPressed(34) then

if the controlDown then
moveSprite me, #thrustBack
else
moveSprite me, #thrust
end if

else

if keyPressed(40) then
moveSprite me, #brake
else
moveSprite me, #coast
end if

end if

end exitFrame

```

Note that all of the if-then-else statements are carefully constructed to allow for rotation and motion at the same time, but not for rotation or motion in more than one direction at a time. This exitFrame handler doesn't actually rotate or move the sprite, but rather calls on other handlers in the behavior to do so. Again, the rotate handler wasn't altered at all from last week's article, so we'll just focus on the moveSprite handler next.

First we retrieve our XY vectors from the lookup table, pTrigList. We'll be multiplying these values by our pSpeed, but first we'll need to determine what that speed is going to be (based on whether it is thrusting forward, thrusting backward, coasting, or braking). To thrust forward (accelerate) then we simply add the pThrust value to the current pSpeed. This will cause it to cumulatively raise on each subsequent frame. The min() function just makes sure that pSpeed doesn't exceed our pTopSpeed (speed limit).

ThrustBack does just the opposite, although I've limited the backward speed to half of our forward speed limit -- just because it's more dangerous to drive backward. Brake subtracts the pBrakePower value from the pSpeed (or adds it if the car is moving backwards), and coast does the same, but with the much lower power of the pDrag value. After pSpeed is set, the move is calculated, the newLoc is checked against the bounding rect, and the sprite moves.

```
on moveSprite me, whichCommand
-- convert angle to list index
whichIndex = (pRotation/pAngle) + 1
thisMoveXY = pTrigList[whichIndex]

case whichCommand of
#thrust: pSpeed = min(pSpeed + pThrust, pTopSpeed)
#thrustBack: pSpeed = max(pSpeed - pThrust, ¬
pTopSpeed * - 0.5)
#brake:
if pSpeed > 0 then pSpeed = max(pSpeed - ¬
pBrakePower,0)
else if pSpeed < 0 then pSpeed = min(pSpeed ¬
+ pBrakePower, 0)
#coast:
if pSpeed > 0 then pSpeed = max(0, ¬
pSpeed - pDrag)
else if pSpeed < 0 then pSpeed = min(0, ¬
pSpeed + pDrag)
end case

-- apply speed to direction vector
thisMove = thisMoveXY * pSpeed
tempDeltaLoc = pDeltaLoc + thisMove
newLoc = pLoc + tempDeltaLoc

-- check new location & move sprite
if inside(newLoc, pConstraintRect) then
pDeltaLoc = tempDeltaLoc
pSprite.loc = newLoc

end if
end moveSprite

```

I think you'll find the motion to be more realistic, though it does not account for traction. So no matter how fast you're moving, your turns will be perfect, without the slippage that would naturally occur. That sort of calculation is much more the sort of thing that Raman Pfaff would tackle in his Physics/Lingo articles. If you're interested in that, I'd suggest you check out DOUG's Using Director archives for Raman's great articles.

Patrick McClellan is Director Online's co-founder. Pat is Vice President, Managing Director for Jack Morton Worldwide, a global experiential marketing company. He is responsible for the San Francisco office, which helps major technology clients to develop marketing communications programs to reach enterprise and consumer audiences.