NPBehave 2.0 Changes - Wishlist

[meniku]

Looking at how things work in NPBehave two years after I wrote it, I realise it has some flaws in the aborting/Stops Rules, that cannot be resolved without major changes to the API. That’s why I aim for a new major version.

If you also have suggestions, feel free to comment on this ticket.

My Suggestions:

Base C# Library

As I currently don’t work in Unity, but in Monogame, I would like to split the NPBehave in a base C# library and have separate git-projects for each of the specific engines: Unity, Monogame etc.

Stops Rules

IMO one of the biggest flaws NPBehave has, is the Stops Rules and the aborting of nodes.

1. Aborted nodes can influence the way the Behaviour Tree continues processing by returning Succeed or Failed. This is a property of NPBehave that I like over UE4, where aborting a node results in the whole branch to be aborted. You can get UE4s way by a combination of IMMEDIATE_RESTART and returning the right result in the aborted node, however the way it works right now is not very obvious. I would like to get rid of any IMMEDIATE_RESTART versions of the Stops Rules, and give the control over what “aborting” actually means completely to the aborted node. In case a node gets aborted, the node could control the flow by finish with: Succeed, Failed or Aborted (the latter is a replacement for IMMEDIATE_RETART but will always guarantee that the aborting decorator is restarted)
2. I would like to introduce an “Aborting” state inside nodes. Nodes that are requested to be aborted shouldn’t be forced to immediately finish their work, but allowed to block the flow until they are finished cleaning up ( sometimes you want to wait for some animation for example ). This could be quite problematic in NPBehave, so I will have to see if I can actually make it happen.

[wqaetly]

Awesome. I'm looking forward to it

[xiajjjjjjjjjj]

NB

[wqaetly]

I think we just need to make the logic part of NPBehave ununity dependent and just change the driver of NPBehave to a FixedUpdate that we write ourselves, which also caters to the logical frame requirements of many online game servers and clients.As for support for other game engines, you can let users customize.

[xiajjjjjjjjjj]

I would like to have a plugin or software that can be debugged visually on the server.

[Hobilsm]

I have 2 requests:

1. maybe instead of creating node arrays when we define elements(such as decorations etc.) maybe creating a decorator which return a decorator instance and we could add nodes to it by using a method.

So it would be like this: Sequence sequence = new Sequence() Action action1 = new Action() BlackboardCondition blackboardcondition = new BlackboardCondition() sequence.addNode(action1) sequence.addNode(blackboard condition)

etc..

The thing is this is my 2nd time using NPBehave, and having to make lots of nests with lots of paranthesis can become insane, if you forgot to close paranthesis the moment you created a node, everything below and above that code relevant to behaviour tree becomes red, however i must say i become better at it on my 2nd try, but this issue was the reason why i quit using NPBehave on my 1st try. (please note that i am no expert in coding so maybe i am just a noob :D )

2: Have debug 'steps', so when NPBehave calculates the node it would print a (perhaps a customazible)log to Debugger window and when we click on that log Debugger window could show the states of all nodes and Blackboard values in that particular moment.

[wqaetly]

I have 2 requests:

1. maybe instead of creating node arrays when we define elements(such as decorations etc.) maybe creating a decorator which return a decorator instance and we could add nodes to it by using a method.

So it would be like this: Sequence sequence = new Sequence() Action action1 = new Action() BlackboardCondition blackboardcondition = new BlackboardCondition() sequence.addNode(action1) sequence.addNode(blackboard condition)

etc..

The thing is this is my 2nd time using NPBehave, and having to make lots of nests with lots of paranthesis can become insane, if you forgot to close paranthesis the moment you created a node, everything below and above that code relevant to behaviour tree becomes red, however i must say i become better at it on my 2nd try, but this issue was the reason why i quit using NPBehave on my 1st try. (please note that i am no expert in coding so maybe i am just a noob :D )

2: Have debug 'steps', so when NPBehave calculates the node it would print a (perhaps a customazible)log to Debugger window and when we click on that log Debugger window could show the states of all nodes and Blackboard values in that particular moment.

Well, I realized this the first time I saw NPBehave, but that doesn't affect NPBehave which is a nice behavior tree.Maybe you can try to make a visual tool, I have made one, but some parts are not handled perfectly, so I don't plan to open source currently, it looks similar to this issue

issues21

I expect to pull it to this great author in January 2020

[meniku]

I think we just need to make the logic part of NPBehave ununity dependent and just change the driver of NPBehave to a FixedUpdate that we write ourselves, which also caters to the logical frame requirements of many online game servers and clients.As for support for other game engines, you can let users customize.

It should be quite easy as most of the base NPBehave library is actually not tied to Unity. We just have to make the UnityContext or remove it from the base-library all together and give the user the responsibility for managing a Clock and, if needed, the Shared Blackboard pool. The most problematic part would be having a debugger that works outside of unity.

I would like to have a plugin or software that can be debugged visually on the server.

Maybe we could think about providing one by running a little HTTP server in NPBehave, that would also solve the issue that we currently have a debugger that's dependent on Unity

maybe instead of creating node arrays when we define elements(such as decorations etc.) maybe creating a decorator which return a decorator instance and we could add nodes to it by using a method.

Sequence sequence = new Sequence()
Action action1 = new Action()
BlackboardCondition blackboardcondition = new BlackboardCondition()
sequence.addNode(action1)
sequence.addNode(blackboard condition)

Yeah that should be possible, although I wouldn't personally make this the default way to describe behaviour trees. However I have to admit that I also had this problem from time to time.

What I did in the past to prevent huge nesting was splitting my tree up, by creating factoring methods that created me subtrees. Here's an example of subtree that is used within a huge BT. It also calls other factory methods to build subtrees within. Maybe that helps you a bit:

    protected Node createBananaTree()
    {
        return new BlackboardCondition(BK_POWERUP_TYPE, Operator.IS_EQUAL, PowerupType.BANANA, Stops.IMMEDIATE_RESTART,
            new Sequence(

                createWaitForActionNode(powerupUseTime, "Use Powerup"),

                new Selector(
                    // A) check for a good place for the banana
                    new Condition(() => shouldActIntelligently(0.25f) && shouldActAnalyticly(0.5f) && !isBehindEnemy("walkPath"),
                        new Selector(

                            // on powerup field
                            createOnPowerupFieldTree(isOnPowerupField),

                            // good banana place
                            new BlackboardCondition(BK_IS_BANANA_GOOD_PLACE, Operator.IS_EQUAL, true, Stops.LOWER_PRIORITY_IMMEDIATE_RESTART, 
                                createUseItemWhenInputAvailableNode()
                            ),
                            new WaitUntilStopped()
                        )
                    ) { Label = "Smart", Collapse = true },

                    // B) bot did not choose good place for a banana, wait some time and proceed with dumb action
                    createDumbPowerupUseTree()
                )
            )
        ) { Label = "Banana", Collapse = true };
    }

2: Have debug 'steps', so when NPBehave calculates the node it would print a (perhaps a customazible)log to Debugger window and when we click on that log Debugger window could show the states of all nodes and Blackboard values in that particular moment.

Yes I agree, that could be useful.

issues21 I expect to pull it to this great author in January 2020

Yeah that sounds good and could be definitely helping some kind of users. Looking forward to it

[wqaetly]

I would like to have a plugin or software that can be debugged visually on the server.

Maybe we could think about providing one by running a little HTTP server in NPBehave, that would also solve the issue that we currently have a debugger that's dependent on Unity

Yes, the Debug tool out of Unity is a tricky issue, But I don't have any good ideas at the moment, as you mean to make a lightweight WEB application, but I can't imagine how to connect to the behavior tree...,I'm looking forward to your performance

[Hobilsm]

Maybe something about persistance to support save/load systems?

In many cases restoring the blackboard could be enough but on many cases with nodes related to time and the nodes that doesnt stop itself when condition is no longer met could be tricky.

So it would be great to have to have a lets say Save method and this method could either directly save to a file or give us a savable struct so we can intergrate that to our save system.

[ye7iaserag]

Firstly, I'd like to thank you a lot for the awesome work done here and the MIT license. I've gone through the code base and as someone who never wants to be tied to an engine; I didn't find that your library is coupled with unity in anyway, the only thing I've found was UnityDebug Where have I gone wrong?

[meniku]

yeah exactly, it should be not that hard to split that up. It's more about how the project(s) will be structured. Will we have a base library project and then extra projects for more specific ones (Unity, Monogame, ...)? Or will there be just one project on GitHub hosting all variants, and then we have a subfolder for each specific variant? Not sure what the best practices are.

[geowarin]

Hello and thanks for your awesome work. An idea to facilitate modularization would be to create a package.json file which would be used by unity.

An example is the node editor framework, which depends on undo pro: https://github.com/Seneral/Node_Editor_Framework/blob/v1.0.2-lts/package.json

{
  "name": "com.seneral.nodeeditorframework",
  "displayName": "Node Editor Framework",
  "version": "1.0.2",
  "unity": "2018.1",
  "description": "A flexible and modular Node Editor Framework for creating node based displays and editors in Unity",
  "category": "",
  "dependencies": {
    "com.seneral.undopro": "1.0.0"
  }
}

Using this, you could split the project in two: core and unity and have unity depend on core. This would allow users to use the package manager in unity to install both.

More info here: https://neogeek.dev/creating-custom-packages-for-unity-2018.3/

[meowao]

I recommend make NPBehave like some runtime, and build behavior tree use some like json or xml file. then we can make a visual editor easy. and we can use this behavior tree file in any language, just implement the runtime in this language.

[meniku]

I recommend make NPBehave like some runtime, and build behavior tree use some like json or xml file. then we can make a visual editor easy. and we can use this behavior tree file in any language, just implement the runtime in this language.

yes I agree, I'm thinking about adding YAML support for my own game, probably gonna put it straight into NPBehave if I can make it general enough

[kvfreedom]

Is MemoryPack a good choice for serialization?