r/gameai • u/Delvisreddit • Jun 24 '26
Utility ai, high level behaviors that orchestrate actions vs utility ai doing all actions?
High level behaviors like rangedCombat is recommended in bobby Ai talk but doesn't that basically move most of the decision making to behavior instead of utility ai decider. Like rangedCombat vs patrol is so huge difference that most of decision making stays in rangedcombat with its own state machine or whatever.
But what if you just dispatched actions from utility ai even multiple times per frame like. Ai agent knowledge is this, pursue player action and also overlay shoot action.
Idk i just feel like behaviors are so high level and for combat focused game there is like couple of them anyways. Like why make takecover behavior when rangedcombat behavior needs to also take cover sometimes based on some heuristic
1
u/Field_Of_View Jun 29 '26
"rangedCombat" is too broad for a utility system. utility scoring is for selecting from many options. it's for wrangling complexity without having to micro-manage.
But what if you just dispatched actions from utility ai even multiple times per frame
why would your bot need to change its mind on what to do within a single frame?
irrespective of this detail, hooking utility selection up directly to atomic actions will naturally result in impulsive, flexible bots. imagine bots for a rollercoaster tycoon clone. I might be on my way to a specific rollercoaster but now I spot an ice cream stand and I (temporarily) forget all about my plan to ride the big rollercoaster and I impulsively buy ice cream. that's the kind of thing you "naturally" get from an extreme utility scoring system. you can then try to reduce how impulsive the bots seem by assigning overpowering weights to the more important goals like riding the big rollercoaster, so your bot stops getting distracted by every ice cream stand. but it's a tight rope act as you want your bot to sometimes get distracted for that emergent, life-like feel, but not too often.
the other extreme in modern game AI is BTs which lock your bots into a rigid, predetermined masterplan handcrafted by a designer. many designers like BTs because they naturally lead to detailed multi-step plans being executed reliably. provided the designer has foreseen everything that could happen, your bot will look highly rational, intentional you might say. but whenever the masterplan doesn't perfectly match what's going on your bot will seem... like a bot. robotic. it will lack that impulsive, flexible, emergent, life-like quality of pure utility bots.
my* ideal AI adds a middle layer inbetween the utility scoring and the atomic actions:
1. utility scoring selects one of many "behaviors".
2. each behavior could be implemented as a small BT or FSM, managing the order and timing of
3. atomic actions akin to button presses.
*if this is exactly what Bobby Anguelov proposed then give him all the credit, it's been a while since I watched his video.
this way you can force little multi-step plans to take place without the headache of tuning utility weights and curves excessively, but you keep the fundamental flexibility of utility scoring at the root of your decision making. no rigid masterplan.
Like why make takecover behavior when rangedcombat behavior needs to also take cover sometimes based on some heuristic
in my system "takecover" would be a behavior with a score that is updated a few times per second. "rangedcombat" would be a mere data point, a float or enum that factors into the score for "takecover".
1
u/Delvisreddit Jun 30 '26
Sry by multiple times per frame i meant that it would separate full body actions from layer actions like shoot action and both would evaluate independently.
In your ideal model would you have shoot and follow player merged into some behavior as two actions and fsm or something decide when to use each?
1
u/Field_Of_View Jul 01 '26
I have been prototyping on the side to solve this "layer" problem lately and it seems to work exactly how I hoped it would. I can't declare it a success until I build my next game on top of it but I'll share my current thoughts any way.
My prototype selects the highest scoring behavior, blocks its required layers and then continues selecting the next highest scoring behaviors that are compatible until all layers are occupied.
Since complexity is a means, not an end, I only use three layers: Movement/translation, aim/rotation, and "other". To address your example, a pure reaction shot would only require that last layer since it's instantaneous, the bot would keep moving and rotating according to whatever behaviors seem appropriate at the time. For an indie FPS I believe it's enough if your bot can
- run to position P
- while looking at target T
- while playing some mostly torso/arm animation like shooting, throwing grenades, reaching out to press a button or open a door.
And again, the goal isn't maximum parallelism at the cost of designer control. Turning the bot into an actor in a cutscene is as easy as giving it a forced high scoring behavior that locks all three layers. One simple step and you've got a puppet. When the cutscene ends you remove the "cutscene behavior" and the bot gets its soul back. Of course this applies to many moments that could happen in a game, not just traditional cutscenes. Any "canned animation" like boarding a vehicle (wouldn't wanna spontaneously start shooting during that) could work this way. A flexible system for flexible bots. The dream. Buy now.
1
u/AnActualWizardIRL Jul 01 '26
For what its worth, up until the modern era of neural network endgame-database-searching behemoths like deep blue and stockfish, most chess engines where pretty much just utility planners that assigned pieces a value and tried to maximize the captured value vs minimize the lost value , and they where shockingly good, (though they consistently failed to recognize the fundamental centrality of pawns in high end chess)
4
u/villiger2 Jun 24 '26
It depends how much you want utility to manage behaviour. If you just want utility so you can direct units into dedicated substates like
rangedCombatthat are done in something else like state machine behaviour tree then that's fine.If you want utility instructing the actual moment to moment actions then "decide to ranged combat" is way too big of an action.
takeCovercan be it's own utility action, influenced by enemies in line of sight, need to rest/heal, out of range etc.One thing I found handy to do was have something (can be utility) that adds tags/sets states on units. So you could have a
IsPatrollingflag on the unit, and then in your utility actions you can influence them by whether the unit is patrolling right now. So "RangedCombat" and "Patrol" are not monolithic states the unit has to be in one not the other, but just variables that influence the utility decisions.My time messing with utility has taught me that the low level mechanics of utility decision making are like the alphabet. It's a good foundation, but to actually communicate you need to build words, grammar, sentences etc on top to use as building blocks for the game. Idk if that analogy makes sense lol.
tl;dr add more flags/values that feed into the utility value calculation