a57b142c1a
* Basic mobs don't become dense upon death (#72554) ## About The Pull Request In #72260 what was previously a var became a flag, which was a sensible change, however this inverted the default behaviour. In virtually all cases we want dead mobs to _stop_ being dense, this added a requirement for the flag to be present for that to happen and then didn't add the flag to any mobs. Rather than add this to every mob I inverted the function of the flag. My reasoning here is that _simple_ mobs seemingly never required this behaviour, basic mobs are probably going to need it rarely if ever, and including it in `basic_mob_flags` by default seems messy and easy to leave off when setting other flags (plus #72524 implies to me we want to avoid adding more default values). Setting this manually on each mob seems kind of silly as a requirement going forward and I can't think of a way we'd unit test for people forgetting. For the same reason I did the same thing with the `STOP_ACTING_WHILE_DEAD` flag I added to the AI controller in a recent PR, the flag should denote unusual behaviour not the default. ## Why It's Good For The Game It looks really odd when you're constantly shuffling places with dead mobs, they're not supposed to do that. It's tedious to add `STOP_ACTING_WHILE_DEAD` to every AI controller when that should be an obvious default assumption. ## Changelog 🆑 fix: Dead basic mobs are no longer "dense" objects and can be stepped on. /🆑 * Basic mobs don't become dense upon death * Removes a flag we didn't need anymore. * Forgot to remove this one Co-authored-by: Jacquerel <hnevard@gmail.com> Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com> Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
AI controllers
Introduction
Our AI controller system is an attempt at making it possible to create modularized AI that stores its behavior in datums, while keeping state and decision making in a controller. This allows a more versatile way of creating AI that doesn't rely on OOP as much, and doesn't clutter up the Life() code in Mobs.
AI Controllers
A datum that can be added to any atom in the game. Similarly to components, they might only support a given subtype (e.g. /mob/living), but the idea is that theoretically, you could apply a specific AI controller to a big a group of different types as possible and it would still work.
These datums handle both the normal movement of mobs, but also their decision making, deciding which actions they will take based on the checks you put into their SelectBehaviors proc.
If behaviors are selected, and the AI is in range, it will try to perform them. It runs all the behaviors it currently has in parallel; allowing for it to for example screech at someone while trying to attack them. As long as it has behaviors running, it will not try to generate new plans, making it not waste CPU when it already has an active goal.
They also hold data for any of the actions they might need to use, such as cooldowns, whether or not they're currently fighting, etcetera this is stored in the blackboard, more information on that below.
Blackboard
The blackboard is an associated list keyed with strings and with values of whatever you want. These store information the mob has such as "Am I attacking someone", "Do I have a weapon". By using an associated list like this, no data needs to be stored on the actions themselves, and you could make actions that work on multiple ai controllers if you so pleased by making the key to use a variable.
AI Behavior
AI behaviors are the actions an AI can take. These can range from "Do an emote" to "Attack this target until he is dead". They are singletons and should contain nothing but static data. Any dynamic data should be stored in the blackboard, to allow different controllers to use the same behaviors.
Guides:
Making Your AI: Quickly runs through how to make an ai controller for anything with a step by step development of one.