This PR replaces our current NPC AI with a [behavior tree
system](https://en.wikipedia.org/wiki/Behavior_tree_(artificial_intelligence,_robotics_and_control)).
Behavior trees are a common way of creating AI in which you place nodes
in a tree structure to define what actions an AI should take.
AI controllers defined a list of /datum/ai_planning_subtree types in
behavior_nodes. Each subtree was a self-contained unit that could call
queue_behavior() to fire off /datum/ai_behavior actions. The controller
iterated subtrees in order, each one deciding independently whether to
queue something and deciding whether the next subtree would run.
This has a few issues:
1. There's no real structure; you are just defining a list of things to
try in order.
2. There was a loooot of subtrees that were basically the same as
another but with some slight modification
3. It was hard to understand.
Controllers now define a single json file describing a tree of nodes.
The tree is composed of structural composites:
Sequence - do A, then B, then C (and so on)
Selector - try A, if it fails try B, then C (and so on)
Parallel - run A and B simultaneously, with configurable failure/success
policies and or looping behavior
Subplan - loop a child continiously
Along that we also have "Decorators". These are nodes that basically
check a condition (E.g.; do we have a combat target). These decorators
can be used to gate behavior and are re-useable across behavior trees.
They also have a concept known as "Observers". Which lets them cancel
lower priority behavior in case their condition changes (Which we check
whenever a signal fires that fits that specific decorator). This makes
the AI much more responsive to change in environment.
For behaviors, we still use the ai_behavior datums. These are the actual
behaviors such as "Move to X", "Attack X". The only major change is that
these can no longer sleep() since they now run in the ai_controller.
Lastly, we now also have subtrees, except now they are essentially
pieces of behavior tree that can be re-used, or even overriden at
runtime or as a variable. Allowing for making modular AI made out of
several smaller trees.
You can set variables on these nodes directly via the extension (see
below), which should reduce the need to make subtypes of behaviors by a
lot. All of these vars are saved on the JSON and will be applied at
runtime.
If you are using subtrees, you can also assign "bindings" to these
variables, which will allow instances of the subtree to override those
variables.
Since a tree structure with variables becomes hard to parse in a JSON,
I've made a VSCode extension to edit these JSONs:
https://marketplace.visualstudio.com/items?itemName=BehaviorTreeG.behaviortreeghttps://github.com/CabinetOnFire/BehaviorTreeG
<img width="1795" height="1268" alt="image"
src="https://github.com/user-attachments/assets/56aa2f0b-3cf9-449f-bca4-8281fca82db6"
/>
This extension allows you to edit the behavior tree JSONs, and browse
through all the behaviors/decorators/subtrees we have
If you'd like more info on how to build these AI check out the
learn_ai.md. I will also make a tutorial to go over more depth on what
the system offers because I kind of suck at doing technical write-ups.
Targetting has been changed to. I've made a new acquire_targets behavior
that takes a target_source (what am I targetting) and
targetting_strategy (what does the candidate need to fulfill to be
considered a target). This allows us to make composites targetting
combinations to reduce the amount of specific find_and_set esque
behaviors we had before. Not everything is ported to this system but
that would be a longer term goal.
I've added a new build_bt script that converts all the behavior tree
JSONs into compiled versions. Why is this needed? Because I wanted to
keep using defines in behavior trees, so we need a way to convert this
into literal values before we send it to DM. This script runs on compile
and should also run in CI (If I didn't fuck that up!). This saves to a
new build/ folder.
I've ported every single AI in the game to this system (except raptors,
Kobsa is working on those so should be in soon!), so I do expect some
bugs to come out of this. But I also fixed some issues that have
probably been in the game for a long time such as:
- Fixed penguins being unable to fish
- Fixed bileworms not being able to devour people
- Fixes goldgrubs not grubbing gold (they could not mine!)
- Lizards actually eat food they find
Either way, I'd reccomend a long TM on this.
1. (Hopefully) a better development experience for making AI
2. Less copy-paste for behaviors, we should be able to re-use more
pieces to make behavior
3. Behavior trees is a more common pattern in making AI, so it should be
easier to find resources to find out how to do things.
🆑 CabinetOnFire, Iamgoofball, SmartKar, Ben10omintrix
refactor: Replaces our AI system with behavior trees, porting all
datum/ai to it
/🆑
I will add this PR with more details down the line. I think I got the
big picture but its a big PR, so sorry if I missed something important.
---------
Co-authored-by: Iamgoofball <iamgoofball@gmail.com>
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com>
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
## About The Pull Request
Separate verb and PR from #89375 because this is something you'd apply
on top of a mob with existing behaviour, or one you've used the other
verb on.
This will probably conflict with my other PR but that's my problem.
This adds a shortcut for making mobs say/emote stuff randomly on a timer
from a list of things you have specified.
Doing this via VV is possible but sufficiently complicated that I don't
think anyone would ever bother.
As with the other PR you can optionally do this to mobs who already have
a client if you want them to randomly burp every so often or something.
I briefly flirted with the idea of replacing all
`/datum/ai_planning_subtree/random_speech` subtypes with blackboard ones
but... I think probably actually we save some memory _and_ sanity by not
doing that.
A bunch of mobs on totally different typepaths use the `/insect` subtype
for instance, and I don't think it would be an improvement to paste the
same four vars into all of their blackboards.
## Why It's Good For The Game
This one is frankly more niche than the other PR probably but it is
plausibly useful if you are setting up some kind of VV creature.
## About The Pull Request
Melbert asked me to make this and I thought it'd be relatively easy and
plausibly useful so I did.
This PR adds a feature to the VV menu for mobs which allows you to apply
and configure an AI controller from a list of templates.
It's not as versatile as coding one would be, but it should be able to
accomodate a lot of generic scenarios.
Some examples of basic stuff you can set it up to do:
- Give Ian a machine gun he will fire at nearby people while staying
within a specified min/max range.
- Have Poly fire brimstone beams on cooldown at whoever is nearby
(although she won't bother trying to line up cardinally).
- Assign a gorilla to be someone's personal bodyguard which will follow
them around and attack anyone who hurts them.
I have also made an executive decision to remove the restriction that
basic ai controllers can only be placed on basic mobs.
We've removed _most_ non-basic simple mobs from the game, and also have
more recently updated most AI behaviours to work agnostically of whether
they are assigned to a basic mob or not... which means that they'll
largely work on carbons.
Coincidentally, this feature makes sure to ask if you want an AI
controller to remain active on a mob which already has a client.
Assigning an active AI controller to a live player which forces their
character to automatically attempt to run away from whoever the last
person to attack them was is ~~not recommended behaviour because it's
largely untested~~ highly recommended behaviour because I think it's
very funny (makes it very hard to play though).
I'm gonna do another PR some time which cleans up `random_speech` so
it's configurable and then let you slap that on whoever as well.
## Why It's Good For The Game
Enables a greater level of admin abuse.
## Changelog
🆑
admin: Added easier tooling for admins to add or change the AI
controllers on mobs
/🆑
* Targeting Datums Renamed (and global) (#79513)
## About The Pull Request
[Implements the backend required to make targeting datums
global](https://github.com/tgstation/tgstation/commit/6901ead12e419530b7f646ea21094d4432d7385e)
It's inconsistent with the rest of basic ai for these to have a high
degree of state, plus like, such a waste yaknow?
[Implements
GET_TARGETING_STRATEGY](https://github.com/tgstation/tgstation/commit/d79c29134d03424a9f8bacd64c08cb41775fe8c0)
Regexes used:
new.*(/datum/targetting_datum[^,(]*)\(*\)* -> GET_TARGETING_STRATEGY($1)
Renamed all instances of targetting to targeting (also targetting datum
-> targeting strategy)
I've used GET_TARGETING_STRATEGY at the source where the keys are
actually used, rather then in the listing. This works out just fine.
## Why It's Good For The Game
Not a misspelled name through the whole codebase, very slightly less
memory load for basically no downside (slight cpu cost maybe but not a
significant one.
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@ users.noreply.github.com>
* Targeting Datums Renamed (and global)
* Update dogs.dm
* Modular
* Modular
* Modular
* Merge skew?
* Revert "Merge skew?"
This reverts commit 0889389ab5cb5c56655f1860d9173ba87efe9a22.
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: John Willard <53777086+JohnFulpWillard@ users.noreply.github.com>
Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com>
