Tools

Online Case-based planning (Part 2)

Posted by Ahmad Atta on October 22, 2009

Plan Representation Language

1. A behavior has two main parts:

The declarative part has the purpose of providing information to the system about the intended use of the behavior. The declarative part of a behavior consists of three parts: a goal, a set of preconditions , a set of alive conditions.

The procedural part contains the generation module to generate behaviors. The procedural part of a behavior consists of 1) Executable code (basic actions) and 2) Subgoal (that need to be further expanded).

2. The state of a behavior can be:

pending (when it still has not started execution)

executing

succeeded

failed.

3. When a goal still doesn’t have an assigned behavior, we say that the goal is open.

4. A goal that has a behavior assigned and where the behavior has failed is also considered to be open.

5. Open goals can be either ready or waiting.

Run-Time Plan Expansion and Execution

1- A partial plan tree in our framework is represented as a tree consisting of two types of nodes: goals and behaviors. In the remainder of this paper we will refer to the partial plan tree simply as the “plan”.

2- Initially, the plan consists of a single goal: “win the game”.

3- The plan expansion module asks the behavior generation module to generate a behavior for that goal.

4- That behavior might have several subgoals, for which the plan expansion module will again ask the behavior module to generate a behavior for it.

5- that behavior is sent to the behavior adaptation module, and then inserted in the current plan, marked as pending.

6- The plan execution module has two main functionalities: check for basic actions that can be sent to the game engine and check the status of plans that are in execution:

7- For each pending behavior, the execution module evaluates the preconditions, and as soon as they are met, the behavior starts its execution.

8- Basic actions that are ready and with all its preconditions satisfied are sent to WARGUS to be executed. If the preconditions are not satisfied, the behavior is sent back to the adaptation module to see if the plan can be repaired. If it cannot, then the behavior is marked as failed.

9- Whenever a basic action succeeds or fails, the execution module updates the status of the behavior that contained it. When a basic action fails, the behavior is marked as failed, and thus its corresponding goal is open again.

10- If the alive conditions of an executing behavior are not satisfied, the behavior is marked as failed. If the success conditions of a behavior are satisfied, the behavior is marked as succeeded.

11- Finally, if a behavior is about to be executed and the current game state has changed since the time the behavior generation module generated it, the behavior is handed back to the plan adaptation module to make sure that the plan is adequate for the current game state.

On-Line Case-Based Plan Adaptation

Plans are composed of four basic types of elements:

Actions, which are the basic actions that can be executed.

Parallel plans which consist of component plans which can be executed in parallel.

Sequential plans which consist of component plans which need to be executed in sequence.

Sub-goal plans requiring further expansion.

We can deduce dependencies between different plans using their preconditions and success conditions. We specifically consider only plans which are completely expanded and do not contain a sub- goal which further needs to be expanded. We generate a plan dependency graph using the preconditions and success conditions of the actions. This plan dependency graph informs the plan adaptation process.

Plan Dependency Graph Generation

1- Each action has preconditions and success conditions, and each goal has only a set of success conditions.

2- Further, every plan has a root node that is always a subgoal.

3- The plan dependency graph generation, begins by

Taking the success conditions of the root of the plan.

Finding out which actions in the plan contribute to the achievement of these success conditions.

These actions are called direct sub-plans for the sub-goal.

4- All direct sub-plans are added to the plan dependency graph. Then the plan dependency graph generator analyzes the preconditions of each of these direct sub-plans.

5- Let B1 be an action in the plan which contributes to satisfying the preconditions of a direct sub-plan D1. Then, it adds B1 to the plan dependency graph and forms a directed edge from B1 to D1 . This directed edge can be considered as a dependency between B1 and D1 .

6- This is done for each of the direct sub-plans. Further this is repeated for each of the actions which are added to the graph. This process results in the formation of a plan dependency graph with directed edges between actions representing that one action contributes to the achievement of the preconditions of another action.

precondition-success condition matcher (ps-matcher).

In our system, we have developed a rule-based ps-matcher that incorporates a collection of rules for the appropriate condition matching. For example, our system has six different conditions which test the existence of units or unit types.

In some cases it is not clear whether a relation exists or not. However it is necessary for our system to capture all of the dependencies, even if some non- existing dependencies are included. Clearly, executing extra actions is better than missing some needed actions.

The plan adaptation after the creation of the plan dependency graph has two sub-processes: elimination of unnecessary actions, and insertion of extra actions.