Search Unity

Discussion Question about design of a Behaviour Tree

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

  1. ShrikeDev

    ShrikeDev

    Joined:
    May 31, 2018
    Posts:
    31
    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:
    https://takinginitiative.files.wordpress.com/2020/01/behaviortrees_breaking-the-cycle-of-misuse.pdf

    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.