Bedrock Protocol

Unlike architectures that rely on TCP, Minecraft Bedrock communicates over UDP using the RakNet protocol library. RakNet provides reliability and ordering streams on top of standard UDP datagrams, allowing the game to send high-priority events reliably while letting continuous movement updates drop if a packet arrives too late. Every singleplayer world actually runs an internal server, meaning your add-on is always operating across this network boundary even when only one person is playing.

When a player joins a server, the protocol runs through a strict handshake and login sequence before any world chunks or entity actors are spawned. During this handshake, the server informs the client about the required resource packs and behavior pack definitions. If you mandate resource packs in your server configuration, the protocol handles chunking and streaming those zip archives directly over the game connection before the player's entity is initialized in the dimension.

A common misconception among new creators is that the entire behavior pack is downloaded by joining clients. In reality, the server retains almost all behavior logic—such as loot tables, spawn rules, AI goals, and server scripts—on the host machine. The client only receives the visual and structural half of the contract: resource packs for textures, geometries, and sounds, along with lightweight registry tables for custom blocks, items, and entity identifiers.

When the world initializes, the server compiles registries of block permutations and item components and transmits them in startup synchronization packets. For example, if you define a custom block with `minecraft:geometry` and `minecraft:material_instances`, the server sends the block's runtime state IDs and visual component payloads to the client so it knows how to render the block and calculate client-side collision prediction. Server-only behavior components, or your custom Script API handlers, never leave the host.

Because the client handles all rendering, animations, and Molang evaluations for visuals, you frequently need a way to send custom server-side state across the protocol to trigger a client-side effect. Historically, creators abused vanilla actor flags (like `minecraft:is_baby` or `minecraft:is_sheared`) or `minecraft:variant` components to smuggle integers to the client. Modern Bedrock replaces that pattern with Entity Properties declared in the behavior pack entity description.

When you define a property inside the `properties` object of a `minecraft:entity` definition, you control whether the Bedrock Protocol serializes it into actor data packets using the `client_sync` boolean. If `client_sync` is `false`, the property stays entirely in server memory and costs zero network bandwidth. Setting `client_sync` to `true` instructs the server to include the property in the initial entity spawn packet and broadcast delta packets whenever its value changes, making it readable by client-side Molang queries via `q.property()`.

{
  "format_version": "1.20.80",
  "minecraft:entity": {
    "description": {
      "identifier": "wiki:networked_turret",
      "is_spawnable": true,
      "is_summonable": true,
      "properties": {
        "wiki:charge_level": {
          "type": "int",
          "range": [0, 100],
          "default": 0,
          "client_sync": true
        },
        "wiki:internal_cooldown": {
          "type": "int",
          "range": [0, 200],
          "default": 0,
          "client_sync": false
        }
      }
    },
    "components": {
      "minecraft:physics": {},
      "minecraft:health": {
        "value": 40,
        "max": 40
      }
    }
  }
}

When working in the `@minecraft/server` Script API environment, your code runs strictly on the server thread after the protocol has unpacked incoming client actions (such as player movement, block breaking, or item use) and before outgoing state updates are flushed at the end of the tick. While you cannot open raw sockets or construct custom RakNet packets from standard server scripts, you can pass structured messages into and out of the script environment using the `scriptevent` protocol pipeline.

The `/scriptevent` command and the `system.afterEvents.scriptEventReceive` listener act as a general-purpose message bus. Although `/scriptevent` is executed on the server (via functions, NPCs, or external RCON/WebSocket tools connected to the server), it is the standard protocol bridge for external tooling or command blocks to inject string payloads into your JavaScript runtime. To send arbitrary text data from your script back to a specific client's UI layer without modifying entity properties, creators commonly emit formatted strings through `player.onScreenDisplay.setActionBar()` or `player.sendMessage()`, which travel over standard text and title packets that custom JSON UI binds can intercept.

import { system, world } from "@minecraft/server";

// Listen for incoming scriptevent payloads from server commands or external bridges
system.afterEvents.scriptEventReceive.subscribe((event) => {
  if (event.id === "wiki:sync_turret") {
    const target = event.sourceEntity;
    if (!target || target.typeId !== "wiki:networked_turret") return;

    const parsedValue = Number.parseInt(event.message, 10);
    if (!Number.isNaN(parsedValue)) {
      // Mutating a client_sync: true property queues an actor data packet for this tick
      target.setProperty("wiki:charge_level", Math.min(Math.max(parsedValue, 0), 100));
    }
  }
}, { namespaces: ["wiki"] });

// Broadcast a lightweight HUD payload to a specific player over the text packet stream
export function sendClientHudPayload(player, chargeLevel) {
  player.onScreenDisplay.setActionBar(`HUD_DATA:${chargeLevel}`);
}

Because the Bedrock Protocol must keep mobile devices, consoles, and PCs in sync over varied internet connections, the server enforces strict packet size and frequency budgets. Every time you mutate a synced entity property, update a block permutation via `block.setPermutation()`, or spawn particles, the server queues outgoing packets for all players within simulation and tracking range.

If a script modifies a `client_sync: true` property or swaps block states on hundreds of entities or blocks every single tick, the RakNet send queue will back up. On the client, this manifests as delayed sound effects, rubber-banding movement, or entities freezing in place while chunks stop loading. Always throttle visual state updates to the minimum frequency needed by your animations, and keep internal counters in `client_sync: false` properties or Script API `DynamicProperties`—which are saved to the world database on disk and never transmitted over the network.

Applies to all modern Bedrock Edition versions (1.20.x and 1.21.x). Entity Properties, DynamicProperties, and the system.afterEvents.scriptEventReceive API are stable and require no experimental toggles.

Read out of the game itself, so the ids match the version you are building for.