That task doesn’t directly trigger a scene change & conversation because I’m not running one tree but potentially a dozen trees when an action is performed.
Now you’re right that the task could look to see if a previous version of that task has already been queued and failed there. But that makes it a first-come, first-served approach, and the author doesn’t have a way of saying, “this actor is more important than that actor.” (I don’t think that approach can work because it will always be context specific).
I could add a “speech priority” attribute to the task so that one task will win out, but if the last task has the highest priority… well, other tasks will have already succeeded when they shouldn’t have.
Perhaps I could run all the behaviour trees in parallel and specific tasks can block waiting for all other tasks of the same type to have completed, and only one can succeed, and the rest fail. That feels like a recipe for deadlocks and painful debugging sessions.
It’s messy, and I haven’t thought of a clean solution.
I feel that tying this to plot & plot clocks while making the author structure things a little differently could end up being more straightforward in the end.
It’s definitely an interesting idea but I’ve not conjured any formulation of “merging” trees that is conceptually easy enough for me to follow and think I could live with over time.
I’ve considered just having one behaviour tree, but it creates a significant authoring challenge as it quickly becomes unwieldy.
In fact I like your idea of subdividing the tree even further along functional lines. I’ll think about that.
NPCs can do different things, but you can represent them as large-scale branches in the big tree. Patrollers take this branch until they sight the player. Rabbits have a whole other branch involve looking for lettuces.
The point, as Matt implies, is that you’re really answering exactly one question: what does this NPC do right now? One tree can handle that.
Breaking it up (actor, location, faction, time-of-day?) sounds tempting to me because I’m used to I7! But it’s tricky all right. I7 groups distinct rules into rulebooks, and the only question is what order to check them in. (And that’s already fraught.) Grouping distinct micro-trees into… what? A big composite tree? Interesting problem. Which I don’t have a solution for. :)
While working on Rez, I came across the RPG “Blades in the Dark” by John Harper. I haven’t played Blades, although I have read the rulebook several times. Something cool it introduces is “progress clocks”:
“Sneaking into the Bluecoat Watch Tower? Make a clock to track the alert level of the patrolling guards. When the PCs suffer consequences from partial successes or missed rolls, fill in segments of the clock until the alarm is raised.”
There are all different kinds of progress clocks that can be operating at the same time in a Blades game.
So I have borrowed them, and Rez has a @plot element to define a plot with a clock and, crucially, a priority, i.e. one plot can be more important than another.
So what I am thinking is that narratively an NPC engaging with a player to initiate dialogue (rather than a player initiating dialogue with an NPC) must be part of advancing a plot. So the behaviour tree task advances the plot and potentially triggers dialogue.
We can use the plot priority to queue the encounters if two plots have advanced in this way in the same “tick”.
I’m still playing with it in my mind. But by gating this kind of thing through a plot, I think (I mean, I hope) it keeps it simple for the author to reason about why things are happening (including later on when they have forgotten everything!).
I’m just looking at it now on Steam. Interesting that they even call out these mechanisms on the store page. I guess I should give this one a go and see how they implement things. Thanks for the pointer.
There’s also…I’ve been hesitating to mention it since it’s a little distinct from behavior trees, but there has been a bunch of work in things like HTN (Hierarchical Task Network) planners and such in the narrative space: in particular Ian Horswill’s Step language can handle most things in the “tree-search with backtracking and unification” family. Max Kreminski’s page might also be interesting to you (maybe starting with the papers about StoryAssembler or Felt)?
