Minecraft:Mob AI: Difference between revisions
More actions
Sync: updated from Minecraft |
Sync: updated from Minecraft |
||
| Line 1: | Line 1: | ||
{{for||AI}} | {{for||AI}} | ||
{{WIP}} | {{WIP}} | ||
{{cleanup}} | |||
This article describes the various components of a mob's AI that control its behavior. | This article describes the various components of a mob's AI that control its behavior. | ||
| Line 6: | Line 7: | ||
== Brain == | == Brain == | ||
Some mobs use a complex AI system called a brain. A mob's brain stores memories (data), a list of tasks that can be performed, and a list of sensors used to determine which tasks it can perform. | Some mobs use a complex AI system called a brain. A mob's brain stores memories (data), a list of tasks that can be performed, and a list of sensors used to determine which tasks it can perform. | ||
=== Memory === | |||
A brain stores data as memories. The type a memory represents is called the memory module type. The data itself is stored within a corresponding memory slot. Within the memory slot the data value can be empty, signaling that the memory is empty, or it can have a value signaling that the memory is present. Additionally the memory may have a time-to-live. The time-to-live indicates the number of ticks after which the memory is forgotten, and the memory value will become empty again. If the time-to-live is not specified, it is assumed to be infinite, i.e. the memory is permanent. | |||
Memories are the only [[Minecraft:NBT_format|NBT]]-driven component of the brain system. | |||
To modify a mob's memories, the {{cmd|data}} command can be used. | |||
Note that this will erase all non-persistent memories and reset all activity and behavior states, as the mob's brain is completely reconstructed. | |||
Example: | |||
{{cmd|data merge entity <''TARGET''> {Brain:{memories:{"minecraft:dig_cooldown":{value:{},ttl:0L<nowiki>}}}}</nowiki>}} | |||
Executing this command with a [[Minecraft:warden]] as its target will cause the warden to immediately burrow. This is because the 60 second cooldown timer gets reduced to 0 ticks, causing the memory to expire in the next tick, at which the warden can initiate its despawning process. | |||
==== Memory statuses ==== | |||
Registered memory module types can have three states in a brain: | |||
# <code>REGISTERED</code>: The brain contains a memory slot for the type. | |||
# <code>VALUE_PRESENT</code>: The brain holds a value in the memory module type's corressponding memory slot. | |||
# <code>VALUE_ABSENT</code>: The brain does not hold a value in the memory module type's corressponding memory slot. | |||
These statuses will become relevant in the [[#Activities|activity]] and [[#Behaviors|behavior]] sections. | |||
==== Memory module types ==== | |||
{|class= "wikitable collapsible collapsed stikitable" | |||
|+ List of Memory module types {{in|JE}} | |||
!ID | |||
!Data type | |||
!Serializable | |||
|- | |||
|<code>dummy</code> | |||
|Void | |||
|false | |||
|- | |||
|<code>home</code> | |||
|GlobalPos | |||
|true | |||
|- | |||
|<code>job_site</code> | |||
|GlobalPos | |||
|true | |||
|- | |||
|<code>potential_job_site</code> | |||
|GlobalPos | |||
|true | |||
|- | |||
|<code>meeting_point</code> | |||
|GlobalPos | |||
|true | |||
|- | |||
|<code>secondary_job_site</code> | |||
|List<GlobalPos> | |||
|false | |||
|- | |||
|<code>mobs</code> | |||
|List<LivingEntity> | |||
|false | |||
|- | |||
|<code>visible_mobs</code> | |||
|NearestVisibleLivingEntities | |||
|false | |||
|- | |||
|<code>visible_villager_babies</code> | |||
|List<LivingEntity> | |||
|false | |||
|- | |||
|<code>nearest_players</code> | |||
|List<Player> | |||
|false | |||
|- | |||
|<code>nearest_visible_player</code> | |||
|Player | |||
|false | |||
|- | |||
|<code>nearest_visible_targetable_player</code> | |||
|Player | |||
|false | |||
|- | |||
|<code>nearest_visible_targetable_players</code> | |||
|List<Player> | |||
|false | |||
|- | |||
|<code>walk_target</code> | |||
|WalkTarget | |||
|false | |||
|- | |||
|<code>look_target</code> | |||
|PositionTracker | |||
|false | |||
|- | |||
|<code>attack_target</code> | |||
|LivingEntity | |||
|false | |||
|- | |||
|<code>attack_cooling_down</code> | |||
|Boolean | |||
|false | |||
|- | |||
|<code>interaction_target</code> | |||
|LivingEntity | |||
|false | |||
|- | |||
|<code>breed_target</code> | |||
|AgeableMob | |||
|false | |||
|- | |||
|<code>ride_target</code> | |||
|Entity | |||
|false | |||
|- | |||
|<code>path</code> | |||
|Path | |||
|false | |||
|- | |||
|<code>doors_to_close</code> | |||
|Set<GlobalPos> | |||
|false | |||
|- | |||
|<code>nearest_bed</code> | |||
|BlockPos | |||
|false | |||
|- | |||
|<code>hurt_by</code> | |||
|DamageSource | |||
|false | |||
|- | |||
|<code>hurt_by_entity</code> | |||
|LivingEntity | |||
|false | |||
|- | |||
|<code>avoid_target</code> | |||
|LivingEntity | |||
|false | |||
|- | |||
|<code>nearest_hostile</code> | |||
|LivingEntity | |||
|false | |||
|- | |||
|<code>nearest_attackable</code> | |||
|LivingEntity | |||
|false | |||
|- | |||
|<code>hiding_place</code> | |||
|GlobalPos | |||
|false | |||
|- | |||
|<code>heard_bell_time</code> | |||
|Long | |||
|false | |||
|- | |||
|<code>cant_reach_walk_target_since</code> | |||
|Long | |||
|false | |||
|- | |||
|<code>golem_detected_recently</code> | |||
|Boolean | |||
|true | |||
|- | |||
|<code>danger_detected_recently</code> | |||
|Boolean | |||
|true | |||
|- | |||
|<code>last_slept</code> | |||
|Long | |||
|true | |||
|- | |||
|<code>last_woken</code> | |||
|Long | |||
|true | |||
|- | |||
|<code>last_worked_at_poi</code> | |||
|Long | |||
|true | |||
|- | |||
|<code>nearest_visible_adult</code> | |||
|LivingEntity | |||
|false | |||
|- | |||
|<code>nearest_visible_wanted_item</code> | |||
|ItemEntity | |||
|false | |||
|- | |||
|<code>nearest_visible_nemesis</code> | |||
|Mob | |||
|false | |||
|- | |||
|<code>play_dead_ticks</code> | |||
|Integer | |||
|true | |||
|- | |||
|<code>tempting_player</code> | |||
|Player | |||
|false | |||
|- | |||
|<code>temptation_cooldown_ticks</code> | |||
|Integer | |||
|true | |||
|- | |||
|<code>gaze_cooldown_ticks</code> | |||
|Integer | |||
|true | |||
|- | |||
|<code>is_tempted</code> | |||
|Boolean | |||
|true | |||
|- | |||
|<code>long_jump_cooling_down</code> | |||
|Integer | |||
|true | |||
|- | |||
|<code>long_jump_mid_jump</code> | |||
|Boolean | |||
|false | |||
|- | |||
|<code>has_hunting_cooldown</code> | |||
|Boolean | |||
|true | |||
|- | |||
|<code>ram_cooldown_ticks</code> | |||
|Integer | |||
|true | |||
|- | |||
|<code>ram_target</code> | |||
|Vec3 | |||
|false | |||
|- | |||
|<code>is_in_water</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>is_pregnant</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>is_panicking</code> | |||
|Boolean | |||
|true | |||
|- | |||
|<code>unreachable_tongue_targets</code> | |||
|List<UUID> | |||
|false | |||
|- | |||
|<code>visited_block_positions</code> | |||
|Set<GlobalPos> | |||
|true | |||
|- | |||
|<code>unreachable_transport_block_positions</code> | |||
|Set<GlobalPos> | |||
|true | |||
|- | |||
|<code>transport_items_cooldown_ticks</code> | |||
|Integer | |||
|false | |||
|- | |||
|<code>charge_cooldown_ticks</code> | |||
|Integer | |||
|true | |||
|- | |||
|<code>attack_target_cooldown</code> | |||
|Integer | |||
|true | |||
|- | |||
|<code>spear_fleeing_time</code> | |||
|Integer | |||
|false | |||
|- | |||
|<code>spear_fleeing_position</code> | |||
|Vec3 | |||
|false | |||
|- | |||
|<code>spear_charge_position</code> | |||
|Vec3 | |||
|false | |||
|- | |||
|<code>spear_engage_time</code> | |||
|Integer | |||
|false | |||
|- | |||
|<code>spear_status</code> | |||
|SpearStatus | |||
|false | |||
|- | |||
|<code>angry_at</code> | |||
|UUID | |||
|true | |||
|- | |||
|<code>universal_anger</code> | |||
|Boolean | |||
|true | |||
|- | |||
|<code>admiring_item</code> | |||
|Boolean | |||
|true | |||
|- | |||
|<code>time_trying_to_reach_admire_item</code> | |||
|Integer | |||
|false | |||
|- | |||
|<code>disable_walk_to_admire_item</code> | |||
|Boolean | |||
|false | |||
|- | |||
|<code>admiring_disabled</code> | |||
|Boolean | |||
|true | |||
|- | |||
|<code>hunted_recently</code> | |||
|Boolean | |||
|true | |||
|- | |||
|<code>celebrate_location</code> | |||
|BlockPos | |||
|false | |||
|- | |||
|<code>dancing</code> | |||
|Boolean | |||
|false | |||
|- | |||
|<code>nearest_visible_huntable_hoglin</code> | |||
|Hoglin | |||
|false | |||
|- | |||
|<code>nearest_visible_baby_hoglin</code> | |||
|Hoglin | |||
|false | |||
|- | |||
|<code>nearest_targetable_player_not_wearing_gold</code> | |||
|Player | |||
|false | |||
|- | |||
|<code>nearby_adult_piglins</code> | |||
|List<AbstractPiglin> | |||
|false | |||
|- | |||
|<code>nearest_visible_adult_piglins</code> | |||
|List<AbstractPiglin> | |||
|false | |||
|- | |||
|<code>nearest_visible_adult_hoglins</code> | |||
|List<Hoglin> | |||
|false | |||
|- | |||
|<code>nearest_visible_adult_piglin</code> | |||
|AbstractPiglin | |||
|false | |||
|- | |||
|<code>nearest_visible_zombified</code> | |||
|LivingEntity | |||
|false | |||
|- | |||
|<code>visible_adult_piglin_count</code> | |||
|Integer | |||
|false | |||
|- | |||
|<code>visible_adult_hoglin_count</code> | |||
|Integer | |||
|false | |||
|- | |||
|<code>nearest_player_holding_wanted_item</code> | |||
|Player | |||
|false | |||
|- | |||
|<code>ate_recently</code> | |||
|Boolean | |||
|false | |||
|- | |||
|<code>nearest_repellent</code> | |||
|BlockPos | |||
|false | |||
|- | |||
|<code>pacified</code> | |||
|Boolean | |||
|false | |||
|- | |||
|<code>roar_target</code> | |||
|LivingEntity | |||
|false | |||
|- | |||
|<code>disturbance_location</code> | |||
|BlockPos | |||
|false | |||
|- | |||
|<code>recent_projectile</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>is_sniffing</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>is_emerging</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>roar_sound_delay</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>dig_cooldown</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>roar_sound_cooldown</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>sniff_cooldown</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>touch_cooldown</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>vibration_cooldown</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>sonic_boom_cooldown</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>sonic_boom_sound_cooldown</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>sonic_boom_sound_delay</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>liked_player</code> | |||
|UUID | |||
|true | |||
|- | |||
|<code>liked_noteblock</code> | |||
|GlobalPos | |||
|true | |||
|- | |||
|<code>liked_noteblock_cooldown_ticks</code> | |||
|Integer | |||
|true | |||
|- | |||
|<code>item_pickup_cooldown_ticks</code> | |||
|Integer | |||
|true | |||
|- | |||
|<code>sniffer_explored_positions</code> | |||
|List<GlobalPos> | |||
|true | |||
|- | |||
|<code>sniffer_sniffing_target</code> | |||
|BlockPos | |||
|false | |||
|- | |||
|<code>sniffer_digging</code> | |||
|Boolean | |||
|false | |||
|- | |||
|<code>sniffer_happy</code> | |||
|Boolean | |||
|false | |||
|- | |||
|<code>breeze_jump_cooldown</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>breeze_shoot</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>breeze_shoot_charging</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>breeze_shoot_recover</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>breeze_shoot_cooldown</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>breeze_jump_inhaling</code> | |||
|Unit | |||
|true | |||
|- | |||
|<code>breeze_jump_target</code> | |||
|BlockPos | |||
|true | |||
|- | |||
|<code>breeze_leaving_water</code> | |||
|Unit | |||
|true | |||
|} | |||
'''Notes''' | |||
* Memory module types that are not serializable will not be saved when the entity is unloaded. | |||
* For memory module types of type Unit, the data stored, is the presence of the memory itself. For example, an entity is considered in water if the memory value for <code>is_in_water</code> is present. | |||
=== Sensor === | === Sensor === | ||
| Line 582: | Line 1,085: | ||
{{Reflist|group=sensor}} | {{Reflist|group=sensor}} | ||
=== | === Activities === | ||
An activity is essentially a phase within a mobs lifecycle. For example, some mobs, start with their idle activity, and switch to the fight activity as soon as an attack target is found. Once the attack target is defeated, the brain switches back to the idle activity. | |||
An activity itself does, however, not define a mobs behavior during the activity. For example, just because the fight activity is called fight, it does not make the mob fight other mobs. This behavior is handled by certain behavior controls associated with the activity. | |||
==== Core and default activities ==== | |||
A brain has two types of special activities: core activities and the default activity. | |||
Core activities are a set of activities that always run in the background. These contain basic behaviors such as trying to swim in water, looking at the current look target, or moving toward the current move target. By default, the set of core activities only includes the <code>core</code> activity. No mob changes this behavior. | |||
The default activity of a brain is used when the mob spawns. This defaults to the <code>idle</code> activity and usually includes behaviors such as randomly looking or walking around. Only the [[Minecraft:Breeze]] sets its default activity to the <code>fight</code> activity. [[Minecraft:Villager]]s can also temporarily set their default activity to <code>pre_raid></code> just before a [[Minecraft:Raid|raid]] or <code>raid</code> during a raid. | |||
Their default activity is reset to <code>idle</code> after the raid. | |||
==== Activity conditions ==== | |||
Within a brain, activities have conditions specifying when they can start. | |||
These conditions are specified as a list of memory module types and a memory status they must have. | |||
For example, the <code>fight</code> activity often requires that <code>attack_target</code> has a memory status of <code>VALUE_PRESENT</code> in order to start. This will be further discussed in the [[#Brain construction|brain construction]] and [[#Brain updates|brain updates]] section. | |||
==== List of activities ==== | |||
<!-- this table could perhaps also include the entities using the activities --> | |||
{|class= "wikitable collapsible collapsed" | |||
|+ List of activites {{in|JE}} | |||
|- | |||
!ID / name | |||
|- | |||
|<code>core</code> | |||
|- | |||
|<code>idle</code> | |||
|- | |||
|<code>work</code> | |||
|- | |||
|<code>play</code> | |||
|- | |||
|<code>rest</code> | |||
|- | |||
|<code>meet</code> | |||
|- | |||
|<code>panic</code> | |||
|- | |||
|<code>raid</code> | |||
|- | |||
|<code>pre_raid</code> | |||
|- | |||
|<code>hide</code> | |||
|- | |||
|<code>fight</code> | |||
|- | |||
|<code>celebrate</code> | |||
|- | |||
|<code>admire_item</code> | |||
|- | |||
|<code>avoid</code> | |||
|- | |||
|<code>ride</code> | |||
|- | |||
|<code>play_dead</code> | |||
|- | |||
|<code>long_jump</code> | |||
|- | |||
|<code>ram</code> | |||
|- | |||
|<code>tongue</code> | |||
|- | |||
|<code>swim</code> | |||
|- | |||
|<code>lay_spawn</code> | |||
|- | |||
|<code>sniff</code> | |||
|- | |||
|<code>investigate</code> | |||
|- | |||
|<code>roar</code> | |||
|- | |||
|<code>emerge</code> | |||
|- | |||
|<code>dig</code> | |||
|- | |||
|} | |||
=== Behaviors === | |||
{{hatnote|In this section, the terms '''behavior control''' and '''behavior''' have distinct meanings. See the behavior control hierarchy for more information}} | |||
Behavior controls define how a mob acts during an activity. For example, the <code>core</code> activity often contains the <code>Swim</code> behavior which instructs a mob to jump if it is in water. Behaviors are often given a priority, like goals in the goal system, allowing them start before lower prioritized behavior controls. | |||
Behavior Controls are not registered via a registry but are standalone classes within the games code. Behavior controls essentially run an action for a certain amount of time. Different types (subclasses) specify different durations. Each Behavior Control also has a status, stating whether it is currently running or not. | |||
==== Behavior control hierarchy ==== | |||
* <code>BehaviorControl</code> | |||
** <code>Behavior</code> | |||
*** <code>Swim</code> | |||
*** <code>MoveToTargetSink</code> | |||
*** <code>LookAtTargetSink</code> | |||
*** <code>RandomLookAround</code> | |||
*** <code>AnimalMakeLove</code> | |||
*** ''many more...'' | |||
** <code>OneShot</code> | |||
** <code>GateBehavior</code> | |||
*** <code>RunOne</code> | |||
** <code>DoNothing</code> | |||
===== Behavior ===== | |||
A behavior is the most common type of behavior control. They are simply actions that run for a random amount of ticks. All behaviors specify so called entry conditions, being memory module types and a memory status they must have. A behavior can only start if these entry conditions and some extra behavior-specific start conditions are fulfilled. The behavior then runs until its specified duration ends or a stop condition is fulfilled. | |||
''' Example: MoveToTargetSink ''' | |||
Entry Conditions: | |||
* <code>cant_reach_walk_target_since</code>: <code>REGISTERED</code> | |||
* <code>path</code>: <code>VALUE_ABSENT</code> | |||
* <code>walk_target</code>: <code>value_present</code> | |||
Description: The MoveToTargetSink behavior tries to reach the position stored in the <code>walk_target</code> memory by instructing the mobs path navigation. This behavior usually runs for 150 to 250 ticks. | |||
===== OneShot ===== | |||
A oneshot is a behavior control that runs within a single tick. It is an action that executes instantly. | |||
''' Example: MeleeAttack ''' | |||
Entry Conditions: | |||
* <code>look_target</code>: <code>REGISTERED</code> | |||
* <code>attack_target</code>: <code>VALUE_PRESENT</code> | |||
* <code>attack_cooling_down</code>: <code>VALUE_ABSENT</code> | |||
* <code>visible_mobs</code>: <code>VALUE_PRESENT</code> | |||
Description: Fires a melee attack at the current target stored in the <code>attack_target</code> memory and resets the <code>attack_cooldown</code> memory to a per mob-specific value. This all occurs within one tick. | |||
===== GateBehavior ===== | |||
A gate behavior is like a behavior but selects a subset of behavior controls to run from a given pool of weighted behavior controls. A gate behavior attempts to start as follows: | |||
# The entry conditions (required memories) for all behavior controls of the pool must be fulfilled. After passing this check, the gate behavior is already considered running. | |||
# The order policy is applied. Either <code>ORDERED</code>, which keeps the order in which the pool elements were specified, or <code>SHUFFLED</code> which randomizes the order. | |||
# The running policy is applied. Either <code>RUN_ONE</code> to find the first behavior control that will start, or <code>TRY_ALL</code> which will attempt to start all of them. | |||
The Gate behavior is considered done when all behavior controls within the gate behavior have stopped. | |||
====== RunOne ====== | |||
A RunOne behavior control is a gated behavior with <code>SHUFFLED</code> order policy and <code>RUN_ONE</code> running policy. | |||
In other words, given a list of weighted behavior controls, the RunOne behavior control will randomly select one of them to run. Most mobs use a RunOne behavior control during the <code>idle</code> activity for looking around and randomized movement. | |||
''' Example: '''RunOne structure used during the [[Minecraft:Creaking]]s <code>idle</code> activity: | |||
* <code>RandomStroll</code> (weight = 2) | |||
* <code>SetWalkTargetFromLookTarget</code> (weight = 2) | |||
* <code>DoNothing</code> (weight = 1) | |||
===== DoNothing ===== | |||
Essentially a behavior that does nothing for a random amount of time. Usually either 20 to 40 ticks long, or 30 to 60 ticks long, but some mobs deviate from these times. | |||
=== Brain construction === | |||
All entities using the brain system define a brain provider. The brain provider is like a blueprint for a brain. | |||
=== | A brain provider specifies: | ||
Memories are | * Required memory module types | ||
* Required sensor types | |||
* A list of activity data, where each activity data specifies: | |||
** An activity | |||
** The activity's memory status conditions | |||
** A list of behavior controls labeled with priorities, that can run during the activity | |||
** Memories to erase once the activity has completed | |||
[[File:Mob ai brain structure example goat.png|thumb|Overview of a [[goat]]s brain structure after spawning|alt=A structural overview depicting the internal components of a goats brain after spawning.]] | |||
The brain provider is then used on a per mob basis, to construct the mobs brain. | |||
The process is as follows: | |||
# The required memory module types specified in the brain provider are registered. | |||
# Each specified sensor is created, and the sensors required memory module types are registered. Each sensors is also randomly delayed here. | |||
# For all activity datas: | |||
## The specified memory module tpyes that are to be erased after the activity completes are stored. | |||
## The memory module types specified in the activity conditions are registered and stored. | |||
## Each behavior control's required memories are registered, then the behavior controls are stored in a tree-like structure with the ordering of priority -> activity -> behavior control. | |||
# Stored memories, from when the mob was saved, are restored. | |||
# The core activity set is set to only include the <code>core</code> activity. | |||
# The default activity (by default <code>idle</code>) is set as currently active. (<code>core</code> is implicitly also set active) | |||
=== Brain updates === | |||
A brain updates once every tick on the server side of the game. This involves ticking the brain, and a manual per-mob-specific decision, where the next activity is chosen. | |||
==== Brain tick ==== | |||
[[File:Mob ai brain tick overview.png|thumb|Visual overview of the brain tick process.|alt=Visual overview of the mob AI brain tick process.]] | |||
# '''Forget outdated memories''': Memories with a time-to-live decrease their lifetime by one tick. Memories that have already reached their end of life are forgotten. | |||
# '''Tick sensors''': All sensors tick. Note that sensors only actually update every scanRate amount of ticks. | |||
# '''Try to start non-running behaviors for active activities''': From highest to lowest priority, and for each active activity, each behavior control, that has a status of not running is attempted to start, starting from the highest priority. It is here that the priority comes into play. For example: a highly prioritized behavior control that sets the <code>walk_target</code> memory will cause a low priority behavior control to not start if that behavior control requires the <code>walk_target</code> memory to be absent. | |||
# '''Tick all running behaviors''': all behaviors that are running are ticked or stopped if done. | |||
==== Activity selection ==== | |||
After the brain has ticked, each entity decides on the next possible activity with a self-defined policy. Usually this just involves defining an order of activities, from which the first is chosen that fulfills its memory requirements. The <code>core</code> activity is also implicity added to the set of active activities. Note, that the activity change will also cause the brain to erase all memories that are specified for erasure by a previously active activity. Behavior controls of previous activities will also continue to run until they are done or reach a stop condition. | |||
Example: Order of activities defined by [[Minecraft:Piglin]]s: | |||
# <code>admire_item</code> | |||
# <code>fight</code> | |||
# <code>avoid</code> | |||
# <code>celebrate</code> | |||
# <code>ride</code> | |||
# <code>idle</code> | |||
The only entities to not use this approach are: | |||
* [[Minecraft:Axolotl]]: only applies the above method if the old activity is not <code>play_dead</code>. | |||
* [[Minecraft:Creaking]]: only applies the above method if it can move, otherwise uses the default activity. | |||
* [[Minecraft:Villager]]: activity updates are performed according to a schedule. | |||
== Control == | == Control == | ||
Latest revision as of 11:08, 8 September 2026
Template:For Template:WIP Template:Cleanup
This article describes the various components of a mob's AI that control its behavior.
Brain
Some mobs use a complex AI system called a brain. A mob's brain stores memories (data), a list of tasks that can be performed, and a list of sensors used to determine which tasks it can perform.
Memory
A brain stores data as memories. The type a memory represents is called the memory module type. The data itself is stored within a corresponding memory slot. Within the memory slot the data value can be empty, signaling that the memory is empty, or it can have a value signaling that the memory is present. Additionally the memory may have a time-to-live. The time-to-live indicates the number of ticks after which the memory is forgotten, and the memory value will become empty again. If the time-to-live is not specified, it is assumed to be infinite, i.e. the memory is permanent.
Memories are the only NBT-driven component of the brain system. To modify a mob's memories, the Template:Cmd command can be used. Note that this will erase all non-persistent memories and reset all activity and behavior states, as the mob's brain is completely reconstructed.
Example:
Executing this command with a Minecraft:warden as its target will cause the warden to immediately burrow. This is because the 60 second cooldown timer gets reduced to 0 ticks, causing the memory to expire in the next tick, at which the warden can initiate its despawning process.
Memory statuses
Registered memory module types can have three states in a brain:
REGISTERED: The brain contains a memory slot for the type.VALUE_PRESENT: The brain holds a value in the memory module type's corressponding memory slot.VALUE_ABSENT: The brain does not hold a value in the memory module type's corressponding memory slot.
These statuses will become relevant in the activity and behavior sections.
Memory module types
| ID | Data type | Serializable |
|---|---|---|
dummy
|
Void | false |
home
|
GlobalPos | true |
job_site
|
GlobalPos | true |
potential_job_site
|
GlobalPos | true |
meeting_point
|
GlobalPos | true |
secondary_job_site
|
List<GlobalPos> | false |
mobs
|
List<LivingEntity> | false |
visible_mobs
|
NearestVisibleLivingEntities | false |
visible_villager_babies
|
List<LivingEntity> | false |
nearest_players
|
List<Player> | false |
nearest_visible_player
|
Player | false |
nearest_visible_targetable_player
|
Player | false |
nearest_visible_targetable_players
|
List<Player> | false |
walk_target
|
WalkTarget | false |
look_target
|
PositionTracker | false |
attack_target
|
LivingEntity | false |
attack_cooling_down
|
Boolean | false |
interaction_target
|
LivingEntity | false |
breed_target
|
AgeableMob | false |
ride_target
|
Entity | false |
path
|
Path | false |
doors_to_close
|
Set<GlobalPos> | false |
nearest_bed
|
BlockPos | false |
hurt_by
|
DamageSource | false |
hurt_by_entity
|
LivingEntity | false |
avoid_target
|
LivingEntity | false |
nearest_hostile
|
LivingEntity | false |
nearest_attackable
|
LivingEntity | false |
hiding_place
|
GlobalPos | false |
heard_bell_time
|
Long | false |
cant_reach_walk_target_since
|
Long | false |
golem_detected_recently
|
Boolean | true |
danger_detected_recently
|
Boolean | true |
last_slept
|
Long | true |
last_woken
|
Long | true |
last_worked_at_poi
|
Long | true |
nearest_visible_adult
|
LivingEntity | false |
nearest_visible_wanted_item
|
ItemEntity | false |
nearest_visible_nemesis
|
Mob | false |
play_dead_ticks
|
Integer | true |
tempting_player
|
Player | false |
temptation_cooldown_ticks
|
Integer | true |
gaze_cooldown_ticks
|
Integer | true |
is_tempted
|
Boolean | true |
long_jump_cooling_down
|
Integer | true |
long_jump_mid_jump
|
Boolean | false |
has_hunting_cooldown
|
Boolean | true |
ram_cooldown_ticks
|
Integer | true |
ram_target
|
Vec3 | false |
is_in_water
|
Unit | true |
is_pregnant
|
Unit | true |
is_panicking
|
Boolean | true |
unreachable_tongue_targets
|
List<UUID> | false |
visited_block_positions
|
Set<GlobalPos> | true |
unreachable_transport_block_positions
|
Set<GlobalPos> | true |
transport_items_cooldown_ticks
|
Integer | false |
charge_cooldown_ticks
|
Integer | true |
attack_target_cooldown
|
Integer | true |
spear_fleeing_time
|
Integer | false |
spear_fleeing_position
|
Vec3 | false |
spear_charge_position
|
Vec3 | false |
spear_engage_time
|
Integer | false |
spear_status
|
SpearStatus | false |
angry_at
|
UUID | true |
universal_anger
|
Boolean | true |
admiring_item
|
Boolean | true |
time_trying_to_reach_admire_item
|
Integer | false |
disable_walk_to_admire_item
|
Boolean | false |
admiring_disabled
|
Boolean | true |
hunted_recently
|
Boolean | true |
celebrate_location
|
BlockPos | false |
dancing
|
Boolean | false |
nearest_visible_huntable_hoglin
|
Hoglin | false |
nearest_visible_baby_hoglin
|
Hoglin | false |
nearest_targetable_player_not_wearing_gold
|
Player | false |
nearby_adult_piglins
|
List<AbstractPiglin> | false |
nearest_visible_adult_piglins
|
List<AbstractPiglin> | false |
nearest_visible_adult_hoglins
|
List<Hoglin> | false |
nearest_visible_adult_piglin
|
AbstractPiglin | false |
nearest_visible_zombified
|
LivingEntity | false |
visible_adult_piglin_count
|
Integer | false |
visible_adult_hoglin_count
|
Integer | false |
nearest_player_holding_wanted_item
|
Player | false |
ate_recently
|
Boolean | false |
nearest_repellent
|
BlockPos | false |
pacified
|
Boolean | false |
roar_target
|
LivingEntity | false |
disturbance_location
|
BlockPos | false |
recent_projectile
|
Unit | true |
is_sniffing
|
Unit | true |
is_emerging
|
Unit | true |
roar_sound_delay
|
Unit | true |
dig_cooldown
|
Unit | true |
roar_sound_cooldown
|
Unit | true |
sniff_cooldown
|
Unit | true |
touch_cooldown
|
Unit | true |
vibration_cooldown
|
Unit | true |
sonic_boom_cooldown
|
Unit | true |
sonic_boom_sound_cooldown
|
Unit | true |
sonic_boom_sound_delay
|
Unit | true |
liked_player
|
UUID | true |
liked_noteblock
|
GlobalPos | true |
liked_noteblock_cooldown_ticks
|
Integer | true |
item_pickup_cooldown_ticks
|
Integer | true |
sniffer_explored_positions
|
List<GlobalPos> | true |
sniffer_sniffing_target
|
BlockPos | false |
sniffer_digging
|
Boolean | false |
sniffer_happy
|
Boolean | false |
breeze_jump_cooldown
|
Unit | true |
breeze_shoot
|
Unit | true |
breeze_shoot_charging
|
Unit | true |
breeze_shoot_recover
|
Unit | true |
breeze_shoot_cooldown
|
Unit | true |
breeze_jump_inhaling
|
Unit | true |
breeze_jump_target
|
BlockPos | true |
breeze_leaving_water
|
Unit | true |
Notes
- Memory module types that are not serializable will not be saved when the entity is unloaded.
- For memory module types of type Unit, the data stored, is the presence of the memory itself. For example, an entity is considered in water if the memory value for
is_in_wateris present.
Sensor
Sensors are used to detect if a mob with a brain can perform certain tasks. Examples of sensors include a sensor to detect if an armadillo should be scared, a sensor to detect the nearest player, and a sensor to detect if a mob is in water.
By default, sensors run once every Template:Convert, although individual sensor classes can have a different scan rate. When a sensor runs, it updates its targeting conditions to match the mob's current Template:Attr attribute before performing its targeting condition. The first execution of each sensor is delayed by a random number of ticks, preventing multiple sensors from running simultaneously; the random number is an integer between 0 (inclusive) and the scam rate (exclusive).
| Sensor | Class | Uses |
|---|---|---|
| dummy | DummySensor | default sensor type |
| nearest_items | NearestItemSensor | Template:Flatlist |
| mobs | NearestLivingEntitySensor | Template:Flatlist |
| nearest_players | PlayerSensor | Template:Flatlist |
| nearest_bed | NearestBedSensor | Template:EntityLink |
| hurt_by | HurtBySensor | Template:Flatlist |
| villager_hostiles | VillagerHostilesSensor | Template:EntityLink |
| villager_babies | VillagerBabiesSensor | Template:EntityLink |
| secondary_pois | SecondaryPoiSensor | Template:EntityLink |
| golem_detected | GolemSensor | Template:EntityLink |
| armadillo_scare_detected | MobSensor | Template:EntityLink |
| piglin_specific_sensor | PiglinSpecificSensor | Template:EntityLink |
| piglin_brute_specific_sensor | PiglinBruteSpecificSensorregister | Template:EntityLink |
| hoglin_specific_sensor | HoglinSpecificSensor | Template:EntityLink |
| nearest_adult | AdultSensor | Template:Flatlist |
| nearest_adult_any_type | AdultSensorAnyType | Template:EntityLink |
| axolotl_attackables | AxolotlAttackablesSensor | Template:EntityLink |
| food_temptations | TemptingSensor | Template:Flatlist |
| frog_temptations | TemptingSensor | Template:Flatlist |
| nautilus_temptations | TemptingSensor | Template:Flatlist |
| frog_attackables | FrogAttackablesSensor | Template:EntityLink |
| is_in_water | IsInWaterSensor | Template:EntityLink |
| warden_entity_sensor | WardenEntitySensor | Template:EntityLink |
| breeze_attack_entity_sensor | BreezeAttackEntitySensor | Template:EntityLink |
Sensor parameters
Some sensor classes have parameters, namely MobSensor and TemptingSensor. The list of parameters is below:
| Sensor | scanRate | mobTest | readyTest | toSet | memoryTimeToLive |
|---|---|---|---|---|---|
| Template:Cd | 5 | Armadillo.isScaredBy(Template:Mono):
|
Armadillo.canStayRolledUp():
Return true only if none of the following occurs to the armadillo:
|
Template:Cd | 80 |
| Sensor | temptations |
|---|---|
| Template:Cd | For each mob and item stack, test if the item is food for the mob. For mobs with these sensors, it means the item is tagged: |
| Template:Cd |
Check if the item is Minecraft:frog food (it's on the tag Template:Tag link), regardless of the mob. |
| Template:Cd |
Check if the item is Minecraft:nautilus food (it's on the tag Template:Tag link), regardless of the mob. |
Technically, all sensor classes have the scanRate parameter, which defines how many ticks the sensor runs. However, most vanilla sensors use the class's default scanRate value (20 by default, but this can change in certain classes; see below). The only sensor that sets its scanRate is Template:Cd.
Targeting condition
Many sensors need to filter entities based on certain tests. The test conditions can change depending on the sensor's objective.
Each targeting condition has the tags Template:Nbt, Template:Nbt, Template:Nbt, Template:Nbt and selector which are used to perform the test. The selector consists of a predicate that depends on the target, but it can be null.
For sensor targeting conditions, except TemptingSensor, the Template:Nbt is initially defined as Template:Cd, but it is updated to the value of the attribute Template:Attr before the sensor's doTick, selector is null, Template:Nbt is true when testing an attack target, Template:Nbt is false when the target is in the targeter's Template:Cd memory, and Template:Nbt is true.
The test value is a boolean value that depends on the target and the targeter (and can be null), both Minecraft:living entity such that:
- If target and targeter are the same entity, it returns false.
- If the target is not alive or is a player in Minecraft:Spectator mode or an invisible or marker Minecraft:armor stand, returns false.
- If the selector is not null, and the target is valid in the selector test, return false.
- If the targeter is null, Template:Nbt is true, and target is invulnerable, or the difficulty is Minecraft:peaceful, it returns false. The following points assume that targeter is not null.
- If Template:Nbt is true, the targeter can not attack the target or the targeter is allied to the target, return true. See below for more details.
- If Template:Nbt > 0 and the Minecraft:euclidean distance from targeter to target is greater than Template:Cd, it returns false.
- If Template:Nbt is false, the modifier is 1.0; else the modifier starts with Template:Cd (double) and is cumulative:
- Multiplying by Template:Cd if target is a Minecraft:sneaking player,
- Multiplying by Template:Cd if target is Minecraft:invisible and without equipament in Template:Tooltip,
- Multiplying by Template:Cd if target is invisible and has Template:Cd equipaments in humanoid armor slot,
- Multiplying by Template:Cd if target is using the corresponding mob Minecraft:head in the Template:Cd slot (for Minecraft:skeleton, Minecraft:zombie, Minecraft:piglin, Minecraft:piglin brute, and Minecraft:creeper)
- This depends on the component Template:DCL, more specifically, for each target's equipment slot s there is an item with the component Template:DCL equal to s, and the targeter is contained in Template:Cd, the modifier is multiplied by Template:Cd.Template:Upcoming
- The modifier is limited by Template:Cd.Template:Upcoming
- If Template:Nbt is false, the modifier is 1.0; else the modifier starts with Template:Cd (double) and is cumulative:
- If Template:Nbt is true, the targeter is a mob, and it is not possible to draw a straight line from the targeter's eye to the target without intersecting a block Minecraft:collision box, return false.
- If the mob is a Minecraft:ravager with a stunned tick or roar tick greater than 0, return false.
- Otherwise, it returns true.
Template:A The table below shows when the conditions of a living entity (the targeter) can not attack another (the target). At least one condition must be satisfied for it not to attack.
| Targeter | Can not attack if... |
|---|---|
| Template:EnvLink (except ender dragon and warden) |
|
| Template:EnvLink (except ender dragon and warden) |
|
| |
| Template:EntityLink |
|
| |
| |
| |
| |
| Template:EntityLink |
|
An entity A is an ally of an entity B if A = B, if A considers B as an ally, or if B considers A as an ally. The table below shows when one entity considers another as an ally:
| Targeter | Considers as ally if... |
|---|---|
|
The targeter and the target have a Minecraft:team, and it is the same team. | |
|
The Template:Tooltip is tame, and the owner is the target or considers the target as an ally. | |
|
The target is the Template:Tooltip linked player (has the Minecraft:UUID in memory Template:Cd). | |
|
The target entity type is in the tag Template:Tag link and the target and the targeter don't have a team. | |
| Template:EntityLink |
The target is a Minecraft:vex and the target root ownerTemplate:Fn is the Template:Tooltip or considers the Template:Tooltip as ally. |
Sensor classes
Sensors classes are responsible for detecting a specific type of information and storing the results in one or more memory modules in a mob's brain. In the game's code, these classes are part of the package Template:Cd
| Class | Memory requires | Do tick |
|---|---|---|
| DummySensor | None | Performs no actions |
| AdultSensor | Template:Cd and Template:Cd | Searches the Template:Cd memory for the nearest visible Minecraft:living entity of the same Minecraft:entity type as the mob that is not a Minecraft:baby. Stores the result in the Template:Cd memory.
If no matching adult is found, Template:Cd is set to empty. |
| AdultSensorAnyType |
When setting the nearest visible adult, it tests whether the entity is in the tag Template:Tag link, rather than whether it's in the same entity type as the mob. | |
| AxolotlAttackablesSensor | Template:Cd | Template:Hatnote
Searches the Template:Cd memory for the closest Minecraft:living entity that:
Stores the closest matching entity in the Template:Cd memory. |
| BreezeAttackEntitySensor | Template:Cd, Template:Cd | Template:Hatnote
Updates the Template:Cd and Template:Cd memories (by the super method). It then searches the Template:Cd memory for the attackable entityTemplate:Fn that is not a player in Minecraft:Creative mode or Minecraft:Spectator mode. Stores the first matching entity in the Template:Cd memory. If no matching entity is found, it removes the Template:Cd memory. |
| FrogAttackablesSensor | Template:Cd, Template:Cd | Template:Hatnote
Searches the Template:Cd memory for entity that:
Stores the closest matching entity in the Template:Cd memory. |
| GolemSensor | Template:Cd and Template:Cd | Searches the Template:Cd memory for an Minecraft:iron golem. If one is found, it sets the Template:Cd memory to true with an expiration time of Template:Convert.
scanRate: This sensor runs every Template:Convert by default. It only checks whether at least one iron golem is present. |
| HoglinSpecificSensor | Template:Cd, Template:Cd, Template:Cd, Template:Cd, Template:Cd | Searches the Template:Cd memory for visible adult Minecraft:piglins and Minecraft:hoglins.
Stores the nearest visible adult Minecraft:piglin in the Template:Cd memory and stores visible adult Minecraft:hoglins in the Template:Cd memory. It also stores the number of visible adult piglins and hoglins in the Template:Cd and Template:Cd memories. Searches for the nearest hoglin repellent block within 8 blocks horizontally and 4 blocks vertically, and stores its position in the Template:Cd memory. |
| HurtBySensor | Template:Cd and Template:Cd | Checks the mob's last damageSource.
|
| IsInWaterSensor | Template:Cd | Checks whether the mob is in Minecraft:water: the hitbox intersects the fluid in the Template:Tag link fluid tag, if the mob are on the Minecraft:boat, reduce the y-min of the hitbox; disregard heights below the height of the boat, except if the boat is underwater.
If it is, it sets the Template:Cd memory. Otherwise, it removes the Template:Cd memory. |
| MobSensor | Template:Cd |
If the sensor's readiness condition (readyTest) is met, it searches the Template:Cd memory for a Minecraft:living entity matching the sensor's predicate (mobTest). If a matching entity is found, it sets the sensor's memory (memoryTimeToLive) to |
| NearestBedSensor | Template:Cd | If the mob is a Minecraft:baby:
|
| NearestItemSensor | Template:Cd | Find the Template:Tooltip item that:
The nearest matching item is stored in the Template:Cd memory. If no matching item is found, the memory is set to empty. |
| NearestLivingEntitySensor | Template:Cd and Template:Cd | Template:A
Lists all other Minecraft:living entities that are alive and within a cuboid generated by the mob's hitbox expanded by its Template:Attr in all directions. Sorts the entities by Minecraft:Euclidean distance from the mob and stores the list in the Template:Cd memory. In Template:Cd, storesTemplate:Fn the entities from Template:Cd filtering entities using the mob's targeting conditionsTemplate:Fn |
| NearestVisibleLivingEntitySensor | Template:Cd and a memory defined by the subclass | Template:A Searches the Template:Cd memory for the closest Minecraft:living entity that matches the conditions defined by the subclass.
The matching entity is stored in the memory defined by the subclass. If no matching entity is found, the memory is set to empty. |
| PiglinBruteSpecificSensor | Template:Cd | Searches the Template:Cd memory for the nearest Minecraft:wither skeleton or Minecraft:wither and stores it in the Template:Cd memory.
Stores nearby adult Minecraft:piglins in the Template:Cd memory. |
| PiglinSpecificSensor | Template:Cd | Searches the Template:Cd memory and updates memories related to Minecraft:piglin behavior:
Searches the Template:Cd memory and stores adult Minecraft:piglins and Minecraft:piglin brutes in Template:Cd. Searches for the nearestTemplate:Fn block in the tag Template:Tag link in a box with 17 × 9 × 17 blocks centered on the piglins' position, and stores its position in Template:Cd. Not lit Minecraft:soul campfires are not considered repellents. |
| PlayerSensor | Template:Cd, Template:Cd, Template:Cd and Template:Cd | List all non-Minecraft:Spectator players that are within a Minecraft:Euclidean distance of the mob's Template:Attr. Sorts the players by distance from the mob and stores the list in Template:Cd.
From this list, it creates Template:Cd by filtering players using the mob's targeting conditionsTemplate:Fn. If the resulting list is not empty, stores the first player in Template:Cd. Creates Template:Cd by filtering Template:Cd's list using the mob's attack targeting conditionsTemplate:Fn. If the resulting list is not empty, the first player is stored in Template:Cd. |
| SecondaryPoiSensor | Template:Cd | Scans all blocks within a Template:Tooltip area centered on a villager. If a block matches one of the villager profession's secondary job site blocks, it stores its global position in the Template:Cd memory. It stores all matching blocks.
If no matching blocks are found, it removes the Template:Cd memory. scanRate: This sensor runs every Template:Convert instead of the default 20. |
| TemptingSensor | Template:Cd |
Searches for the Minecraft:player that:
If a matching player is found, it stores the nearest (by Minecraft:euclidean distance) player in the Template:Cd memory. Otherwise, it removes the Template:Cd memory. |
| VillagerBabiesSensor | Template:Cd | Finds all villagers that are babies from the mob's Template:Cd memory and stores them as a list in the Template:Cd memory.
If no visible baby villagers are found, stores an empty list. |
| VillagerHostilesSensor | Template:Cd and Template:Cd |
Template:Hatnote Searches the Template:Cd memory for the nearest Minecraft:living entity matching one of the following hostile entity types and stores it in the Template:Cd memory:
If no matching hostile entity is found, Template:Cd is set to empty. |
| WardenEntitySensor | Template:Cd, Template:Cd | Template:Hatnote
Updates the Template:Cd and Template:Cd memories (by the super method). It then searches the Template:Cd memory for the Template:Tooltip targetable Minecraft:player. If none is found, it searches for the Template:Tooltip targetable non-player Minecraft:living entity. In both cases, only entities that the warden can target are considered. Stores the first matching entity in the Template:Cd memory. If no matching entity is found, it removes the Template:Cd memory. |
Activities
An activity is essentially a phase within a mobs lifecycle. For example, some mobs, start with their idle activity, and switch to the fight activity as soon as an attack target is found. Once the attack target is defeated, the brain switches back to the idle activity.
An activity itself does, however, not define a mobs behavior during the activity. For example, just because the fight activity is called fight, it does not make the mob fight other mobs. This behavior is handled by certain behavior controls associated with the activity.
Core and default activities
A brain has two types of special activities: core activities and the default activity.
Core activities are a set of activities that always run in the background. These contain basic behaviors such as trying to swim in water, looking at the current look target, or moving toward the current move target. By default, the set of core activities only includes the core activity. No mob changes this behavior.
The default activity of a brain is used when the mob spawns. This defaults to the idle activity and usually includes behaviors such as randomly looking or walking around. Only the Minecraft:Breeze sets its default activity to the fight activity. Minecraft:Villagers can also temporarily set their default activity to pre_raid> just before a raid or raid during a raid.
Their default activity is reset to idle after the raid.
Activity conditions
Within a brain, activities have conditions specifying when they can start.
These conditions are specified as a list of memory module types and a memory status they must have.
For example, the fight activity often requires that attack_target has a memory status of VALUE_PRESENT in order to start. This will be further discussed in the brain construction and brain updates section.
List of activities
| ID / name |
|---|
core
|
idle
|
work
|
play
|
rest
|
meet
|
panic
|
raid
|
pre_raid
|
hide
|
fight
|
celebrate
|
admire_item
|
avoid
|
ride
|
play_dead
|
long_jump
|
ram
|
tongue
|
swim
|
lay_spawn
|
sniff
|
investigate
|
roar
|
emerge
|
dig
|
Behaviors
Behavior controls define how a mob acts during an activity. For example, the core activity often contains the Swim behavior which instructs a mob to jump if it is in water. Behaviors are often given a priority, like goals in the goal system, allowing them start before lower prioritized behavior controls.
Behavior Controls are not registered via a registry but are standalone classes within the games code. Behavior controls essentially run an action for a certain amount of time. Different types (subclasses) specify different durations. Each Behavior Control also has a status, stating whether it is currently running or not.
Behavior control hierarchy
BehaviorControlBehaviorSwimMoveToTargetSinkLookAtTargetSinkRandomLookAroundAnimalMakeLove- many more...
OneShotGateBehaviorRunOne
DoNothing
Behavior
A behavior is the most common type of behavior control. They are simply actions that run for a random amount of ticks. All behaviors specify so called entry conditions, being memory module types and a memory status they must have. A behavior can only start if these entry conditions and some extra behavior-specific start conditions are fulfilled. The behavior then runs until its specified duration ends or a stop condition is fulfilled.
Example: MoveToTargetSink
Entry Conditions:
cant_reach_walk_target_since:REGISTEREDpath:VALUE_ABSENTwalk_target:value_present
Description: The MoveToTargetSink behavior tries to reach the position stored in the walk_target memory by instructing the mobs path navigation. This behavior usually runs for 150 to 250 ticks.
OneShot
A oneshot is a behavior control that runs within a single tick. It is an action that executes instantly.
Example: MeleeAttack
Entry Conditions:
look_target:REGISTEREDattack_target:VALUE_PRESENTattack_cooling_down:VALUE_ABSENTvisible_mobs:VALUE_PRESENT
Description: Fires a melee attack at the current target stored in the attack_target memory and resets the attack_cooldown memory to a per mob-specific value. This all occurs within one tick.
GateBehavior
A gate behavior is like a behavior but selects a subset of behavior controls to run from a given pool of weighted behavior controls. A gate behavior attempts to start as follows:
- The entry conditions (required memories) for all behavior controls of the pool must be fulfilled. After passing this check, the gate behavior is already considered running.
- The order policy is applied. Either
ORDERED, which keeps the order in which the pool elements were specified, orSHUFFLEDwhich randomizes the order. - The running policy is applied. Either
RUN_ONEto find the first behavior control that will start, orTRY_ALLwhich will attempt to start all of them.
The Gate behavior is considered done when all behavior controls within the gate behavior have stopped.
RunOne
A RunOne behavior control is a gated behavior with SHUFFLED order policy and RUN_ONE running policy.
In other words, given a list of weighted behavior controls, the RunOne behavior control will randomly select one of them to run. Most mobs use a RunOne behavior control during the idle activity for looking around and randomized movement.
Example: RunOne structure used during the Minecraft:Creakings idle activity:
RandomStroll(weight = 2)SetWalkTargetFromLookTarget(weight = 2)DoNothing(weight = 1)
DoNothing
Essentially a behavior that does nothing for a random amount of time. Usually either 20 to 40 ticks long, or 30 to 60 ticks long, but some mobs deviate from these times.
Brain construction
All entities using the brain system define a brain provider. The brain provider is like a blueprint for a brain.
A brain provider specifies:
- Required memory module types
- Required sensor types
- A list of activity data, where each activity data specifies:
- An activity
- The activity's memory status conditions
- A list of behavior controls labeled with priorities, that can run during the activity
- Memories to erase once the activity has completed
The brain provider is then used on a per mob basis, to construct the mobs brain. The process is as follows:
- The required memory module types specified in the brain provider are registered.
- Each specified sensor is created, and the sensors required memory module types are registered. Each sensors is also randomly delayed here.
- For all activity datas:
- The specified memory module tpyes that are to be erased after the activity completes are stored.
- The memory module types specified in the activity conditions are registered and stored.
- Each behavior control's required memories are registered, then the behavior controls are stored in a tree-like structure with the ordering of priority -> activity -> behavior control.
- Stored memories, from when the mob was saved, are restored.
- The core activity set is set to only include the
coreactivity. - The default activity (by default
idle) is set as currently active. (coreis implicitly also set active)
Brain updates
A brain updates once every tick on the server side of the game. This involves ticking the brain, and a manual per-mob-specific decision, where the next activity is chosen.
Brain tick
- Forget outdated memories: Memories with a time-to-live decrease their lifetime by one tick. Memories that have already reached their end of life are forgotten.
- Tick sensors: All sensors tick. Note that sensors only actually update every scanRate amount of ticks.
- Try to start non-running behaviors for active activities: From highest to lowest priority, and for each active activity, each behavior control, that has a status of not running is attempted to start, starting from the highest priority. It is here that the priority comes into play. For example: a highly prioritized behavior control that sets the
walk_targetmemory will cause a low priority behavior control to not start if that behavior control requires thewalk_targetmemory to be absent. - Tick all running behaviors: all behaviors that are running are ticked or stopped if done.
Activity selection
After the brain has ticked, each entity decides on the next possible activity with a self-defined policy. Usually this just involves defining an order of activities, from which the first is chosen that fulfills its memory requirements. The core activity is also implicity added to the set of active activities. Note, that the activity change will also cause the brain to erase all memories that are specified for erasure by a previously active activity. Behavior controls of previous activities will also continue to run until they are done or reach a stop condition.
Example: Order of activities defined by Minecraft:Piglins:
admire_itemfightavoidcelebraterideidle
The only entities to not use this approach are:
- Minecraft:Axolotl: only applies the above method if the old activity is not
play_dead. - Minecraft:Creaking: only applies the above method if it can move, otherwise uses the default activity.
- Minecraft:Villager: activity updates are performed according to a schedule.
Control
Walking
Mob movement on land varies depending on whether it's hostile or passive. Hostile mobs will try to approach and attack the player when within their detection range, while most passive mobs will attempt to run away when attacked. Some mobs will also try to attack or run away from certain blocks or mobs.
Swimming
Mob swimming works the same way as walking, but in water. While most mobs will just float on water or sink, some can properly swim like Minecraft:fish, Minecraft:drowned, Minecraft:dolphins, Minecraft:turtles, Minecraft:guardians, and Minecraft:elder guardians.
Flying
Mob flying works the same way as walking, but in the air. Most mobs will just fall when suspended in air, with a few exceptions. Mobs with Minecraft:Slow Falling, Minecraft:levitation, and the Minecraft:chicken don't fly normally but can float in mid-air. [[Minecraft::Category:Flying mobs]] contains a list of all mobs that can pathfind in air.
Goals
Goals are a simple AI system used primarily by mobs that already existed before the brain AI. However, there are recent mobs that use both AIs simultaneously, for example, the Minecraft:happy ghast.
Goals can range from wandering around, opening doors, attacking another mob, and more. Each type of mob that uses goals has its own defined list of goals, and each goal has a priority. Mobs attempt to perform the lowest priority goal they can, and may switch goals if there is an opportunity to pursue a lower priority goal. For example, if a zombie is targeting and chasing a villager (priority of 3) and a player comes within the detection range of the zombie, the zombie may target and chase the player (priority of 2) instead.
List of goals
List of goals that are used by many different mobs.
| Goal | Description | Notes |
|---|---|---|
| Active Target | Select an entity to target for chasing and attacking | |
| Ambient Stand | Untamed horse bucks when player tries to ride it | |
| Attack | Attack target | |
| Attack with Owner | Tamed animal attacks a target mob attacked by owner | |
| Avoid Entity | Mob runs away from another mob that it is afraid of (e.g. skeletons running from wolves) | |
| Bow Attack | Attack target with bow | |
| Breathe Air | Mob that can drown tries to move out of water | |
| Cat Lie on Bed | Tamed cat lies down on bed | |
| Cat Sit on Block | Cat sits on bed, chest, or furnace | |
| Chase Boat | Chase after boat ridden by player | Unused |
| Crossbow Attack | Attack target with crossbow | |
| Destroy Egg | Destroy turtle eggs | |
| Disableable Follow Target | Raid entity stops following target | Unused |
| Dive Jump | Mob jumps up and dives down | |
| Dolphin Jump | Dolphin jumps out of water | |
| Door Interact | Mob tries to open a door | |
| Eat Grass | Mob grazes on grass | |
| Flee Sun | Move out of direct line-of-sight with sky during day | |
| Float | Mob floats in water | |
| Follow Flock Leader | Fish tries to follow the leader of a school of fish | |
| Follow Mob | Mob follows another mob | |
| Follow Owner | Tamed mob follows owner | |
| Follow Parent | Baby mob follows its parent | |
| Go to Walk Target | Mob walks to a target | |
| Hold in Hands | Mob holds an item in its main hand | |
| Horse Bond with Player | Horse attempts to bond with player attempting to tame it | |
| Iron Golem Look | Iron golem looks at a villager | |
| Iron Golem Wander Around | Iron golem wanders around village | uses points of interest |
| Llama Follow Caravan | Llamas form and follow a caravan | |
| Leap At Target | Mob jumps towards target | cats, foxes, ocelots, spiders |
| Long Door Interact | Open a door, then close it after a delay | |
| Look At Entity | Mob looks at another mob | |
| Look At Player | Mob looks at player | |
| Look At Trading Player | Villager or wandering trader looks at player while trading | |
| Melee Attack | Mob paths to target and attacks | |
| Move Into Water | Mob paths to water | |
| Move Through Village | Mob moves between points of interest in a village | |
| Move To Raid Center | Raiders move toward village after spawning | |
| Move To Target Position | Mob paths to a specific block | |
| Panic | Mob panics and runs away when damaged | |
| Powder Snow Jump | Mob dives into powder snow | foxes |
| Prioritized Goal | Used to override the default priority of a goal | |
| Projectile Attack | Mob attacks target with a projectile | arrow, spit, trident, potion, snow ball, wither skull, not fireballs |
| Raid Goal | Raiders target villagers | |
| Random Look Around | Mob looks around in random directions | |
| Random Stroll | Move to a nearby random position | |
| Revenge | Target entity that attacked the mob | |
| Run Around Like Crazy | Untamed horse runs around randomly when ridden by a player | |
| Spear Use | Mob attacks target with spear | |
| Swell | Creeper attempts to explode near its target | |
| Tempt | Mob follows player holding breeding item | |
| Water Avoiding Random Stroll | Move to a nearby random position, while actively avoiding water | |
| Wander Around Far | Move to a random position, sometimes farther away than Wander Around goal | |
| Zombie Attack | Attack goal for zombies and zombie variants |
Lists of mob goals
Lists of goals and associated priorities for individual mobs.
| Goal | Priority | Notes |
|---|---|---|
| Revenge | 1 | Attack entity that damaged the zombie |
| Active Target - Player | 2 | Target the player |
| Zombie Attack | 2 | Attack current target |
| Active Target - Iron Golem | 3 | Target Iron Golem |
| Active Target - Merchant | 3 | Target Villager or Wandering Trader |
| Destroy Egg | 4 | Break turtle eggs |
| Active Target - Turtle | 5 | Target baby turtle |
| Wander Around Far | 7 | |
| Look Around | 8 | Looks away from Entities |
| Look at Entity | 8 | Looks at nearest Entities |
Pathfinding
Pathfinding is the system used by mobs to navigate through the world. Mobs that use pathfinding calculate routes through the environment and follow these routes using their navigation system. Different mobs use different types of navigation depending on their movement abilities, such as Minecraft:walking, Minecraft:swimming, or Minecraft:flying.
The default navigation type for mobs is ground path navigation, although individual mobs can replace it with a different navigation implementation.
Pathfinding is controlled by a mob's AI. Goals and behaviors can request movement to a location or entity, causing the mob's navigation system to calculate and follow a path. The navigation system is updated every Minecraft:tick while the mob's AI is active.
A mob is considered to be pathfinding when its navigation system has an active path. The path ends when the mob reaches its destination, the path becomes invalid, or the navigation is stopped.
The navigation system controls how mobs follow paths after they have been calculated.
A navigation system stores the mob's current path, movement speed, and destination. During each AI update, the navigation system checks the current path, advances through nodes that have been reached, and sends movement instructions to the mob's movement controls.
Navigation can be stopped manually, which clears the mob's current path. A mob is considered to be navigating when it has an active path that has not been completed.
Different mobs use different navigation systems depending on their movement type. Ground mobs generally use ground navigation, while Minecraft:aquatic and [[Minecraft::Category:Flying mobs|flying mobs]] use specialized navigation systems.
Navigation systems can also perform checks while moving, such as:
- When a mob becomes stuck.
- Recalculating paths when needed.
- Whether a mob can move directly between two points.
- Adjusting paths around certain blocks.
Path following
After a path is created, mobs follow the path by moving from node to node. A node represents a position that the mob must reach while traveling.
A mob advances to the next node when it is close enough to its current node. Some paths allow mobs to skip nodes when moving directly toward a later point would be safe.
While following a path, mobs can become stuck if they fail to make sufficient progress. The navigation system checks movement over time and stops the path if the mob cannot continue.
Pathfinding penalties
When pathfinding to a target, mobs will sometimes avoid certain blocks (usually blocks that cause damage or slow the mob down). These blocks have a penalty associated with them. Generally, mobs try to path through blocks with the smallest penalty. There are some blocks that most mobs cannot path through; these all have a penalty of -1.
The following table is a list of all pathfinding penalties and their default values. Each type of pathfinding (land, water, air) uses its own subset of these penalties. Some mobs override these default values.
| Penalty type | Penalty | Description |
|---|---|---|
| blocked | -1 | can't pathfind through block (most full solid blocks) |
| powder snow | -1 | Template:BlockLink |
| fence | -1 | Template:BlockLink Template:BlockLink Template:BlockLink (closed) |
| lava | -1 | Template:BlockLink |
| unpassable rail | -1 | Template:BlockLink |
| damage - other | -1 | Template:BlockLink Template:BlockLink |
| closed wood door | -1 | Template:BlockLink |
| closed iron door | -1 | Template:BlockLink |
| open | 0 | Template:BlockLink Template:BlockLink Template:BlockLink |
| walkable | 0 | Template:BlockLink with pressure plate on top (under the mob) |
| walkable door | 0 | a door the mob can open |
| trapdoor | 0 | Template:BlockLink Template:BlockLink Template:BlockLink |
| danger - powder snow | 0 | neighboring block is Template:BlockLink |
| open door | 0 | open wood or iron door |
| cocoa | 0 | Template:BlockLink |
| damage - cautious | 0 | Template:BlockLink Template:BlockLink |
| danger - trapdoor | 0 | neighboring block is Template:BlockLink |
| breach water | 4 | there is an air block above a water block |
| water | 8 | Template:BlockLink |
| water border | 8 | neighboring block is Template:BlockLink |
| danger - fire | 8 | neighboring block is: Template:BlockLink Template:BlockLink Template:BlockLink Template:BlockLink Template:BlockLink |
| danger - other | 8 | neighboring block is: Template:BlockLink Template:BlockLink |
| honey | 8 | Template:BlockLink |
| damage - fire | 16 | Template:BlockLink Template:BlockLink Template:BlockLink Template:BlockLink Template:BlockLink |
- Mob pathfinding penalty overrides
The following mobs override the default pathfinding penalty for some blocks:
| Mob | Penalty Type | Penalty |
|---|---|---|
| Template:EntityLink | water | 0 |
| Template:EntityLink | damage - fire | -1 |
| water | -1 | |
| cocoa | -1 | |
| fence | -1 | |
| water border | 16 | |
| Template:EntityLink | water | 0 |
| Template:EntityLink | danger - other | 0 |
| damage - other | 0 | |
| Template:EntityLink | trapdoor | -1 |
| water | 4 | |
| Template:EntityLink | powder snow | -1 |
| danger - powder snow | -1 | |
| Template:EntityLink Template:EntityLink |
damage-fire | -1 |
| danger - fire | 16 | |
| Template:EntityLink | danger-fire | -1 |
| damage - fire | -1 | |
| cocoa | -1 | |
| Template:EntityLink | water | -1 |
| danger - powder snow | -1 | |
| damage - cautious | -1 | |
| Template:EntityLink | water | -1 |
| lava | 0 | |
| danger - fire | 0 | |
| damage - fire | 0 | |
| Template:EntityLink | close iron door | -1 |
| closed wood door | -1 | |
| open door | -1 | |
| water | 0 | |
| Template:EntityLink | powder snow | -1 |
| danger - powder snow | -1 | |
| Template:EntityLink Template:EntityLink |
damage - fire | -1 |
| danger - fire | 16 | |
| Template:EntityLink | water | -1 |
| danger - fire | 8 | |
| damage - fire | 8 | |
| lava | 8 | |
| Template:EntityLink | danger - trapdoor | -1 |
| damage - fire | -1 | |
| Template:EntityLink | water | 0 |
| Template:EntityLink | water | -1 |
| Template:EntityLink | water | 0 |
| Template:EntityLink | leaves | 0 |
| Template:EntityLink | unpassable rail | 0 |
| damage - fire | 0 | |
| danger - fire | 0 | |
| damage - other | 8 | |
| powder snow | 8 | |
| lava | 8 | |
| water creatures | water | 0 |
| Template:EntityLink | lava | 8 |
| Template:EntityLink | lava | 8 |
| animal | damage - fire | -1 |
| danger - fire |
Pathfinding on land
- All entities move based on random targets that are generated every tick with a priority toward their entity-specific goals.
- These targets can be located anywhere in 3D space within the entity range and are only generated when wandering or when they have no goals.
- For every target, a path is generated; with the entity preferring the path with the lowest score regarding the Pathfinding penalties.
- If an entity cannot take any paths with a low enough score, or any paths without a score of -1, the entity will not move until one is found.
- If an entity's target is located inside a block (including water), the target is moved to the nearest air block above it.
This means every entity, when wandering, will always prefer to pathfind to a block with the most blocks below it within range.
Due to the higher chance that a target will be generated within the blocks below it and moved up to the nearest air block above before generating a path.
Pathfinding in water
- Pathfinding in water is roughly the same as land; however, most entities, excluding fish and drowned, will bounce on the surface, preferring land due to the Pathfinding penalties of water.
Pathfinding in air
- Pathfinding in air is roughly the same as land; however, few entities can pathfind to air.
See also
Template:Navbox Java Edition technical
Minecraft:de:Künstliche Intelligenz Minecraft:ja:Mob AI Minecraft:pt:IA de criatura Minecraft:zh:生物AI