Gamasutra: The Art & Business of Making Gamesspacer
Coordinated Unit Movement
View All     RSS
November 13, 2018
arrowPress Releases
November 13, 2018
Games Press
View All     RSS
  • Editor-In-Chief:
    Kris Graft
  • Editor:
    Alex Wawro
  • Contributors:
    Chris Kerr
    Alissa McAloon
    Emma Kidwell
    Bryant Francis
    Katherine Cross
  • Advertising:
    Libby Kruse






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Coordinated Unit Movement


January 22, 1999 Article Start Previous Page 3 of 9 Next
 

Simple Movement Algorithm

Let's start with some pseudo code for a simple, state-based movement algorithm (Listing 1). While this algorithm doesn't do much more than follow a path and decide to find a new path when a collision is found, it does work equally well for both 2D and 3D games. We'll start in a given state and iterate until we can find a waypoint to move towards. Once we find that point, we break out of the loop and do the movement. There are three states: WaitingForPath, ReachedGoal, and IncrementWaypoint. The movement state for a unit is preserved across game updates in order to allow us to set future events, such as the "automatic" waypoint increment on a future game update. By preserving a unit's movement state, we lessen the chance that a unit will make a decision on the next game update that counters a decision made during the current update. This is the first of several planning steps that we'll introduce.

We assume that we'll be given a path to follow and that the path is accurate and viable (meaning, no collisions) at the time it was given to us. Because most strategy games have relatively large maps, a unit may take several minutes to get all the way across the map. During this time, the map can change in ways that can invalidate the path. So, we do a simple collision check during the state loop. At this point, if we find a collision, we'll just repath. Later on, we'll cover several ways to avoid repathing.

Listing 1. Movement Algorithm in Pseudocode.

Top of movement state loop:
{
If we're in IncrementWaypoint state:
Increment our waypoint.
If we're on a patrol
Grab the next waypoint as defined by the patrol direction.
Set state to WaitingForPath.
Else
If we're out of waypoints
Set state to ReachedGoal.
Else
Set state to WaitingForPath.
If we're in ReachedGoal state:
Make the appropriate notifications (if any).
We're done. Stop the walking animation. Exit function.
If we're in WaitingForPath state:
Find a path and save it.
If we could not find one
We've failed. Exit function.
Calculate the direction we need to head in to get to our desired waypoint.
Modify that direction by any limitations such as turn radius.
Using that new direction, calculate where we'll end up after this move.
If that new position causes a collision
Set state to WaitingForPath.
Jump back to the top of the loop.
Using the current and future position:
If we're closer to the waypoint before moving
Set state to IncrementWaypoint
Go back to top of loop.
If we're going to jump over the waypoint during this move
Set state to IncrementWaypoint.
Break out of loop.
}
Set the accelerations accordingly.
Do the actual move.
Set or update any animation hooks that we might have.
Update our predicted positions


Article Start Previous Page 3 of 9 Next

Related Jobs

Game Changer
Game Changer — Remote Work From Anywhere, Kansas, United States
[11.13.18]

Mobile Game Programmer
Plarium Michigan Studio LP
Plarium Michigan Studio LP — Portage, Michigan, United States
[11.12.18]

Senior Game Developer
Monomi Park
Monomi Park — San Mateo, California, United States
[11.09.18]

Senior Game Engineer
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[11.08.18]

Mid/Senior Multiplayer Programmer





Loading Comments

loader image