How Bedrock Handles Team Allegiances
Bedrock Edition has a global `pvp` game rule, which disables all player-versus-player damage across the entire world when set to false. However, if you want Red Team players to hurt Blue Team players while sparing their own Red Team members—or if you want custom guard mobs to ignore accidental hits from their owners—the global game rule is too blunt.
To create distinct teams, add-on developers rely on two main grouping mechanisms: type families (`minecraft:type_family`) and entity tags (`/tag`). Type families are defined statically in the entity JSON or swapped dynamically via component groups. Tags can be applied at any time in-game using commands or script APIs, making them the preferred method when assigning players to teams on the fly.
Once your entities are grouped by a family or a tag, the `minecraft:damage_sensor` component acts as the gatekeeper. It intercepts incoming damage, evaluates a filter against the attacking entity (`other`), and cancels the damage before health is deducted.
Using Type Families for Mob Factions
If you are creating custom mobs that belong to fixed factions—such as a team of soldiers that use area-of-effect attacks or ranged projectiles that might accidentally hit allies—assigning a shared family in `minecraft:type_family` is the cleanest approach.
In the example below, the custom soldier belongs to the `red_team` family. Its `minecraft:damage_sensor` listens for any attack where the `other` subject (the attacker) also belongs to the `red_team` family. When the filter matches, `deals_damage` is set to `false`, completely negating both the health loss and the knockback.
{
"format_version": "1.20.80",
"minecraft:entity": {
"description": {
"identifier": "custom:red_soldier",
"is_spawnable": true,
"is_summonable": true
},
"components": {
"minecraft:type_family": {
"family": [
"red_team",
"monster",
"mob"
]
},
"minecraft:health": {
"value": 20,
"max": 20
},
"minecraft:damage_sensor": {
"triggers": [
{
"on_damage": {
"filters": {
"test": "is_family",
"subject": "other",
"value": "red_team"
}
},
"deals_damage": false
}
]
}
}
}
}Using Tags for Dynamic Player and Mob Teams
Players cannot have their `minecraft:type_family` changed through commands without modifying `BP/entities/player.json` and setting up events and component groups for every possible team. A much more flexible approach for both players and mobs is using the `has_tag` filter test.
By placing a `minecraft:damage_sensor` in `BP/entities/player.json` (or on your custom mobs), you can check if both the victim (`self`) and the attacker (`other`) share the same gameplay tag. If both entities have the `team_blue` tag, the damage is ignored.
This setup requires you to include multiple triggers in the damage sensor—one for each team tag supported by your map or add-on. You can then assign teams in-game using standard commands like `/tag @p add team_blue`.
| Property | What it does | Notes |
|---|---|---|
| deals_damage | Controls whether the incoming hit reduces health and applies knockback. | Accepts true or false. In newer format versions, also accepts strings like "no" or "no_but_side_effects_apply". |
| subject: "self" | Evaluates the filter against the entity receiving the damage. | Default subject if omitted, but best declared explicitly when pairing with "other". |
| subject: "other" | Evaluates the filter against the entity that caused the damage. | Works for both direct melee attacks and projectiles where the shooter is tracked as the damage source. |
{
"format_version": "1.20.80",
"minecraft:entity": {
"description": {
"identifier": "minecraft:player",
"is_spawnable": false,
"is_summonable": false
},
"components": {
"minecraft:damage_sensor": {
"triggers": [
{
"on_damage": {
"filters": {
"all_of": [
{
"test": "has_tag",
"subject": "self",
"value": "team_red"
},
{
"test": "has_tag",
"subject": "other",
"value": "team_red"
}
]
}
},
"deals_damage": false
},
{
"on_damage": {
"filters": {
"all_of": [
{
"test": "has_tag",
"subject": "self",
"value": "team_blue"
},
{
"test": "has_tag",
"subject": "other",
"value": "team_blue"
}
]
}
},
"deals_damage": false
}
]
}
}
}
}Preventing Tamed Mob Friendly Fire
Another common form of team damage is a player accidentally striking their own tamed pet or summoned minion during combat. While you can use teams or tags, Bedrock provides a dedicated filter test called `is_owner` specifically for entities tamed via `minecraft:tameable`.
When you test `is_owner` with the subject set to `other`, the game checks if the attacker's Unique ID matches the owner ID stored on the mob. Setting `deals_damage` to `false` on this trigger ensures the owner can swing a sword in tight quarters without hurting their companion.
{
"format_version": "1.20.80",
"minecraft:entity": {
"description": {
"identifier": "custom:companion",
"is_spawnable": true,
"is_summonable": true
},
"components": {
"minecraft:damage_sensor": {
"triggers": [
{
"on_damage": {
"filters": {
"test": "is_owner",
"subject": "other",
"value": true
}
},
"deals_damage": false
}
]
}
}
}
}Stopping AI Retaliation
Setting `deals_damage` to `false` stops health loss, knockback, and the red hurt flash, but you must also make sure your custom mobs do not try to target teammates to begin with. If a mob has `minecraft:behavior.hurt_by_target`, a cancelled hit with `deals_damage: false` generally will not trigger retaliation because the damage event never completes.
However, if you use `deals_damage: "no_but_side_effects_apply"` (or if your mob uses `minecraft:behavior.nearest_attackable_target`), the mob might still aggro onto its allies. Always mirror your team exclusions inside your AI targeting filters using `operator: "not"` or `operator: "!="` so the mob never selects a teammate as a valid target.
{
"minecraft:behavior.hurt_by_target": {
"priority": 1,
"entity_types": [
{
"filters": {
"test": "is_family",
"subject": "other",
"operator": "!=",
"value": "red_team"
}
}
]
}
}Which versions this applies to
Applies to all modern Bedrock versions (1.16.0 through 1.21+). The `minecraft:damage_sensor`, `minecraft:type_family`, and filter tests (`is_family`, `has_tag`, `is_owner`) are completely stable and do not require any experimental toggles.
When it does not work
| What you see | Why | The fix |
|---|---|---|
| Teammates still take damage from each other despite the damage_sensor being present. | The filter inside `on_damage` omitted `"subject": "other"`. Because the default filter subject is `"self"`, the entity was only checking if it belonged to its own team, which caused the logic to fail when paired with opposing checks or misconfigured conditions. | Explicitly add `"subject": "other"` to the filter testing the attacker's family or tag. |
| Content Log Error: [Json][error] Failed to parse filter, unknown test 'has_tags'. | Filter test names are strict and singular. Writing `has_tags` or `is_families` will fail schema validation and break the component. | Use the exact singular test names: `"test": "has_tag"` and `"test": "is_family"`. |
| Player team damage works at first, but breaks or resets when the player equips custom armor or triggers another add-on mechanic. | You modified `BP/entities/player.json` by pasting only the `minecraft:damage_sensor` component instead of starting from the full vanilla `player.json` file, or a second behavior pack in the world also overrides `player.json`. | Always copy the complete vanilla `player.json` file before adding your custom triggers, and merge any `minecraft:damage_sensor` triggers into a single `triggers` array. |
Reference, straight from the game files
Read out of the game itself, so the ids match the version you are building for.