How to Make a Custom Mob in Minecraft Bedrock with Blockbench (2026)

The short answer

A new Bedrock mob is split across two packs. The Behavior Pack owns the entity's logic and spawning. The Resource Pack owns the model, texture, materials, render controllers, and visual animations. Both sides must use the same namespaced entity identifier.

We will create Mossling with the identifier icedfox:mossling. Start with a summonable, visible, walking entity. Add natural spawning and advanced animations only after that base works.

Understand the file map

Mossling_BP/
  manifest.json
  entities/
    mossling.json
  spawn_rules/
    mossling.json

Mossling_RP/
  manifest.json
  entity/
    mossling.entity.json
  models/entity/
    mossling.geo.json
  textures/entity/
    mossling.png
  animations/
    mossling.animation.json
  animation_controllers/
    mossling.animation_controller.json
  texts/
    en_US.lang
    languages.json

The animation files are optional for the first summon test. A static model is easier to debug than a model, controller, Molang expression, and behavior file all failing at once.

Step 1: create the model with Entity Wizard

1. Open Blockbench and install Minecraft Entity Wizard from the Plugins window.
2. Choose Create Bedrock Entity.
3. Set the display name to Mossling and the identifier to icedfox:mossling.
4. Choose a vanilla appearance and behavior close to the creature you want. Matching presets reduce animation and behavior conflicts.
5. Export to your development packs or integrate into an existing addon.
6. Use Edit Model to change geometry, texture, pivots, and animations.

Step 2: build the Behavior Pack entity

The server-side entity defines health, collision, movement, navigation, and AI goals. This minimal creature wanders and looks at nearby players.

{
  "format_version": "1.21.0",
  "minecraft:entity": {
    "description": {
      "identifier": "icedfox:mossling",
      "is_spawnable": true,
      "is_summonable": true,
      "is_experimental": false
    },
    "components": {
      "minecraft:physics": {},
      "minecraft:collision_box": {
        "width": 0.8,
        "height": 1.1
      },
      "minecraft:health": {
        "value": 20,
        "max": 20
      },
      "minecraft:movement": {
        "value": 0.2
      },
      "minecraft:movement.basic": {},
      "minecraft:navigation.walk": {
        "can_path_over_water": false,
        "avoid_water": true
      },
      "minecraft:jump.static": {},
      "minecraft:behavior.look_at_player": {
        "priority": 6,
        "look_distance": 8,
        "probability": 0.08
      },
      "minecraft:behavior.random_stroll": {
        "priority": 7,
        "speed_multiplier": 1
      },
      "minecraft:behavior.random_look_around": {
        "priority": 8
      }
    }
  }
}

AI goals use priorities: lower numbers win when multiple goals can run. Build a small, understandable behavior stack before adding temptation, panic, combat, breeding, interaction, sensors, or component groups.

Step 3: connect the visual files

The Resource Pack client entity maps friendly aliases to the actual texture and geometry resources.

{
  "format_version": "1.10.0",
  "minecraft:client_entity": {
    "description": {
      "identifier": "icedfox:mossling",
      "materials": {
        "default": "entity_alphatest"
      },
      "textures": {
        "default": "textures/entity/mossling"
      },
      "geometry": {
        "default": "geometry.mossling"
      },
      "render_controllers": [
        "controller.render.default"
      ],
      "spawn_egg": {
        "base_color": "#4E7C45",
        "overlay_color": "#B9D77A"
      }
    }
  }
}

The geometry value must match the identifier inside mossling.geo.json, not merely the file name. Texture paths omit .png. The client and behavior entity identifiers must be identical.

Step 4: add names for the mob and spawn egg

Add en_US to texts/languages.json, then include both translation keys:

entity.icedfox:mossling.name=Mossling
item.spawn_egg.entity.icedfox:mossling.name=Spawn Mossling

Step 5: run the first summon test

1. Activate both packs in a disposable world with cheats.
2. Run /summon icedfox:mossling ~ ~ ~.
3. Confirm the model, texture, collision, gravity, and movement.
4. Use the spawn egg from Creative inventory.
5. Walk around obstacles and shallow water to inspect navigation.
6. Damage and kill the entity to verify health and cleanup.
7. Check the Content Log after every failed test.

If the summon command fails, debug the Behavior Pack. If an invisible entity collides, moves, or makes sounds, the behavior side loaded and the visual references are failing.

Step 6: add natural spawning

Only add spawn rules after manual summoning works. This example spawns Mosslings on the surface in forest-tagged biomes during brighter conditions.

{
  "format_version": "1.8.0",
  "minecraft:spawn_rules": {
    "description": {
      "identifier": "icedfox:mossling",
      "population_control": "animal"
    },
    "conditions": [
      {
        "minecraft:spawns_on_surface": {},
        "minecraft:brightness_filter": {
          "min": 9,
          "max": 15,
          "adjust_for_weather": true
        },
        "minecraft:weight": {
          "default": 35
        },
        "minecraft:herd": {
          "min_size": 1,
          "max_size": 3
        },
        "minecraft:biome_filter": {
          "test": "has_biome_tag",
          "operator": "==",
          "value": "forest"
        }
      }
    ]
  }
}

Population control shares a cap with other entities in that pool. A high weight does not guarantee constant spawns if the relevant pool is already full or the biome conditions never match.

Add animations after the entity is stable

Animations store bone movement. Animation controllers decide when those animations play. The client entity references both and uses Molang queries to select states such as idle, walking, attacking, sleeping, or transforming.

Keep the first controller to two states: idle and walk. Once transitions are reliable, add attack, hurt, special ability, or ambient states. The complete setup is covered in the Bedrock animation controllers guide.

Common custom mob problems

The mob is invisible

Match the behavior and client identifiers. Then verify texture path, geometry identifier, material, render controller, and Resource Pack activation. An invisible mob with collision usually means the Resource Pack side failed.

The mob falls through the world

Add or correct minecraft:physics and collision. Also inspect the model origin and collision-box size.

The mob stands still

Movement value alone is not enough. The entity needs a movement component, compatible navigation, and an AI goal that asks it to move.

The mob moves but slides in a T-pose

The behavior is fine; the animation wiring is not. Check the animation file identifier, controller reference, scripts.animate, and Molang transition conditions.

The mob never spawns naturally

Confirm manual summoning first. Then check spawn-rule identifier, population pool, biome tag, surface/water rule, brightness, weight, and whether the world has space in that population pool.

The mob attacks or targets the wrong entities

Inspect target acquisition and attack goals separately. Add filters that express exactly which families, entities, or conditions qualify rather than relying on broad defaults.

Before releasing the mob

• Test single-player and multiplayer ownership of interactions and damage.
• Verify spawn density in several biomes and over longer play sessions.
• Check collision in doors, slabs, water, slopes, and tight structures.
• Test every animation transition repeatedly and at different movement speeds.
• Add sensible loot, sounds, name translations, and player-facing documentation.
• Confirm the addon does not override vanilla identifiers or require undocumented experiments.

Frequently asked questions

Can Blockbench create all the mob behavior?

Entity Wizard generates a useful starting behavior, appearance, and pack structure. More advanced AI, events, component groups, combat, spawning, and scripts still require editing and testing the exported addon.

Can one mob have several textures or models?

Yes. Render controllers can choose resources using Molang and entity properties. Begin with one model and texture so each later variation has a known-good baseline.

Should I copy a vanilla entity file?

Vanilla samples are valuable references, but remove systems your mob does not need and keep your own identifier. Copying a large entity unchanged creates hidden behavior and maintenance work.

Official sources checked

• Microsoft Learn: Creating New Entity Types
• Microsoft Learn: Minecraft Entity Wizard
• Microsoft Learn: Behaviors and Render Controllers
• Microsoft Learn: Troubleshooting Add-on Bugs

Continue building

• Minecraft Bedrock Animation Controllers Guide
• Make a Custom Item in Minecraft Bedrock
• Bedrock manifest.json Guide
• Bedrock Addon Debugging Checklist