mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-22 20:48:56 +01:00
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.behaviortreeg https://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>
231 lines
8.9 KiB
Plaintext
231 lines
8.9 KiB
Plaintext
/**
|
|
* # Pet Command
|
|
* Set some AI blackboard commands in response to receiving instructions
|
|
* This is abstract and should be extended for actual behaviour
|
|
*/
|
|
/datum/pet_command
|
|
/// Weak reference to who follows this command
|
|
var/datum/weakref/weak_parent
|
|
/// Unique name used for radial selection, should not be shared with other commands on one mob
|
|
var/command_name
|
|
/// Description to display in radial menu
|
|
var/command_desc
|
|
/// If true, command will not appear in radial menu and can only be accessed through speech
|
|
var/hidden = FALSE
|
|
/// Icon to display in radial menu
|
|
var/icon/radial_icon = 'icons/hud/radial_pets.dmi'
|
|
/// Icon state to display in radial menu
|
|
var/radial_icon_state
|
|
/// Speech strings to listen out for
|
|
var/list/speech_commands = list()
|
|
/// Callout that triggers this command
|
|
var/callout_type
|
|
/// Shown above the mob's head when it hears you
|
|
var/command_feedback
|
|
/// How close a mob needs to be to a target to respond to a command
|
|
var/sense_radius = 7
|
|
/// does this pet command need a point to activate?
|
|
var/requires_pointing = FALSE
|
|
/// Blackboard key for targeting strategy, this is likely going to need it
|
|
var/targeting_strategy_key = BB_PET_TARGETING_STRATEGY
|
|
///our pointed reaction we play
|
|
var/pointed_reaction
|
|
|
|
/datum/pet_command/New(mob/living/parent)
|
|
. = ..()
|
|
weak_parent = WEAKREF(parent)
|
|
|
|
/// Register a new guy we want to listen to
|
|
/datum/pet_command/proc/add_new_friend(mob/living/tamer)
|
|
RegisterSignal(tamer, COMSIG_MOB_SAY, PROC_REF(respond_to_command))
|
|
RegisterSignal(tamer, COMSIG_MOB_AUTOMUTE_CHECK, PROC_REF(waive_automute))
|
|
RegisterSignal(tamer, COMSIG_MOB_CREATED_CALLOUT, PROC_REF(respond_to_callout))
|
|
if(requires_pointing)
|
|
RegisterSignal(tamer, COMSIG_MOVABLE_POINTED, PROC_REF(point_on_target))
|
|
|
|
/// Stop listening to a guy
|
|
/datum/pet_command/proc/remove_friend(mob/living/unfriended)
|
|
UnregisterSignal(unfriended, list(
|
|
COMSIG_MOB_SAY,
|
|
COMSIG_MOB_AUTOMUTE_CHECK,
|
|
COMSIG_MOB_CREATED_CALLOUT,
|
|
COMSIG_MOVABLE_POINTED,
|
|
))
|
|
|
|
/// Stop the automute from triggering for commands (unless the spoken text is suspiciously longer than the command)
|
|
/datum/pet_command/proc/waive_automute(mob/living/speaker, client/client, last_message, mute_type)
|
|
SIGNAL_HANDLER
|
|
if(mute_type == MUTE_IC && find_command_in_text(last_message, check_verbosity = TRUE))
|
|
return WAIVE_AUTOMUTE_CHECK
|
|
return NONE
|
|
|
|
/// Respond to something that one of our friends has asked us to do
|
|
/datum/pet_command/proc/respond_to_command(mob/living/speaker, speech_args)
|
|
SIGNAL_HANDLER
|
|
var/mob/living/parent = weak_parent.resolve()
|
|
if (!parent)
|
|
return
|
|
if (!can_see(parent, speaker, sense_radius)) // Basically the same rules as hearing
|
|
return
|
|
|
|
var/spoken_text = speech_args[SPEECH_MESSAGE]
|
|
if (!find_command_in_text(spoken_text))
|
|
return
|
|
|
|
try_activate_command(commander = speaker, radial_command = FALSE)
|
|
|
|
/// Respond to a callout
|
|
/datum/pet_command/proc/respond_to_callout(mob/living/speaker, datum/callout_option/callout, atom/target)
|
|
SIGNAL_HANDLER
|
|
|
|
if (isnull(callout_type) || !ispath(callout, callout_type))
|
|
return
|
|
|
|
var/mob/living/parent = weak_parent.resolve()
|
|
if (!parent)
|
|
return
|
|
|
|
if (!valid_callout_target(speaker, callout, target))
|
|
var/found_new_target = FALSE
|
|
for (var/atom/new_target in range(2, target))
|
|
if (valid_callout_target(speaker, callout, new_target))
|
|
target = new_target
|
|
found_new_target = TRUE
|
|
|
|
if (!found_new_target)
|
|
return
|
|
|
|
if (try_activate_command(commander = speaker, radial_command = FALSE))
|
|
look_for_target(parent, target)
|
|
|
|
/// Does this callout with this target trigger this command?
|
|
/datum/pet_command/proc/valid_callout_target(mob/living/speaker, datum/callout_option/callout, atom/target)
|
|
return TRUE
|
|
|
|
/**
|
|
* Returns true if we find any of our spoken commands in the text.
|
|
* if check_verbosity is true, skip the match if there spoken_text is way longer than the match
|
|
*/
|
|
/datum/pet_command/proc/find_command_in_text(spoken_text, check_verbosity = FALSE)
|
|
for (var/command in speech_commands)
|
|
if (!findtext(spoken_text, command))
|
|
continue
|
|
if(check_verbosity && length(spoken_text) > length(command) + MAX_NAME_LEN)
|
|
continue
|
|
return TRUE
|
|
return FALSE
|
|
|
|
/datum/pet_command/proc/pet_able_to_respond()
|
|
var/mob/living/parent = weak_parent.resolve()
|
|
if(isnull(parent) || isnull(parent.ai_controller))
|
|
return FALSE
|
|
if(IS_DEAD_OR_INCAP(parent)) // Probably can't hear them if we're dead
|
|
return FALSE
|
|
return TRUE
|
|
|
|
/// Apply a command state if conditions are right, return command if successful
|
|
/datum/pet_command/proc/try_activate_command(mob/living/commander, radial_command)
|
|
if(!pet_able_to_respond())
|
|
return FALSE
|
|
var/mob/living/parent = weak_parent.resolve()
|
|
set_command_active(parent, commander, radial_command)
|
|
return TRUE
|
|
|
|
/datum/pet_command/proc/generate_emote_command(atom/target)
|
|
var/mob/living/living_pet = weak_parent?.resolve()
|
|
return isnull(living_pet) ? null : retrieve_command_text(living_pet, target)
|
|
|
|
/datum/pet_command/proc/retrieve_command_text(atom/living_pet, atom/target)
|
|
return "signals [living_pet] to spring into action!"
|
|
|
|
/// Target the pointed atom for actions
|
|
/datum/pet_command/proc/look_for_target(mob/living/friend, atom/potential_target)
|
|
var/mob/living/parent = weak_parent.resolve()
|
|
if(!pet_able_to_respond())
|
|
return FALSE
|
|
if (parent.ai_controller.blackboard[BB_CURRENT_PET_TARGET] == potential_target) // That's already our target
|
|
return FALSE
|
|
if (!can_see(parent, potential_target, sense_radius))
|
|
return FALSE
|
|
|
|
set_command_target(parent, potential_target)
|
|
return TRUE
|
|
|
|
/// Activate the command, extend to add visible messages and the like
|
|
/datum/pet_command/proc/set_command_active(mob/living/parent, mob/living/commander, radial_command = FALSE)
|
|
parent.ai_controller.clear_blackboard_key(BB_CURRENT_PET_TARGET)
|
|
|
|
var/datum/pet_command/previous = parent.ai_controller.blackboard[BB_ACTIVE_PET_COMMAND]
|
|
if(previous && previous != src)
|
|
previous.command_ended(parent.ai_controller)
|
|
parent.ai_controller.set_blackboard_key(BB_ACTIVE_PET_COMMAND, src)
|
|
execute_action(parent.ai_controller) // Install the BT override subtree for this command
|
|
if (command_feedback)
|
|
parent.balloon_alert_to_viewers("[command_feedback]") // If we get a nicer runechat way to do this, refactor this
|
|
if(!radial_command)
|
|
return
|
|
if(!requires_pointing)
|
|
var/manual_emote_text = generate_emote_command()
|
|
commander.manual_emote(manual_emote_text)
|
|
return
|
|
RegisterSignal(commander, COMSIG_MOB_CLICKON, PROC_REF(click_on_target))
|
|
commander.client?.mouse_override_icon = 'icons/effects/mouse_pointers/pet_paw.dmi'
|
|
commander.update_mouse_pointer()
|
|
|
|
|
|
/// Called when this command is replaced by another command or otherwise deactivated. Extend to add cleanup logic.
|
|
/datum/pet_command/proc/command_ended(datum/ai_controller/controller)
|
|
controller.set_behavior_tree_override(SUBPLAN_ID_PET_COMMAND, null)
|
|
return
|
|
|
|
/datum/pet_command/proc/click_on_target(mob/living/source, atom/target, list/modifiers)
|
|
SIGNAL_HANDLER
|
|
if(!can_see(source, target, 9))
|
|
return COMSIG_MOB_CANCEL_CLICKON
|
|
var/manual_emote_text = generate_emote_command(target)
|
|
if(on_target_set(source, target) && !isnull(manual_emote_text))
|
|
INVOKE_ASYNC(source, TYPE_PROC_REF(/atom, manual_emote), manual_emote_text)
|
|
UnregisterSignal(source, COMSIG_MOB_CLICKON)
|
|
source.client?.mouse_override_icon = source.client::mouse_override_icon
|
|
source.update_mouse_pointer()
|
|
return COMSIG_MOB_CANCEL_CLICKON
|
|
|
|
/datum/pet_command/proc/point_on_target(mob/living/friend, atom/potential_target)
|
|
SIGNAL_HANDLER
|
|
on_target_set(friend, potential_target)
|
|
|
|
/// Store the target for the AI blackboard
|
|
/datum/pet_command/proc/set_command_target(mob/living/parent, atom/target)
|
|
parent.ai_controller.set_blackboard_key(BB_CURRENT_PET_TARGET, target)
|
|
return TRUE
|
|
|
|
/// Provide information about how to display this command in a radial menu
|
|
/datum/pet_command/proc/provide_radial_data()
|
|
if (hidden)
|
|
return
|
|
var/datum/radial_menu_choice/choice = new()
|
|
choice.name = command_name
|
|
choice.image = icon(icon = radial_icon, icon_state = radial_icon_state)
|
|
return list("[command_name]" = choice)
|
|
|
|
/**
|
|
* Execute an AI action on the provided controller, what we should actually do when this command is active.
|
|
* This should basically always be called from a planning subtree which passes its own controller.
|
|
* Return SUBTREE_RETURN_FINISH_PLANNING to pass that instruction on to the controller, or don't if you don't want that.
|
|
*/
|
|
/datum/pet_command/proc/execute_action(datum/ai_controller/controller)
|
|
SHOULD_CALL_PARENT(FALSE)
|
|
CRASH("Pet command execute action not implemented.")
|
|
|
|
/// Target the pointed atom for actions
|
|
/datum/pet_command/proc/on_target_set(mob/living/friend, atom/potential_target)
|
|
var/mob/living/parent = weak_parent.resolve()
|
|
if (!parent)
|
|
return FALSE
|
|
|
|
parent.ai_controller.cancel_current_plan()
|
|
if(!look_for_target(friend, potential_target) || !set_command_target(parent, potential_target))
|
|
return FALSE
|
|
parent.visible_message(span_warning("[parent] follows [friend]'s gesture towards [potential_target] [pointed_reaction]!"))
|
|
return TRUE
|