AI Planner

This was just fixed in the latest release (preview.7)

 

This is likely due to an aging entites, which the extant version of the planner depends on. This will change in the future, so that entities can be updated more frequently than releases of the planner. Also, we currently aren't developing on 2019.3 internally yet.

 

We did a small update, which was just posted, but the update to Entities 30+ will come with our next larger release because it required a re-working of the visualizer to support the changes that came with that version.

At the time I posted that original comment I thought our next release was "right around the corner", but that turned out to be the many months of refactoring that we have done to improve the planner overall.

 

There is a bug in the extant version that does not create multiple worlds, so that many agents can run with the same domain definition. This has been completely refactored in our next larger release we are hoping to get out in August.

 

@JustinLarrabee and @zephyr831125, our intention was not to create class-based polymorphism where boxing and managed allocations normally occur. What you are currently looking at has been refactored in our next larger release (i.e. ~August), but the templates remain. This allows us to prevent boxing by referencing specific interfaces with constraints like 'struct'. It also makes the planner easier to extend with custom domains (e.g. deterministic or non-trait based).

 

What is compiled in the assembly is a model that is used to describe your world (type of resources, state of objects...) and how it can evolve. Even if your world and objects are generated it's based on rules and predefined components, so no issue to use the Planner!

 

The package does not yet support 2019.3. You'll find that even if you work around the auto reference issue, there are also errors with the versions of burst (preview.8) and entities (preview.30) we depend on, when using 2019.3. We're updating our dependencies in the next release (projected later this month), with better support for 2019.3 coming as well later this year.

 

So looking at your error trace, what stands out to me is

DomainDef.DomainDefUpdateSystem.StateEquals (Unity.Entities.Entity lhsStateEntity, Unity.Entities.Entity rhsStateEntity) (at Assets/AI.Planner/Generated/DomainDef/DomainDef.cs:171)

Is this line (171 in DomainDef.cs) accessing a buffer of type DomainObjectReference through the EntityManager? If so, did you set up your initial state on your agent script? The buffer is added to the state entity on the initial state creation.

 

Can you post a screenshot of your agent inspector with the initial state?

 

The current version only supports 2019.1. Our next release will be compatible with 2019.2. We're planning to release the next version by the end of the month.

 

I'm told that this should be available towards the end of next week. Most likely this will come on Unity's YouTube channel, so check there.

 

Hello, everyone! Today we are releasing our latest update to the Unity AI Planner, version 0.1.1-preview. With that, we're going to start a new forum thread. Please join us over at: https://forum.unity.com/threads/ai-planner-v0-1-1-preview-release.736763/

 

I cloned your project and the Navigate action was missing, maybe you forgot to commit the file?
Otherwise it seems correctly configured, I added a Navigate action to test your domain and it worked. I sent you a PR if you want to take a look.

 

Thanks. We have a bug logged for that already and will address it in a future release.

 

This is usually due to a compile error. Try removing PLANNER_DOMAINS_GENERATED and PLANNER_ACTIONS_GENERATED from your build settings defines and then re-run Build Assemblies from the AI menu.

 

Yes. The planner will continue to plan until the plan is complete. State terminations can close off nodes from further expansion. We'll be introducing an option soon to limit plan depth or possible plan nodes.

 

We're aware of this issue and will need to provide better validation towards these sorts of issues prior to a full release.

 

Otto will still run, but likely die at some point because the state termination of death means that no reward will continue to be accrued on that branch of the plan. Without that state termination the plan may think that Otto can continue to consume, work, and sleep even after death.

A plan is complete when all nodes are either terminal or "complete" in the sense that there are no further actions that can be taken. In the case of Otto the plan is never complete because there is no "goal state". Otto simply plans and replans in order to stay alive.

So, state terminations can either be seen as goal states where a reward could be given or penalty states where there should likely be a large cost to reaching it (e.g. death). Currently, the heuristic is what would dole out that reward or cost depending on the state.

 

What changes have you made to the demo?

 

There are quite a few things going on here:

1. There is a missing action reference in the Mu plan that seems to have gotten deleted.
2. The actions you have are missing references to a trait that no longer seems to exist.
3. All the custom code has been deleted, but the Custom directory still exists, which means it is an empty DLL and won't actually compile
4. With the remaining actions, the preconditions are still referring to traits that either no longer exist or no longer are listed for the parameters you have.

My suggestion is to fork and tweak the existing Otto project or to try building something from the ground up. At the very least, I'd say reduce your actions to a single action in the Mu plan definition and get that working. Start with something simple that you can verify and then expand.

What you've uncovered with your exploration is that there are quite a lot of ways to break the planner and not much validation of the data in definition files at the UI layer. There also isn't much in the way of good error messages to help you diagnose what is wrong. We'll get better on this over time as we stabilize the workflow.

 

It's not rude at all! Your question is actually very insightful and shows that we have not yet communicated the benefits of our chosen direction. Hopefully, I can shine some light on that topic today.

The short answer to your question is that our system handles a broader class of decision problems (with or without goals; deterministic or nondeterministic) while the algorithm we use scales better to larger problems (similar to MCTS than to GOAP/HTNs).

Now for the long answer:

As a motivation for our chosen direction, consider the comparison to goal-oriented action planning (GOAP). In GOAP, a user provides one or more goal criteria to fulfill, from which a finite-length plan is returned. For many games/problems, this is enough. But what about games where an agent must make decisions indefinitely (Sims/Otto) or has a less concrete goal (maximize score)? It's not particularly intuitive how a user could extend a GOAP framework to handle these cases. Luckily, finite, goal-driven decision-making problems are simply a subset of a larger class of decision-making problems our package can solve. If your particular application uses goals, you can support them as a detail of modeling your decision-problem by adding state termination criteria (i.e. when has a goal been achieved or failed), adjusting the costs/rewards (add rewards for achieving a goal state, for example), and implementing a custom heuristic (which, in a way, estimates how close to a goal a given state is). But if your application does not have concrete goals, you don't have to specify any. It's flexible.

Another advantage to our approach is the ability to support non-deterministic domains. In many planning frameworks---including GOAP---the results of taking an action are deterministic, i.e. there is only one outcome. We support probabilistic outcomes, which allow the decision-making process to consider the risks and rewards of an uncertain outcome. Perhaps an agent can only attack an opponent with only a 30% chance of success. Should it commit to the attack or flee? Our tool can make that judgment, which we believe will make for smarter, more believable AI.

As a final point on the problem representation, our system solves exactly the same class of problems as deep reinforcement learning (see: ML-Agents), which means we have a common foundation for mixing the two in various ways. We have nothing to share publicly on this front, but stay tuned!

Now, from an algorithmic standpoint, our approach is an anytime algorithm, meaning it iteratively improves the solution to the decision-making problem given more time. This is a very handy quality for a planner to possess, particularly in very large domains, where a complete, optimal solution to a problem may be intractable to compute at runtime. Instead, we can focus on returning high-quality approximate solutions on demand, while also developing better support for scheduling runtime computation distributed over multiple frames in background worker threads.

Lastly, on the point of hierarchical methods (e.g. HTNs), we've been thinking quite a bit on how to best support decision-making at various levels of abstraction. In HTNs, high-level tasks are decomposed into lower-level tasks and actions, for example. Such a hierarchy is incredibly useful, as it can constrain the problems to be solved at lower levels, making them more tractable to solve. But this isn't the only hierarchy of decision-making you'll find in games. It's quite common to see two or more distinct approaches layered together, be it a rule-based system sitting over a finite-state machine or a high-level activity planner that triggers pathfinding and/or animation systems. In fact, with a little work, you could use our planner to trigger operational actions that set up, solve, and execute plans for a sub-task. We don't yet have a demo that uses our planner at multiple levels of decision-making, but in both Otto and our Overcooked demos, the operational actions use the NavMeshAgent, which is simply a planner/agent controller for pathfinding (a different problem with a different representation, but constrained by high-level decisions).

So, what are our thoughts on this front? It would be myopic to support hierarchical planning only with our planning system and our trait-based representation. Our larger group at Unity is creating a suite of decision-making tools. Our goal is to make such tools interoperable where possible, as we anticipate users wanting to mix and layer them. We also want these tools to work with a variety of problem representations (trait-based, pathfinding, user-specified, etc). As a consequence, mixing these tools may require bridging problems with very different representations, such as in moving from high-level trait-based decision-making to low-level pathfinding. At the very least, we want these considerations to be made explicit, which will help guide the users on how to implement successful hierarchical decision-making systems. More practically, we might add supporting scaffolding for using these tools and representations together. We've already been discussing how to better support navigation decisions in our trait-based language; we may also consider tools that automatically set up calls to, say, the NavMeshAgent as a convenience to the user. This is likely a direction a year or two out in our overall vision, but with enough user demand, it could be moved up in priority.

I hope that answers your question!

 

Yes, there was a known memory leak at release (see the release thread). The issue turned out to be on the DOTS side, and has since been fixed.

 

No, that will come with a future release.