Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at during this transition time.

    It's still possible to reply to existing private message conversations during the migration, but any new replies you post will be missing after the main migration is complete. We'll do our best to migrate these messages in a follow-up step.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.

    Read our full announcement for more information and let us know if you have any questions.

Discussion Question about design of a Behaviour Tree

Discussion in 'Scripting' started by ShrikeDev, Sep 16, 2022.

  1. ShrikeDev


    May 31, 2018
    I've been working on a 2d action game for around two months now, it's my first game and project of this scale so a lot of the time has mostly been spent learning, refactoring and making something rudimentary.

    Currently I'm trying to improve my AI code, the game is heavily focused on bossfights so it's important that they are dynamic and interesting. I'm trying to follow a good design pattern that's easy to modify and change in the future. I've already studied up some on behaviour trees but I don't actually know anyone I knowledgeable about them can discuss them with. Initially I looked into statemachines, but recently I've decided to try using a behaviour tree instead. I've read this:

    My takeaway is that behaviour trees are the most powerful when used as "actuators" rather than "decisionmakers". In other words, you have *all* of the conditions evaluated before you run the behaviour inside the tree, the only decisionmaking allowed inside the tree have to be limited to executing their designated task, and cannot change the overall state of the tree. So if I understand correctly, to make an implementation of this in order to make a dynamic AI, it could look something like this:

    Conditions: Player is within long range, health below 40, randomized value is X
    (Unique behaviour accepting conditions, not on cooldown) X <- this is executed
    (Unique behaviour accepting conditions, not on cooldown) Y
    (Unique behaviour accepting conditions, not on cooldown) Z

    Randomized value was X, so Behaviour X might be executed if Behaviour X is not on cooldown, if it was on cooldown value X would be excluded as an outcome of the randomization. The durations of the cooldowns could also be randomized within a range to make them less predictable

    Does this pattern make sense? As I understand the full length of the behaviour is executed as long as nothing external happens that would change it, the behaviour can never change to another internally or the design could become cyclic and confusing as it expands. So you end up having more behaviours but at the advantage of better readability and mutability. I've grown quite interested in game AI so I don't mind taking some extra time learning more about it before I get too deep working out my own for the game.