AI Planner - v0.2-preview released

Yes the Planner is using Jobs internally (and burst) and can run on multiple frames, you can give a budget for the search with different settings (time, max plan size...)

 

Yes, all of the planning occurs within jobs. The package exposes parameters for adjusting how much search is scheduled at each frame, however the package does not provide an "automatic" load balancer.

 

We're still evaluating if we move the min requirement to 2020.1. Our goal would be to follow as much as possible latest DOTS releases in this case

 

It is in our long term plan to have an AI framework that uses node-based graph tools and having the Planner compatible with that.

 

We moved Traits to ECS ComponentData in our latest version to have an easiest bridge with entity/system.
With the modification to the package release cycle, we're still evaluating when and how we will share the next public version.

 

It is still in our plan but don't expect anything soon. You can also take a look to DOTS Visual Scripting tool that is evolving a lot and could fit with some of your needs.

 

We plan to make operational actions more flexible to allow developers to create their own control flow, so it may not be a built-in option, but it should be possible to do it.

 

Currently the way to do hierarchical planning, is to have multiple plans operating at different timescale, and like you said changing the state of the other plan by modifying the world state (object/traits)

 

I'm going to answer based on my interpretation of your question, but if it is incorrect, please let me know!

My interpretation: "Why do we have a domain language... {as opposed to using data types from game code directly}?"

There are many constraints that would make arbitrary data support difficult to support. For instance, the planning jobs run in the Unity Job System, which only accepts blittable data types, meaning we can't support class types for state data.

Secondly, what is not apparent from the package but is a factor in this decision: the data used to describe the state of the world takes different forms in different contexts. On game objects, it's monobehaviour components On entities in the game scene, it's component data. In the planning simulations, it's packed into buffers in ECS. Each context has a different data access need in order to be correct as well as performant. I feel your pain when it comes to code generation problems (you could argue no one runs into this more than we do), but code generation is actually a very useful solution to this context problem. You author your data/traits once, and we generate the appropriate code for each different context where it might be used.

I'd like to assure you that the pains of the code generation process will be eased as we move forward. Many teams at Unity are increasingly adopting code generation for various purposes, and there are many active discussions about how to make the process both correct and (hopefully) painless for our users. At the moment, I don't have any details on how or when it will improve, but it certainly among our top priorities.

 

I'm going to address some of your points out of order. I hope that's not too confusing!

I suspect this is the core issue. When you alter the traits in your methods, do you set the trait data back on the object? When you pull trait data from an object, you're working with a local copy, as it's a struct/value type. In order for the data to change, you have to reassign it back on the object.

To track the execution of the plan, the controller updates its current state using either the world state (pulls in current data from the objects in the scene) or from the `Next Plan State` (i.e. the predicted state from the last action performed). If your changes to trait data aren't applied, querying the world won't pick up any changes, so it will think it's still at the same state. Using the next plan state "works" because it's pulling the state from the simulated changes, in which the effects are applied. If my suspicions about changing the trait data are correct, this should fix the world state option.

At the very least, the method for the *first* action of the plan should be called. Look into trait assignment first, and hopefully this will be resolved as well. Let us know!

 

There's no method of doing this in the inspector or settings, no. However, this shouldn't require much code to manage multiple coroutines, no? I've not tried it, so maybe I'm underestimating the required work.

 

We are changing our release cycle to line up with other R&D teams to ensure compatibility between packages/dependencies. I don't have a firm date for our next release yet, but it will likely come in August. Pure DOTS support has been deprioritized in favor of hybrid workflows for the time being.

 

Do you have Burst enabled?

Have you considered adding a termination condition for when there are no more seeds available?

 

Ah. Yes, the visualizer is handy for tracking the process of planning, but we have no tooling to track the status of acting. In an older version of the package, actions were effectively coroutines that returned information regarding its status (running, complete, invalid/interrupt). However, the form of such actions was a bit constrained for the wide variety of action implementations people wanted. Shifting to performing actions by invoking user method callbacks unfortunately meant the burden of tracking such execution is now on the users.

Let me see if I understand your question correctly. Are you sharing a plan between multiple agents executing the joint plan? How synchronized should the actions of the various controllers be? I'd imagine if each performed a part of some joint/group action, you'd want each to query for a new world state only after each controller's action has completed (so as to not miss any changes that are still ongoing).

At the moment, our editor tools don't allow you to specify multiple results. That said, the planning process itself does support non-deterministic action outcomes, but if you want to take advantage of that, you'll need to modify code. If you look in the generated action code (same name as your actions asset), the key part you'll want is to add additional StateTransitionInfoPairs<...>, which hold information about which states/actions are connected and by what probabilities (ensure they sum to 1!).

 

Glad to hear it! If you want to discuss your dissertation project sometime, I'd be happy chat!

As for showing previously performed actions, there is not currently a way to do it. The data for prior actions is disposed of once the graph is updated to a new root, pruning out unreachable states. Until we change that logic, I'd recommend logging the actions in your callbacks as they are executed.

 

Exactly, we moved traits in its own package, with a more complex query system (based on ECS) and new authoring tools. It should be available as a standalone package in the future.

 

While updating our package to the latest entities version, we discovered a bug which has required a fix in Unity itself. The issue has since been resolved, however the bugfix is not yet in a publicly released version of Unity (coming in a near-term 2020.2 release; will be backported to 2020.1). Unfortunately, this means it might be several weeks before we can publish a new version of the AI Planner.

 

What you're authoring in the action definitions are the predicted effects, as used by the planning algorithm. It's a model used by the agent to reason about the future. It's not meant to define gameplay directly, as it represents a more condensed version of what actually happens. For example, a simple "Eat" action may involve playing an animation, only resetting hunger at the appropriate frame. It is also common for the predicted effects to not line up with what happens in the game. If an agent decides to go pick up an object but the player steals it first, then it is not appropriate to apply the predicted effects to the game state, as the agent cannot pickup the object. These are two of the primary reasons there is a distinction between the model of the action---which you author as an Action Definition---and the actual execution of the action, which is left to whichever user-provided callback you specify on the DecisionController.

Now, is the distinction made clearly enough in our package/tool? No, I believe we can do a better job here. You are not the first to be tripped up on this point. We're open to suggestions!

 

Hi, @Du-z! I believe I have a pattern that should work for you. First, let me explain why we haven't supported some of the solutions you suggested (just for clarity).

In practice, this can be confusing or error-prone, as we tend to operate on game objects as a whole rather than individual trait components, meaning there's likely a chance of reading/writing to/from the wrong component. We have seen some of our users spawn child objects to hold trait components, though I haven't personally worked with such a structure.

So it seems possible that we could support generic/templated trait types, given that entities supports generic component data with known/registered instances (e.g. MyTrait<int>). However, I don't believe we can operate on entity data without knowing the full type (we can't use MyTrait<>), so I'm not sure where it would be advantageous to support those traits. It might make authoring easier, but we'll have to think a bit further about how that would look.

Alright, here is a pattern you can use for having various needs. I'm trying to stick closely to what you've described. The key, as you identified in your suggestion #2 is to use an enum to define the need type.



From this, you can define a "generic" Need trait, the type of which depends on its NeedType (a property of the trait).



I've also added a value field (NeedValue) and an object reference to define the object that has the need (NeedOwner). To fulfill a need, you mentioned a "needFulfiller", for which I've also created a trait:



You could optionally add a value for how much of the need is satisfied by interacting with the object.

Finally, let's look at an action to handle this interaction, which I've called SatisfyNeed:



This is really just the skeleton for such an action. You don't actually need the first parameter, NeedOwner, but I've included it as an example of how to specify the object possessing the need. What's key is the precondition matching the need with the object that can fulfill that need. That will ensure the plan reasons about the correct interactions between objects fulfilling needs and the needs they fulfill. Hopefully this type of pattern will unblock you! Keep us posted.

 

I'm not sure I understand what you're asking. TraitDefinitions are the assets used to define traits, so you should be able to use the AssetDatabase to find the ones you've created in your project.

 

Not naive! Simply unexpected.

 

Feel free to message me directly!