Game/AI

Jeff,

great presentation!

Question about the squad communication. The dialogue examples all represent after-the-fact statements ("I need reinforcements", "What's your status?" + "I'm in pain", "Do you see him?" + "Negative").

How would/did you deal with timing sensitive squad communication, for example: "Cover me, so I can flank him" + "Roger, I'll cover you!", where the flanking grunt shouldn't move until the support fire grunt has answered and actually started firing.

William

thanks william! well, to handle things like "cover me" + "roger" we generally queued a sequence of lines up when the squad behavior activates, and abort the sequence if anything goes awry (e.g. a participant dies, or the squad behavior exits). Sometimes we queue up new dialogue at the time of cancelling the old dialogue (e.g. "He's rushing you! Get out of there!"). does this answer your question?

Hey Jeff, I really enjoyed your presentation! I've been reading your other papers as well, and I had a question about your implementation.

In "Symbolic Representations of Game World State: Toward Real-Time Planning in Games", you say that you used a hash table to look up actions. The table was indexed by effect, so I guess you would use it to look up all of the actions that affected the "TargetIsDead" value, for example.

It seems to me that after all of the preconditions and effects are laid out for the actions, and a list of actions and goals is given to an AI entity, it's possible to build a graph at pipeline time of the connections between actions and goals.

Would building this graph structure be preferable to using a hash table? Or would it restrict you in some way?

right Euan, you can think of the plan space as a graph -- but one that allows cycles, since the same action may be re-used multiple times in a plan. The disadvantage of _explicitly_ representing the planspace as a graph is that this prevents the possibility of dynamic changes. For example, agents learning new actions, or learning new preconditions or effects of existing actions.

We did not have any learning in FEAR, but we did allow actions to add preconditions dynamically. This was useful for handling designer-specified dependencies between objects. For example, an agent who wants to take cover discovers that some cover node depends on first flipping over a table before the cover becomes valid. During plan formulation, if a dependency like this is discovered, we can add a precondition to the action that uses the cover node which leads the agent to continue planning until he finds a plan that handles the dependency of flipping the table before using the cover node.

In my current work on unified planning for actions and navigation, I've found additional situations where modifying preconditions dynamically is useful. There are multiple possible preconditions for getting to some navmesh polygon - one for each neighboring poly. One way to handle this is to specify different preconditions for the same action within different nodes of the plan's search tree.

so anyway, building an explicit graph is possible, but my opinion is that keeping a looser data structure leaves you more flexibility.

First, thanks for nice presentation! I enjoyed it a lot, even I was not able attend the actual presentation at GDC. Though, I was told it was very good and I bet a lot of excited people left the conference room itching to (re)write their AI code :) I've been following the GOAP stuff a lot lately and your presentation filled a lot of gaps.

One of the first things that I was wondering after reading the first GOAP paper about a year ago was that would it be possible to unify the pathfinding and action planning. It seems I'm not alone with that idea.

My idea was to represent the environment a bit more higher level than the path finder data usually does. Basically in the same level of detai l as a human would when giving directions to a stranger in a building. More or less rooms and portals.

The rest of navigation would be handled using dynamic local search a bit like the recent James Kuffner's motion planning stuff. That would pretty much reduce the states of the agent to just one :)

So far that has been just daydreaming, I'm just starting on my first planner implementation and doing research.

Another simple planner which reminded me a lot about the GOAP was Pattie Maes behavioral network, which I discovered recently (even it is quite old paper). There seems to be very little references to that even it sound very interesting dynamic approach to planning. Maybe there is some obvious limitation to it I just cannot foresee.

We have system at work which involves preconditions, and I have noticed that it is quite a task to keep track of the states especially when working in a team where a lot of people creating changes. Is that just something where you have to be very careful when creating the states and preconditions for a planner in general or is that a problem at all?

Thanks Jeff, that makes perfect sense!