When my planner had finished, it produced the following plan:
[ go([4, 4], [5, 6]), grab(key(1), [5, 6]), go([5, 6], [8, 4]), use(key(1)) ]meaning ``go from
[4,4] to [5,6]; grab key 1; go from
[5,6] to [8,4]; use key 1''. You will see that this plan
is incomplete; it doesn't say anything about how to go between two
points. The reason for this is that my planner is not very efficient
(though better than blind search), and it runs slowly if it has to
consider too many details. So I have treated ``go'' as a primitive
action: as far as the planner is concerned, one can always go between
any two points. This is called planning at a level of abstraction:
making a plan whilst ignoring some of the details.
Before PopBeast can obey this plan, it must be fleshed out with the actual
moves. To do this, PopBeast runs through, looking at all the gos. For
each one, it plots a short path between the two points, and then
converts that into a sequence of lefts, rights, forwards, and backs. It
could be that no such path exists, if (say) there is a wall between the
points. In that case, the path-plotter would have to tell the planner to
make a new plan. In my example, paths do exist, and I'll ignore
situations where they don't.