Muse Behavior to JSON

Muse
,
1

I’m interested in converting my Muse behavior tree into a straightforward JSON format. I’d like to explore two approaches:

  1. Is it feasible to transform the Muse Behavior tree into a basic JSON representation? I’m primarily interested in capturing the structure of the nodes and the associated blackboard keys.
  2. Can we reverse this process and convert the JSON representation back into a functional Muse behavior tree within the codebase?
2

Hi @varun_convai,

The ScriptableAsset for the graph currently save its internals as a JSON using Newtonsoft, so if you look inside the .asset you’ll find a json interpretation. That said, the output isn’t very clear at the moment and we could look into tidying it somewhat to allow users modify it on their own :slight_smile:

Please note it will contain 2 JSONs, one for the editor time authoring structure and another for the runtime subasset, that should be leaner and more optimised for execution.

3

Thank you @ShaneeNishry for your detailed response. I have a few follow-up queries:

  1. Can I dynamically generate a new behavior tree solely through code, bypassing the GUI?
  2. Specifically, I’m aiming to programmatically extract a behavior tree created in the GUI, apply modifications (such as adding a node), and then implement this modified tree. Is this feasible entirely through code, and if so, could you guide me on how to accomplish this?
4

Hi Varun,

In theory, yes, but right now the BehaviorAuthoringGraph and Graph.GraphAsset classes are internal for the moment to avoid encouraging people do things that we might break the APIs for.

We could look into exposing them, but I don’t want to guarantee not breaking people using them while we’re still experimental. If you want, you can look into the APIs in the GraphAsset under the Graph namespace.

Once you have your graph ready, you’ll need to use the GraphAssetProcessor to create the runtime version of the graph.

Alternatively, you could just create the Runtime graph, which is just a series of Unity.Muse.Behavior::Node(s) and those that inherit from it.

Can you share more about your use case so that we can consider adding it?

5

Thank you @ShaneeNishry for your prompt and helpful responses. Here’s a breakdown of my use case and a request for additional clarification:

  1. Primary Use Case: For the current phase, my focus is on using Muse’s behavior tree functionality and GUI, while not incorporating its Generative AI features. My aim is to leverage the behavior trees solely.
  2. Behavior Tree Creation: Option to create behavior trees either via the UI or by defining a JSON structure. This structure would be simple parent-child relationships, node parameters (blackboard keys), and node types.
  3. Dynamic Modification Requirement: Ability to modify the behavior tree on-the-fly through code. This includes:
  • Adding new nodes.
  • Deleting existing nodes.
  • Altering the entire behavior tree structure.
  1. Agent Adaptation: Ensure that the agent adapts to these programmatic changes in real time.

Request for Clarification:

  • Could you provide more details on implementing this dynamic modification using the current package?
  • Specifically, regarding the suggestion to create a Runtime graph composed of Unity.Muse.Behavior::Node(s) and its derivatives, how would this approach facilitate the real-time, code-based modifications I require?

Your guidance on these points would be greatly appreciated.

6

Hi @varun_convai,

Let’s start with a warning: This is a rabbit hole I can’t recommend for you to pursue right now. Ideally we should expose certain APIs for you to do what you’re hoping to achieve, but most of the time is away now until the new year and this request isn’t prioritised.

Just for clarity: Right now, with the package unmodified, you can’t do what you want to do because most of the APIs are internal. To achieve what you want you’ll need to copy the package locally and expose the internals, either by making them public or adding InternalsVisibleTo in the AssemblyInfo.cs.

This gives you 2 options:

  1. (The easier way) Use the authoring BehaviorAuthoringGraph which has pretty clear APIs on how to modify it, then use the GraphAssetProcessor to generate the runtime graph asset, or
  2. Generate the runtime graph directly using the Nodes themselves.

To give you some hints on the runtime option, if you look at the subasset, which is the runtime graph, the inspector will show you the tree somewhat like this:
image

image
image392×889 28.5 KB

The BehaviorGraphAgent needs a BehaviorGraph, which includes your node hierarchy. You’ll need to look into the file and see which parts you’ll need to create. Generally the Blackboard and at least one BehaviorGraphModule, which holds the actual graph hierarchy.

To create the hierarchy which goes into the BehaviorGraphModule you’ll be using the individual Nodes, such as Start, Sequence and your actions, as reflected in the inspector of the runtime graph. The Node has APIs to add children, parents, etc. You can look into the GraphAssetProcessor to see how it generates the hierarchy.

I hope this helps, even if just to stop you from jumping down the rabbit hole.

Can you give more detail on why do you need to change the graphs at runtime? What experience are you trying to achieve with this?

Thanks! :slight_smile: