Mark starts with a plug for Artificial Intelligence: a Modern Approach, by Stuart Russell and Peter Norvig
Pretexting that this is a new topic that he has been studying, Mark promised that this talk has nothing to do with Drools. Wow! It definitely deserves to be noted 😉
The room is either exhausted by the fast-paced agenda we have been going through for the last 2 days, or less than half the room is familiar with technical concepts from this goal-oriented programing.
Mark is using a goal of yummy food to get our attention, and explain the dynamics of goals in prolog terms. It boils down to searching for that goal, for which there are many algorithms to get to the solution, with variations in terms of depth-first versus breath-first, potentially minimizing a cost function to avoid unnecessary search space exploration, or performing local search, or leveraging constraint satisfaction solvers.
STRIPS Planning example:
Hungry lady has 2 paths to satisfy her hunger. She could either call a pizza delivery service or bake a pie. If she has a phone and no recipe, the only solution would be the pizza. When the pizza arrives, she would eat it and no be hungry any more (which we need to tell the system). Similarly if she has a recipe and no phone then she would rather bake a pie. But if she has both, both options are still on the table. Then you can string more plans together. To order a pizza, she needs money… If she does not have money, she needs to go to the bank, etc.
Mark contrasts different planners. The core of the talk is the objective of making the search for a plan efficient. Again, the slides provide many step by step use cases and pages of algorithms and research references.
The FireGrid application designed to evaluate rescue plans and avoid disasters like the Mont Blanc tunnel fire. It relies on generation of plans and Case-Based Training.
Games are ideal use cases for such technologies. Finite State Machines feel quite mechanical, predictable, repetitive and ultimately boring. Using Goal-oriented programing allows the introduction of more complex behavior WHILE the implementation remain under control, no combinatorial explosion of cases to handle explicitly. For each character, the set of available actions drives the actual behavior for the small set of goals (Patrol and KillEnemy) allowing for much reuse. The guard in a first-person shooter game would evaluate what to do based on those 2 goals given the available actions as well as the context surrounding him. An assassin would share the same goals but have different available actions that make him more nimble and aggressive. The rat may only be “programmed” to patrol.
The cool thing for a developer is the declarative nature of the approach!
Mark lived up to the set expectation of making it a product pitch. We appreciate that.
Check the abstract here.
Learn more about Decision management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
