remembering goals

It's a shame my next book isn't in print yet as it covers this in a lot of detail and it's not something one can explain easily in a few sentences. However, I'll have a go...

An agent's behavior is broken down into a number of goals, say goalSleep, goalWork, goalFight. The agent chooses between goals using a technique of your choice. This is called "action selection" or "goal selection".

Each goal can be satisfied by a "plan", which is a series of connected actions (states). The easiest way of implementing plans is for the programmer to predefine them (instead of the AI formulating them at runtime, which makes the problem orders of magnitude more difficult)in code or in a script. For example, the goal goalSleep would consist of the actions find(Bed), goTo(bed), sleep(bed). Depending on the functionality you desire you may prefer to create several plans for each goal and use yet another selection criterion (or just random choice) for selecting between them.

When a plan is selected (by your goal selection technique)its constituent states are pushed onto a stack. states are popped from this stack in the order they appear in the plan. For example, if the goalSleep goal is activated, the state stack will look like this:

find(Bed) <---top of stack
goTo(bed)
sleep(bed)


Each action is capable of detecting its own success or failure. If successful then the action is removed from the front of the stack and the next action becomes active. If an action detects failure then the agent must "replan". Depending on the situation this can either be done locally (via the state) or the state may prefer to terminate and delegate the flow of control back to goal selection.


Thisis only one way of achieving the behavior you desire. There are several options, and I'm sure other people will comment, but this is the way I'd go about it.

Hope it helps

Awesome! Thank you very much for this explanantion. Your explanation is the first one that doesn't leave me dangling after "just implement a state machine". I've been making games for years, but none that needed anything more than a single state machine. For this game I knew I needed goal, planning and execution stages, but I couldn't figure out how to make them work together: stack! DOH!

I will definately buy your book. When is it due out?

If you want another way, one that is quite useful.

First you have a movegenerator, so say if your doing
sleep

Then you can wake up... and thats all you can do,
When your at work
you can
stop working
or you can work
or you can read the paper
or you can take a break

I would recommend doing that by using arrays of arrays.

For each thing (like taking a break) you defin how "hard" it is to do that.

You then just do A* to find your goal state! just nice eh?
DENC

Awesome! Thank you very much for this explanantion. Your explanation is the first one that doesn't leave me dangling after "just implement a state machine".

Glad I could help. There are quite a few implimentation details I couldn't go into but that's the basic skeleton.

I will definately buy your book. When is it due out?

It should be in print in Sept. The title is "Programming Game AI by Example" (ISBN 1556220782).



PS. Thanks for letting me get a plug for my book in ;)

anon: I checked out the "Reactive Agent Planner" link you gave. Interesting. It's actually quite similar to fup's post, except that RAP does the planning at runtime.

I have a decent goal evaluation and selection system running now implemented by using a set of chained evaluators on an event. I can control how many evaluators run each time the event is fired, so I can control how often the npc "thinks" and can even adjust the number at runtime if needed to allow for more thinking when in proximity of the player. This seems to be throttling the CPU usage well at the moment.

I also know the steps I want to take to fulfill my plan, and have a nice path finding system. The part I need to focus on now is how to encode the plan such that it can easily be changed. The stack looks like a good choice on the surface, but I need to think through the other details (like animation state machine interace, steering behavior, etc.)

The plan steps itself being pre-defined isn't a problem because it can be interrupted at any time to provide emergent gameplay for unforeseen circumstances. What I'm wondering is whether the plan will be interrupted so often as to cause it to take a lot of overhead to keep switching. Again, the stack seems appealing because it could recheck the next step before continuing after an interuption, and add more steps backwards to get from the new situation to connect to the top of the stack. Hmmm... lots of food for thought.

Thanks everybody for your help so far.