To get through the sliding door, the bot must follow these steps
1. Get the list of buttons that open the door (b1 and b2).
2. From the list, select the closest navigable button (b1).
3. Plan and follow a path to button b1 (the button will trigger, opening
4. Plan and follow a path to node A.
5. Traverse the edge AB.
Goal_NegotiateDoor addresses each of these steps in its Activate method,
adding the subgoals necessary to complete the task. The listing will help
m_iStatus = active;
//if this goal is reactivated then there may be some existing subgoals that
//must be removed
//get the position of the closest navigable switch
Vector2D posSw = m_pOwner->GetWorld()->GetPosOfClosestSwitch(m_pOwner->Pos(),
//because goals are *pushed* onto the front of the subgoal list they must
//be added in reverse order.
//first, the goal to traverse the edge that passes through the door
AddSubgoal(new Goal_TraverseEdge(m_pOwner, m_PathEdge));
//next, the goal that will move the bot to the beginning of the edge that
//passes through the door
AddSubgoal(new Goal_MoveToPosition(m_pOwner, m_PathEdge.GetSource()));
//finally, the goal that will direct the bot to the location of the switch
AddSubgoal(new Goal_MoveToPosition(m_pOwner, posSw));
You can see Raven’s bots navigating doors by running Raven and loading
the map Raven_DM1_With_Doors.map. It uses a sparse navgraph so you
can clearly see how the NegotiateDoor goal works.
Real-time strategy games have grown in complexity tremendously over the
last few years. Not only has the number of NPCs a player is able to control
increased, but also the number of commands he can instruct the NPCs to
follow. This has necessitated several improvements to the user interface,
one being the ability for a player to queue an NPC’s orders — something
that has become known as command queuing (or build queuing).
410 | Chapter 9