Question: How to best model multi behavior/action sequences?

[namrog84]

Using curvature, I am not quite sure how to have multiple behaviors that i do want to run in sequence?

The only thing I can think of is to have one of the considerations be that some earlier action was chosen and then rank the next action in the sequence very highly. Potentially only really needing 1 consideration( was other behavior just finished)

Or should I bundle them all into the 1 'behavior' internally as all the actions that need to be taken?

[apoch]

The approach you described is quite reliable; in Curvature's model, I would only make a small adjustment, to organize things a bit: define a Knowledge Base entry that is a property of every agent and has predefined values. Create one value for each "stage" of the behavior sequence. Then you can set up each stage as a separate behavior with a consideration that looks at the predefined value to see where an agent is at in the sequence.

Personally I would not recommend having the "what stage am I at" consideration be the only criteria for a behavior. Instead I would suggest using it as a weight modifier; maybe it can influence the score but it is not the only thing that makes a particular subset of the behavior sequence meaningful. This has the nice property of allowing behaviors to pick up in the middle of a sequence if it makes sense.

Generally in the design space I try to encourage fluid combination of many small behaviors instead of fixed sequences. For example if your action sequence is 15 seconds long, you have just turned off the AI for 15 seconds until the sequence is over. If there is anything happening during that time that you may want the agent to react to, a fixed sequence is a liability. Having many different considerations on a behavior really mitigates this. For the same reason, I don't personally like the approach of having "uber behaviors" that encapsulate many actions.

Of course every design space is different, so ultimately you will be the best judge of what works well in your situation. Part of my goal with Curvature is to learn about design challenges that I haven't already tackled, so I am happy to discuss if there is room for improvement in the tool.

Thanks!

[namrog84]

So for example in this Shouting Sniper Example:

Actions = [Stand up, aim, shout something, fire, duck down]. All should happen relatively fast, so not quite the 15 seconds and so it doesn't really make sense to resume from all states. If a grenade is tossed into his proximity, I'd agree he'd want to duck out of the way no matter where in the sequence is at. So it should still be override-able from higher up in the chain. So perhaps if something override the sequence, it can reset the 'internal state of the sequence', or at least have some checkpoints of the internal state of sequence if there even is a 'resumable point'. I agree it shouldn't be the only consideration for the action. Because perhaps in this case there is no enemy anymore, I had considered that to be checked by the conditionals of a parent utility/subreasoner, but it depends upon the particular action.

I am coming from having first learned Behavior Tree and FSMs, so I am still trying to wrap my head around the utility theory of how to approach certain problems. Thanks again for your support and assistance in helping me :). I know some of these are more Utility theory questions and maybe less curvature specific.

[apoch]

There's a few layers here. Pure utility-based architectures (like the one Curvature implements) are generally not a good fit for game/simulation designs that need a lot of highly specified behavior sequences. You can make it happen, with enough work, but it's just more efficient to stick to a pure BT or HFSM style architecture at that point.

If the simulation design really mandates that kind of scripted sequence a lot, then the real sweet spot in my opinion is hybrid architectures - where you use utility-based principles to inform the selection of nodes in a BT, as one example. Another architectural approach that I think is totally valid is to write custom logic in a scripting language; you can blend any set of rules and logic you like.

If the scripting is not really essential to the game design, the trick is that we have to think of our AI in a different way than we're used to from BT/HFSM type systems. I think of this as "doubling down" on utility and setting aside the desire for knowing exactly what an NPC is going to do at all times. This is admittedly a giant change of mentality and does not necessarily work in every project.

The old "right tool for the job" quip is highly relevant here. If you have a specific design you want to achieve in a game/sim, pick the architecture that is most suited for pulling it off. Of course if you're interested in seeing what utility can do when really set loose, it will take a journey up the learning curve. I encourage people to really play with Curvature - not as a way to implement a specific behavior or NPC design, but as a sandbox where you can see what is really possible when all the stops come out.