FluadHTN - The AI Framework (formerly OdaiHTN)

Features

• []Total-order forward decomposition planner.[/]

  []Pre-existing Domain Builder to simplify the design of code-oriented HTN domains.[/]

  []Partial planning.[/]

  []Domain splicing.[/]

  []Domain slots for run-time splicing.[/]

  []Replan only when plans complete/fail or when world state change.[/]

  []Early rejection of replanning that can't succeed.[/]

  []Easy to extend.[/]

  []Uses a Factory interface internally to create and free tables/queues/stacks/objects, allowing for pooling, or other memory management schemes.[/]

  []Decomposition logging, for debugging.[/]

  []No MWSE or OMW dependency, allowing for easy porting between the two.[/]

Concepts

Compound Tasks

High level tasks that have multiple ways of being accomplished. There are primarily two types of compound tasks:

• []Selectors must be able to decompose a single sub-task.[/]

  []Sequencers must be able to decompose all its sub-tasks successfully for itself to have decomposed successfully.[/]

Primitive Tasks

Represent a single step that can be performed. A set of Primitive Tasks is the plan that are ultimately getting out of FluadHTN. Primitive Tasks are comprised:

• []Operators[/]

  []Effects[/]

  []Conditions[/]

  []Executing Conditions.[/]

  Boolean validators that can be used to validate the decomposition of a Compound Task, or the validity of a Primitive Task. Primitive Tasks also have Executing Conditions, which we validate before every update to the primary task's Operator during execution of a plan.

  Executing Conditions

  Special conditions that are evaluated every planner tick; useful for cases where you need to re-evaluate the validity of your conditions after planning and after setting a new task as current task during execution. In the case where the operator returns continue and the condition becomes "invalid", the planner will not automatically know. Using Executing Conditions is one way to ensure that the planner realizes that the task is now invalid. Another way is to put this logic inside the Operator and have it return Failure, which should yield the same result in practice thus triggering a replan.

  Logic operation that a Primitive Task should perform during plan execution. Every time an Operator updates, it returns a status whether it Succeeded, Failed or needs to Continue next tick.

  Credit

  []Pål Trefall for his original C# framework.[/]