General feedback

Muse
,
1

First of all, I think you guys are doing a great job with this tool. Unity has lacked something like this from a long time and what you have now plus all the things that will come, like Utility Theory nodes, will make it a very complete set to program complex behaviors. I also love the design and the UI, very nice, very user-friendly.
I got some questions, some suggestions, some bugs to report, and random feedback:

QUESTIONS

  1. Are you going to introduce a system to directly map the variables in the blackboard to variables in a script, similar to what Behavior Designer has? Right now I’m just using properties in a script to directly map the variables to and from the blackboard, to have everything synchronized, which is not a bad way to do it, but I just wanted to ask if there’s going to be another way to do it in the future.
  2. Are you planning to have a more straightforward way to call events in the graph from outside, from a script? Right now the only info I found about this is Event Channels in Muse Behavior but it seems rather cumbersome (though I may be confused). I’m thinking on something in the line of “behaviorGraphAgent.SendEvent(“Command”, “GoToDestination”);”, for example.
  3. We lack basic documentation. Plans on this?
  4. Approximate release date, if possible, of version 1.0?

SUGGESTIONS

  • It’s very hard right now to have the basic info of certain things of this package. I would recommend a common Q&A post for everyone with the most important things people have asked that are points of confusion, like the price of the tool and its use without the Muse subscription, the philosophy of this kind of approach to behavior trees in relation to others, compatibility, roadmap, etc.
  • A node to Print/Debug/Log a value from the blackboard, or a string you write.
  • Wander node, similar to Patrol node, but with random positions, with configurable distances between them, wait times between movement, etc.
  • Add Transform as variable type in the blackboard.
  • These are being worked on, but I mention it to express interest: aborts (whatever the shape it takes) and utility theory nodes.
  • A Find function in the graph in order to know in which nodes a variable is being used.

BUGS

  • Heads up with this, that due to an error in a script unrelated to the tree, where I had to reload domain several times, I don’t know what happen but, without me doing anything in the editor itself, it ended up erasing my entire behavior graph. Not the file, but inside the graph, it was empty, no nodes, no blackboard variables. I wish I could tell you how to replicate the error but I can’t now. I just wanted to share this problem even if I don’t know the source, because the fact that the entire graph can be erased somehow, it’s serious.
  • I got a simple Set Variable Value node where I set Vector3.zero to a Vector3 variable of the blackboard and on play it gives me the error “Found mismatched field type for Value in SetVariableValueAction. Expected Vector3, but found Object.” And I am just passing 0, 0, 0. This not only happens with a Vector3 but with other types of variables aswell, even when I pass them a new value with the correct type.

RANDOM FEEDBACK

  • I like very much the fact that you can specify where the agent is in your configuration. Other tools didn’t contemplate the possibility that the agent could be in an object different than that of the behavior tree.
2

Hi there! Thank you for the many questions and feedback. I’ll reply in-line.

I feel there would be much value in having a solution for this, so I’ll see where we might fit it into our roadmap. Thanks for the suggestion!

Yes, retrieving the event channel requires a bit of boilerplate (shown below) that we could package up differently. We may add some extension methods to expose a friendlier API on the agent class, as you suggested.

var agent = GetComponent<BehaviorGraphAgent>();
if (agent.Blackboard.TryGetVariable("Enemy Spotted", out BlackboardVariable<EnemySpotted> channelVariable))
{
    var enemySpottedChannel = channelVariable.Value;
    enemySpottedChannel.SendEventMessage(Enemy, Position);
}

It’s coming. We’re short on technical writing support, but we hope to ship at least the basics before too long.

We will launch the 1.0 once we feel it is production ready. At the moment, we’re finalizing the 1.0 feature set list, taking requests and feedback from users, and weeding out bugs where they crop up.

Not a bad idea! There will be a blog post about the tool coming soon. I’ll see if we can time a Q&A post here around the same time. Just to clarify, could you expand on “the philosophy of this kind of approach to behavior trees in relation to others”? Do you mean why we’ve decided to implement event-driven behavior trees rather than the traditional form that runs from the root node on each evaluation? Something else?

That’d be an easy include for us. I’ll throw together a quick PR for one. Here’s some code you can use today:

using System;
using UnityEngine;
using Unity.Muse.Behavior;
using Action = Unity.Muse.Behavior.Action;

[Serializable]
[NodeDescription(name: "Log Variable", story: "Log [variable]", category: "Action", id: "b95551d408d852c7e54ce84d1369f56a")]
public class LogVariable : Action
{
    public BlackboardVariable Variable;

    protected override Status OnStart()
    {
        Debug.Log(Variable?.ObjectValue);
        return Status.Success;
    }
}

We could, but it’s difficult to make the right node for all use cases (2D or 3D? With terrain height factored in? Are positions required to be on the NavMesh?). We may throw together a simple one in the importable samples, but in most cases, we suggest users create their own. I think this would be a fine example to generate with Muse, if you happen to be a subscriber.

Yes, absolutely. We’ll greatly expand the variety blackboard types supported this year.

Aborts are in progress. Utility is TBD.

Great idea!

We have occasionally run into this issue as well, but have yet to identify reliable reproduction steps. We’ll continue to investigate, but if you happen to find a way to repro it, please let us know!

Ah. I see these warnings as well. I’ll look into it. :+1:

Thanks! We wanted the trees to be quite flexible and not always tied to a particular GameObject. This way you could have something akin to a “Scene Director” which could puppet the relevant characters in a scene without needing them to be agents running behavior graphs. This way you can centralize or decentralize your behaviors as you see fit.

2 Likes
3

Thank you very much for all the answers.

Regarding mapped variables, I’ve seen you added a OnValueChanged callback for Blackboard variable value changes in version 0.6.0 but I can’t seem to access it from script.

Anyway, answering your question…

Yes, I think it’s related to that. I’m not an expert so it’s hard for me to really understand the differences but from the beginning I got confused for example with the lack of Aborts I’ve seen in other tools and what it means for traversing branches. In this post there’s a discussion about the design choices:
Muse Behaviour design questions, “What I meant by it’s not fully traversed at each tick is that, let’s say you just started the graph, you do traverse it from the root, but then at some point you hit a node that returns “Running” status, so we cache which node was the last to run and we return for the rest of the frame. Then on the next Tick we don’t start from the top, but from the cached node. This means the evaluation which happens above that node won’t happen again until the branch is terminated or something triggers it, which is why the ways to abort a branch is quite important and we need a more clear way to do it.”.
Maybe it’s not really a different paradigm but rather little things done differently so please don’t give it too much thought. As I said, I’m not an expert and I’m not sure if this should be highlighted :slightly_smiling_face:

Thanks!

Just to point out by the way, I got a lot of inconsistency assigning variables to nodes, they frecuently loose their references. I understand everything is a work in progress though, don’t worry.

Interesting!

Again, much encouragement to the team! Loving it so far.

4

We’re finalizing that API, but you’ll have access to it very soon. :slight_smile:

Thanks for clarifying about your question regarding the philosophy behind the tool. You aren’t the first to ask, so we’ll do our best to give clarity on the topic.

Our next version will include several bugfixes, which will hopefully create a more stable experience for you. On that note, I fixed the mismatched field warnings you brought to our attention. Thanks again for raising it! I’ll let you know when the next version is out.

1 Like