| |
|
|
||||
![]() |
||||||
| |
|
|||||
|
Now that
we have a simple movement algorithm and a list of unit collisions, what
else do we need to get decent unit cooperation? Position prediction.
The
most obvious optimization is to avoid recalculating all of your predicted
positions at every frame. A simple rolling list works well (see Figure
5 below); you can roll off the positions that are now in the past and
add a few new positions each frame to keep the prediction envelope at
the same scale. While this optimization doesn't get rid of the start-up
cost of creating a complete set of prediction positions the first time
you move, it does have constant time for the remainder of the movement.
The
next optimization is to create a prediction system that handles both points
and lines. Because our collision determination system already supports
points and lines, it should be easy to add this support to our prediction
system. If a unit is traveling in a straight line, we can designate an
enclosed volume by using the current position, a future position, and
the unit's soft movement radius. However, if the object has a turn radius,
things get a little more complicated. You can try to store the curve as
a function, but that's too costly. Instead, you're better off doing point
sampling to create the right predicted points (see Figure 6 below). In
the end, you really want a system that seamlessly supports both point
and line predictions, using the lines wherever possible to cut down on
the CPU cost.
The last
optimization we'll cover is important and perhaps a little nonintuitive.
If we're going to get this predicted system with as little overhead as
possible, we don't want to duplicate our calculations for every unit by
predicting its position and then doing another calculation to move it.
Thus, the solution is to predict positions accurately, and then use those
positions to move the object. This way, we're only calculating each move
once, so there's no extra cost aside from the aforementioned extra start-up
time.
|
|
|