Goal objects share a lot of similarities with the State class. They have a
method for handling messages just like
State, and Activate, Process, and
Terminate methods, which share similarities with the Enter, Execute, and
Exit methods of State.
Activate method contains initialization logic and represents the
planning phase of the goal. Unlike the
State::Enter method though, which
is only called once when a state first becomes current, a
Goal is able to call
Activate method any number of times to replan if the situation
Process, which is executed each update step, returns an enumerated
value indicating the status of the goal. This can be one of four values:
inactive: The goal is waiting to be activated.
active: The goal has been activated and will be processed each
completed: The goal has completed and will be removed on the next
failed: The goal has failed and will either replan or be removed on
the next update.
Terminate method undertakes any necessary tidying up before a goal is
exited and is called just before a goal is destroyed.
In practice, a chunk of the logic implemented by composite goals is
common to all composites and can be abstracted out into a
class, which all concrete composite goals can inherit from, resulting in the
final design fleshed out in Figure 9.7.
The UML diagrams do an adequate job of describing the
Goal class hier-
archy so I won’t waste paper listing their declarations, but I think it will be
helpful if I list the source for a couple of the
384 | Chapter 9