Introduction

Running a Minecraft server on a one-dollar microcontroller sounds like a joke.

I asked the question, and the answer is yes. Literally.

There's a project called Bareiron, by p2r3, and it's probably one of the most fascinating projects I've seen in the Minecraft world in recent years. We're talking a binary fitting in 300 kilobytes, 6800 lines of C, zero external dependencies, no malloc, no threading, and it runs on a one-dollar ESP32.

Infinite terrain generation. Biomes. Caves. Crafting. Mining. Mobs. Hunger. Chests. Everything you expect from a survival server.

On a chip consuming 0.5W with a 160MHz clock.

To give an order of magnitude: a vanilla Minecraft server needs several gigs of RAM. The ESP32-C3 is 520KB of SRAM (400K usable after boot). CPUs 20 years ago already ran in gigahertz -- this one tops out at 160MHz. The raw power factor between the two is about 20,000.

p2r3 didn't write a Minecraft server in C, he reinvented every server brick to fit those constraints. Let's look at how, by opening the source code.

The project's brain: memoryless terrain generation

The biggest problem when you want an embedded MC server is terrain generation.

In vanilla Minecraft, the world generates with Perlin noise: several stacked layers (octaves), 6 biome parameters (temperature, humidity, continentalness, erosion, weirdness, depth), and a whole caching system to avoid recomputing everything each time.

The result is gorgeous. But it's expensive in compute, and it takes RAM to store generated chunks.

Bareiron's approach is radically different. Instead of stacking noise, it uses bilinear interpolation on 4 points generated by a deterministic RNG.

You know when you upscale a small pixelated image and the edges get blurry? That's exactly it.

// worldgen.c, lines 117-171 (simplified)

uint8_t interpolate (uint8_t a, uint8_t b, uint8_t c, uint8_t d, int x, int z) {
  uint16_t top    = a * (CHUNK_SIZE - x) + b * x;
  uint16_t bottom = c * (CHUNK_SIZE - x) + d * x;
  return (top * (CHUNK_SIZE - z) + bottom * z) / (CHUNK_SIZE * CHUNK_SIZE);
}

uint8_t getHeightAt (int x, int z) {
  int _x = floor(x / CHUNK_SIZE);  // chunk coordinates
  int _z = floor(z / CHUNK_SIZE);
  int rx = x % CHUNK_SIZE;          // offset inside chunk
  int rz = z % CHUNK_SIZE;
  uint32_t hash = getChunkHash(_x, _z);
  uint8_t biome = getChunkBiome(_x, _z);
  // interpolate between 4 corners seeded by hash + biome
  return getHeightAtFromHash(rx, rz, _x, _z, hash, biome);
}

Standard bilinear interpolation: 4 corners, position-based weights, a single uint8_t out. CHUNK_SIZE is 8, so it's all integer multiplication, no floats.

p2r3 shows it step by step in the video: first the chunk's 4 corners, each with an RNG-seeded height.

Then interpolating between those 4 points creates a continuous surface.

And repeating the pattern over all adjacent chunks gives terrain extending to infinity.

The deterministic RNG

The key making all of this possible is seeding. Each chunk has 4 corners, and each corner needs a unique but reproducible pseudo-random value.

// worldgen.c, lines 13-22

uint32_t getChunkHash (short x, short z) {
  uint8_t buf[8];
  memcpy(buf, &x, 2);          // 16 bits of X coordinate
  memcpy(buf + 2, &z, 2);      // 16 bits of Z coordinate
  memcpy(buf + 4, &world_seed, 4);  // 32 bits of global seed
  return splitmix64(*((uint64_t *)buf));  // hash
}

It packs 16 bits of X, 16 bits of Z, and 32 bits of seed into an 8-byte buffer, and runs it all through splitmix64. Result: a unique deterministic value per position, based on the world seed.

You catch the power of the mechanism? The server doesn't need to store terrain. It recomputes on the fly when the player arrives in a new zone, and it gives exactly the same result every time.

The splitmix64 used is an ultra-fast PRNG designed for 64-bit hashes:

// worldgen.c (simplified)

static uint32_t splitmix64 (uint64_t state) {
  state += 0x9E3779B97F4A7C15ull;
  uint64_t z = state;
  z = (z ^ (z >> 30)) * 0xBF58476D1CE4E5B9ull;
  z = (z ^ (z >> 27)) * 0x94D049BB133111EBull;
  return (z ^ (z >> 31)) >> 32;
}

3 ops: addition, xor/shift, multiplication, xor/shift, multiplication, xor/shift. All in direct ops, no table or loop. It takes the 8-byte buffer (X + Z + seed), treats it as a 64-bit int, and returns 32 bits of hash. Deterministic, fast, fits in 5 lines.

Why it's not Perlin noise

p2r3 says it himself in the video: "the more digits of the random number you add, the more regular the terrain gets, like more coin flips getting you closer to 50/50". In practice, it's the number of hash bits he combines:

// worldgen.c, lines 51-115

// For a plains biome: 4 combined factors → regular terrain
h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// For snowy plains: 2 factors → rougher
h = (hash % 5) + ((hash >> 4) % 5);

Each biome picks how many bit extractions it combines. The more there are, the more the distribution stabilizes -- like more coin flips approaching 50/50. The fewer, the stronger local variations.

With only 2 factors, snowy plains produce a hilly, almost mountainous terrain. Peaks and dips are frequent.

With 4 factors, plains stay flat and predictable. The distribution stabilizes.

One chunk generates in 200ms on ESP32 -- versus unmeasurable time on the same hardware with Perlin noise, it's that expensive.

The killer detail: querying a block without generating the whole chunk

You play, you mine a block. The server must know which item to give you. Naively, it would need to generate the whole chunk for that.

With bilinear interpolation, you query any point of the plane directly from coords. The chunk corners come from the player position, interpolation gives the height at any offset. A handful of math ops, no chunk generation.

p2r3: "what I want is a magic function that can tell me which block sits at a given coordinate, without accessing memory or computing expensive noise maps". Exactly what he built.

Here's how height becomes concrete blocks:

// worldgen.c (simplified)

uint8_t getTerrainBlock (int x, uint8_t y, int z) {
  uint8_t surface = getHeightAt(x, z);

  if (y > surface)             return B_air;
  if (y == surface)            return biome_top[getChunkBiome(x, z)];
  if (y > surface - 4)         return B_dirt;
  if (y > surface - 16)        return B_stone;
  if (y > CAVE_BASE_DEPTH)     return B_deepslate;
                               return B_bedrock;
}

5 conditions. One grass/dirt/stone/deepslate/bedrock layer. The surface block depends on the biome via biome_top[] -- grass for plains, sand for desert. A simple cascade of ifs falls into the right layer, replacing loop and switch.

Caves, the laziest mirror

cave_altitude = CAVE_BASE_DEPTH - (surface_height - y);

It mirrors surface height underground. That looks like big deepslate cavities. Zero compute, one line.

Ores, XOR version

candidate = (chunk_x ^ col_x ^ col_z) % 100;
if (candidate < 5 && y < 16) -> diamond

One XOR of coords guarantees one candidate per column. Type depends just on altitude. Diamonds hide under the caves' lowest point to keep digging useful.

Tile-map biomes

Each biome is a circular island in a grid, its type set by a seed-computed pattern. Gridded, predictable, and free.

Each biome has its own parameter set encoded in arrays:

// worldgen.c (simplified)

static const uint8_t biome_base[] = {
  [BIOME_PLAINS]  = 48,   // base height: 48
  [BIOME_DESERT]  = 52,   // slightly higher
  [BIOME_FOREST]  = 50,   // in between
  [BIOME_TAIGA]   = 46,   // a bit lower
  [BIOME_SNOWY]   = 40,   // the lowest
};

static const uint8_t biome_top[] = {
  [BIOME_PLAINS]  = B_grass,
  [BIOME_DESERT]  = B_sand,
  [BIOME_FOREST]  = B_grass,
  [BIOME_TAIGA]   = B_grass,
  [BIOME_SNOWY]   = B_snow_block,
};

static const uint8_t biome_factors[] = {
  [BIOME_PLAINS]  = 4,   // 4 extractions → very regular
  [BIOME_DESERT]  = 3,   // 3 extractions → moderate
  [BIOME_FOREST]  = 4,   // 4 extractions → regular, hilly
  [BIOME_TAIGA]   = 3,   // 3 extractions → moderate
  [BIOME_SNOWY]   = 2,   // 2 extractions → very rough
};

Plains: height 48, 4 factors → very flat terrain, grass.

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// Result: ±4 blocks max variation

Desert: height 52, 3 factors, surface block = sand. Never below sea level.

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3);
// Result: ±6 blocks max variation, clamped to SEA_LEVEL+1

Forest: height 50, 4 factors like plains but higher base → wooded hills.

Taiga: height 46, 3 factors → moderate variations, cold terrain.

Snowy plains: height 40, only 2 factors → the roughest.

h = (hash % 5) + ((hash >> 4) % 5);
// Result: ±14 blocks max variation

Each biome encodes in 3 arrays of 5 entries: base height, surface block, factor count. When getHeightAtFromHash gets the biome, it consults those tables to tune terrain. 15 bytes of data replacing Minecraft's whole biome system.

The biome detector uses the seed to determine which biome matches each chunk:

// worldgen.c (simplified)

static const uint8_t biome_pattern[] = {
  BIOME_PLAINS, BIOME_FOREST, BIOME_PLAINS, BIOME_DESERT,
  BIOME_FOREST, BIOME_TAIGA,  BIOME_PLAINS, BIOME_SNOWY,
  BIOME_PLAINS, BIOME_FOREST, BIOME_DESERT,  BIOME_PLAINS,
  BIOME_SNOWY,  BIOME_PLAINS, BIOME_FOREST, BIOME_TAIGA,
};

uint8_t getChunkBiome (short cx, short cz) {
  uint32_t h = splitmix64(cx * 31 + cz * 97 + world_seed);
  uint8_t index = h % 16;
  return biome_pattern[index];
}

A 16-entry pattern, an index seeded by chunk coords. That gives a repetitive but visually coherent grid. 4 lines of code replacing all of vanilla Minecraft's biome parameter system.

getHeightAtFromHash: the terrain assembler

The function at the heart of generation combining the 4 biome-seeded corners:

// worldgen.c (simplified)

static uint8_t getHeightAtFromHash (int rx, int rz, short cx, short cz,
                                    uint32_t h, uint8_t biome) {
  // 4 corners extracted from hash, different seed per corner
  uint8_t h1 = biome_base[biome] + (h & 0x0F);
  uint8_t h2 = biome_base[biome] + ((h >> 4) & 0x0F);
  uint8_t h3 = biome_base[biome] + ((h >> 8) & 0x0F);
  uint8_t h4 = biome_base[biome] + ((h >> 12) & 0x0F);

  // Biome constraint: desert never underwater
  if (biome == BIOME_DESERT) {
    h1 = max(h1, SEA_LEVEL + 1);
    h2 = max(h2, SEA_LEVEL + 1);
    h3 = max(h3, SEA_LEVEL + 1);
    h4 = max(h4, SEA_LEVEL + 1);
  }

  // Interpolate from the 4 corners
  return interpolate(h1, h2, h3, h4, rx, rz);
}

Each biome has a biome_base shifting the reference height, and the 4 corners extract from the hash with different shifts. The desert forces the min above sea level -- one constraint line avoiding water with no extra biome compute.

Trees and cacti: probabilistic placement

Surface generation uses the same chunk hash to decide where to plant:

// worldgen.c (simplified)

static void genFoliage (uint8_t *chunk_data, short cx, short cz,
                        uint32_t hash, uint8_t biome) {
  if (biome == BIOME_DESERT) {
    // Cactus: one candidate per chunk, hash determines position
    int tx = (hash >> 8) & 7;
    int tz = (hash >> 12) & 7;
    int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
    if (chunk_data[ty * 64 + tz * 8 + tx] == B_sand)
      placeCactus(chunk_data, tx, ty + 1, tz);
  } else {
    // Trees: hash determines whether to place and where
    int tree_count = (hash & 3);  // 0-3 trees per chunk
    for (int i = 0; i < tree_count; i ++) {
      int tx = ((hash >> (4 + i * 4)) & 7);
      int tz = ((hash >> (6 + i * 4)) & 7);
      int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
      placeTree(chunk_data, tx, ty + 1, tz);
    }
  }
}

0-3 trees per chunk for green biomes, 1 cactus max for desert. The chunk hash is the only entropy source -- an & 7 for position in the chunk, an & 3 for the counter. All deterministic, nothing stored.

generateChunk: putting it all together

The function assembling everything to produce a full 8×8×256 chunk:

// worldgen.c (simplified)

void generateChunk (uint8_t *chunk, short cx, short cz) {
  uint32_t hash = getChunkHash(cx, cz);
  uint8_t biome = getChunkBiome(cx, cz);

  // For each column of the chunk (8×8 = 64)
  for (int x = 0; x < 8; x ++) {
    for (int z = 0; z < 8; z ++) {
      // Absolute world coordinates
      int wx = cx * 8 + x;
      int wz = cz * 8 + z;

      // Column height
      uint8_t height = getHeightAt(wx, wz);

      // Fill the column bottom to top
      for (int y = 0; y < height; y ++) {
        uint8_t block = getTerrainBlock(wx, y, wz);
        chunk[y * 64 + z * 8 + x] = block;
      }
    }
  }

  // Add surface elements (trees, cacti)
  genFoliage(chunk, cx, cz, hash, biome);
}

That's it. 3 nested loops: for each column, find the height, fill the blocks, move to the next. Output is a uint8_t[16384] (8 × 8 × 256) representing the full chunk. The chunk generates then ships straight to the client, with no caching, lazy loading, or compression.

Storage: static arrays everywhere

Bareiron's memory architecture is embedded C in all its glory: only fixed-size global arrays, no malloc, no hash maps, no linked lists.

Block changes

// globals.h, lines 191-196

typedef struct {
  short x;      // 2 bytes -- capped at 32,000 blocks horizontal
  short z;      // 2 bytes
  uint8_t y;    // 1 byte -- capped at 256 blocks vertical
  uint8_t block; // 1 byte -- capped at 256 block types
} BlockChange;

20,000 entries, about 25,000 changes -- the equivalent of a chunk and a half fully dug out. The block field at 0xFF marks a free entry. Lookup is a linear scan:

// procedures.c

uint8_t getBlockChange (short x, uint8_t y, short z) {
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block == 0xFF) continue;
    if (block_changes[i].x == x && block_changes[i].y == y && block_changes[i].z == z)
      return block_changes[i].block;
    #ifdef ALLOW_CHESTS
      if (block_changes[i].block == B_chest) i += 14;  // skip chest data
    #endif
  }
  return 0xFF;
}

Adding a change is as direct as lookup:

static uint8_t changes_count = 0;

void addBlockChange (short x, short z, uint8_t y, uint8_t block) {
  if (changes_count >= MAX_CHANGES) return;
  block_changes[changes_count].x = x;
  block_changes[changes_count].z = z;
  block_changes[changes_count].y = y;
  block_changes[changes_count].block = block;
  changes_count ++;
}

One counter, one index, one write. The array just piles up: no sorting, no compaction, no memory management. When the array is full, new changes are ignored -- terrain reverts to its generated state.

The author's comment on the 256-block cap: "I don't plan to implement lightly weathered waxed copper stairs anytime soon."

Mobs: 8 bytes per pipe head

// globals.h, lines 240-251 (pragma pack(push, 1) to kill padding)

typedef struct {
  uint8_t type;   // 25=chicken, 28=cow, 95=pig, 106=sheep, 145=zombie
  short x;
  uint8_t y;      // if health=0, Y becomes a deletion timer
  short z;
  uint8_t data;   // bits 0-4: health, bit 5: sheep sheared, bits 6-7: panic timer
} MobData;

8 bytes. 16 slots max. Alignment and padding thrown out. The data byte is a homemade bitfield: 5 bits of health, 1 shear bit, 2 panic-timer bits. And when a mob dies, the Y field becomes a deletion timer. Memory reuse down to the bit.

Players: tightly packed

Player data uses #pragma pack(push, 1) too -- coords in short + uint8_t, inventories in fixed uint16_t + uint8_t arrays, and a flags field encoding attack cooldown, spawn state, sneak, sprint, eat, load, movement cooldown, and craft lock, all in individual bits.

The main loop: while(true) and non-blocking

The whole server runs on one loop, one thread, zero event library.

// main.c, lines 594-720

while (true) {
  task_yield();  // let the FreeRTOS idle task breathe on ESP32

  // Accept a new connection (non-blocking)
  for (int i = 0; i < MAX_PLAYERS; i ++) {
    if (clients[i] != -1) continue;
    clients[i] = accept(server_fd, ...);
    if (clients[i] != -1) client_count ++;
    break;
  }

  // Server tick if time elapsed
  if (get_program_time() - last_tick_time > TIME_BETWEEN_TICKS) {
    handleServerTick(time_since_last_tick);
    last_tick_time = get_program_time();
  }

  // Round-robin: one client, one packet per iteration
  client_index = (client_index + 1) % MAX_PLAYERS;
  if (clients[client_index] == -1) continue;

  // Read packet header: length + ID
  recv(client_fd, &recv_buffer, 2, MSG_PEEK);
  int length = readVarInt(client_fd);
  int packet_id = readVarInt(client_fd);
  handlePacket(client_fd, length - sizeVarInt(packet_id), packet_id, state);
}

One client handled per loop iteration, one packet read at a time. The task_yield() at the loop start lets the FreeRTOS idle task breathe on ESP32 -- without it, the watchdog timer resets the chip.

Packet dispatch is a monstrous 400-line switch:

// main.c, lines 68-497

void handlePacket (int client_fd, int length, int packet_id, int state) {
  switch (packet_id) {
    case 0x00:  // Handshake / Status / Login depending on state
    case 0x01:  // Status ping
    case 0x02:  // Plugin message
    case 0x03:  // Login/configuration acknowledgment
    case 0x08:  // Chat
    case 0x0B:  // Client status (respawn)
    case 0x11:  // Click container (handles chests)
    case 0x19:  // Interact entity
    case 0x1D..0x20:  // Movement packets (biggest case)
    case 0x28:  // Player action (dig/place)
    // ... 40+ cases
  }
}

A switch compiles to a static jump table, replacing dynamic jump table, vtable, and map. Perfect for embedded.

The 0x1D-0x20 case is the biggest -- it handles position updates, fall damage, chunk-border crossings, mob spawning, chunk generation, AND hunger. All in one big fall-through.

The server tick and mob AI

The handleServerTick function runs every 50ms (20 TPS). It manages the world while the main loop handles players:

// main.c (simplified)

void handleServerTick (uint32_t delta) {
  // Update each mob
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type == 0 || mobs[i].data == 0) continue;  // dead or empty

    MobData *mob = &mobs[i];
    int px, pz;
    getNearestPlayer(mob->x, mob->z, &px, &pz);

    if (mob->type == MOB_ZOMBIE) {
      // Hostile: walk toward nearest player
      if (px < mob->x) mob->x --;
      else if (px > mob->x) mob->x ++;
      if (pz < mob->z) mob->z --;
      else if (pz > mob->z) mob->z ++;
      // Contact damage at 2 blocks
      if (abs(px - mob->x) <= 2 && abs(pz - mob->z) <= 2)
        damagePlayer(getNearestPlayerId(mob->x, mob->z), 3);
    } else {
      // Passive: 8 random directions
      uint8_t dir = getMobDir(mob);
      mob->x += dir_lookup[dir][0];
      mob->z += dir_lookup[dir][1];
      // Direction change every ~40 ticks
      if (mob->data >> 6 < 1) setMobDir(mob, rand() & 7);
      mob->data = (mob->data & 0x3F) | ((mob->data - 0x40) & 0xC0);
    }

    // Wake chunks around the mob
    setChunkGenerated(mob->x / 8, mob->z / 8);
  }
}

Hostile mob AI is a coordinate comparison. Literally if (px < x) x--. The zombie ignores pathfinding, A*, and obstacle avoidance: it adjusts X and Z independently toward the player -- it walks through walls if there are any.

Contact damage is 3 hearts/sec. p2r3 wanted it high because the lack of pathfinding makes zombies easy to kite.

The armor formula is the pre-combat-update one -- the simplest possible:

// main.c (simplified)

static uint8_t applyArmor (uint8_t damage, uint16_t armor_value) {
  // Pre-1.9 formula: linear reduction
  // Each armor point = 4% reduction, max 80%
  uint8_t reduction = (armor_value * 4);
  if (reduction > 80) reduction = 80;
  return damage * (100 - reduction) / 100;
}

Full diamond = 80% reduction. A zombie hit at 3 hearts becomes 0.6 hearts. p2r3 picked that old formula because it computes in 2 ops -- no thresholds, no curves, just a linear percentage.

Passive mobs: 8 directions in a lookup table, heading change every ~40 ticks. The data field encodes the current direction in the 2 high bits, and the direction-change timer in the 6 remaining bits.

Mob respawning

Mobs don't spawn on random ticks. They appear when the server tick meets a new chunk border:

if (player crossed chunk boundary) {
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type != 0) continue;
    spawnMob(&mobs[i], new_chunk_coords, getChunkHash(cx, cz));
    break;
  }
}

Same RNG as terrain, same chunk seed. If a mob slot is free, spawning is deterministic.

Crafting: no matrices, if/else

// crafting.c, lines 9-347 (simplified)

void getCraftingOutput (PlayerData *player, uint8_t *count, uint16_t *item) {
  // If flag 0x80 is set, the craft buffer is used by a chest
  if (player->flags & 0x80) { *count = 0; *item = 0; return; }

  // Count filled slots, find first item, check identity
  uint8_t filled = 0, first = 10, identical = true;
  for (int i = 0; i < 9; i ++) {
    if (player->craft_items[i]) {
      filled ++;
      if (first == 10) first = i;
      else if (player->craft_items[i] != player->craft_items[first])
        identical = false;
    }
  }

  switch (filled) {
    case 1:  /* planks, ingots... */
    case 2:  /* sticks, shears, torches */
    case 3:  /* shovels, swords, slabs */
    case 4:  /* crafting table, boots */
    case 5:  /* pickaxes, axes, helmets */
    case 7:  /* leggings, composters */
    case 8:  /* furnace, chest, chestplate */
    case 9:  /* full blocks (iron, gold, etc.) */
  }
}

First check: if the 0x80 flag is set, the craft buffer is recycled as a chest pointer. Craft stays locked.

Then it counts filled slots, notes the first item, checks identity. With just that, you match the furnace in 4 checks:

if (count == 8 && first == cobblestone && all_identical && center_empty)
    return furnace;

For complex shapes, it uses the first item's index and checks relative position. Recipes share one matching function -- material determines the result.

Chests: the real hack

The memory hack everyone talks about, in real code:

// procedures.c, lines 1262-1293

if (target == B_chest) {
  // Find the chest entry in the block array
  uint8_t *storage_ptr = NULL;
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block != B_chest) continue;
    if (block_changes[i].x != x || block_changes[i].y != y || block_changes[i].z != z)
      continue;
    storage_ptr = (uint8_t *)(&block_changes[i + 1]);  // point after the chest block
    break;
  }
  if (storage_ptr == NULL) return;

  // Terrible memory hack!!
  // We copy the POINTER into the player's craft item array
  memcpy(player->craft_items, &storage_ptr, sizeof(storage_ptr));
  player->flags |= 0x80;  // lock crafting

  // Send the chest UI to the client
  sc_openScreen(player->client_fd, 2, "Chest", 5);
  for (int i = 0; i < 27; i ++) {
    uint16_t item;
    uint8_t count;
    memcpy(&item, storage_ptr + i * 3, 2);
    memcpy(&count, storage_ptr + i * 3 + 2, 1);
    sc_setContainerSlot(player->client_fd, 2, i, count, item);
  }
}

And the comment in the code: // Terrible memory hack!!1!

Exactly that. It takes the memory address of the next entry in block_changes[], copies it into player->craft_items (a uint16_t[9], so 18 bytes -- enough to hold a 32-bit pointer), and raises the flag so nobody tries crafting meanwhile.

On each click in the chest inventory:

// packets.c, lines 620-638

uint8_t *storage_ptr;
memcpy(&storage_ptr, player->craft_items, sizeof(storage_ptr));
// storage_ptr now points to the chest data
uint16_t *p_item = (uint16_t *)(storage_ptr + (slot - 41) * 3);
uint8_t *p_count = storage_ptr + (slot - 41) * 3 + 2;

It pulls the pointer back from the craft buffer, and accesses slots with an offset. Chest data sits at 3 bytes per slot (2 for ID, 1 for count), stuck together in the block array.

Hunger: 5 lines of genius

// main.c, lines 293-305

// Players send movement packets at ~20/sec when
// moving, far fewer when still. We correlate that
// with activity to simulate hunger for free.
if (player->saturation == 0) {
  if (player->hunger > 0) player->hunger--;
  player->saturation = 200;
  sc_setHealth(client_fd, player->health, player->hunger, player->saturation);
} else if (player->flags & 0x08) {  // sprinting
  player->saturation -= 1;
}
}

Literally that. 5 lines. Each movement packet decrements saturation. When saturation hits zero, hunger drops and saturation resets. Sprint (flag 0x08) doubles the drain.

Zero timers, zero allocated memory, zero dedicated compute. A counter decrementing on packets that already exist.

Fall damage

The project's simplest damage system:

damage = last_ground_y - current_y

One subtraction.

Mining and placing blocks

When you click a block, packet 0x28 (Player Action) lands in the switch. The handler must figure out which block sits at the position, remove it, and put the item in inventory:

// main.c, case 0x28 (simplified)

void handlePlayerAction (int client_fd, uint8_t action, int x, uint8_t y, int z) {
  switch (action) {
    case START_DESTROY_BLOCK: {
      // Determine the block type at the clicked position
      uint8_t block = getBlockAt(x, y, z);

      if (block == B_chest) {
        openChest(client_fd, x, y, z);
        break;
      }

      // Add to block_changes
      addBlockChange(x, z, y, 0);  // 0 = air

      // Give the item to the player (trust the client)
      addItemToPlayer(client_fd, block_to_item(block), 1);

      // Send the update to the client
      sc_blockChange(client_fd, x, y, z, 0);
      sc_ackBlockChange(client_fd, x, y, z, 0);
      break;
    }
    case PLACE_BLOCK: {
      // Read the block type from the player's hand
      uint16_t item = getHeldItem(client_fd);
      uint8_t block = item_to_block(item);
      addBlockChange(x, z, y, block);
      removeItemFromPlayer(client_fd, item, 1);
      sc_blockChange(client_fd, x, y, z, block);
      break;
    }
  }
}

getBlockAt combines generated terrain AND player changes:

uint8_t getBlockAt (int x, uint8_t y, int z) {
  // Check player changes first
  uint8_t change = getBlockChange(x, y, z);
  if (change != 0xFF) return change;

  // Otherwise, read from generated terrain
  return getTerrainBlock(x, y, z);
}

Changes first, generated fallback. Zero debate, zero cache, zero overhead. Under the hood getTerrainBlock is getHeightAt + the stone/dirt/grass/coal layers.

The instant furnace

The funniest: the furnace doesn't exist as an entity. If you put cobblestone in the "cooking" slot and coal in "fuel", the result appears immediately, no timer or chunk ticking: it's just an inventory slot emptying when you put the right items in.

The ESP32 loop: an MC server in 4KB of stack

// main.c, lines 732-779

#ifdef ESP_PLATFORM

void bareiron_main (void *pvParameters) {
  main();
  vTaskDelete(NULL);
}

static void wifi_event_handler (...) {
  if (/* connected */) {
    xTaskCreate(bareiron_main, "bareiron", 4096, NULL, 5, NULL);
  }
}

void app_main () {
  esp_timer_early_init();
  wifi_init();
  // The rest is handled by the event handler
}
#endif

The whole server runs in a FreeRTOS task with 4096 bytes of stack. That's it. The main thread just initializes WiFi and waits for a connection. Once connected, it spawns bareiron_main calling standard main().

All ESP32-specific code is guarded by #ifdef ESP_PLATFORM. On PC, all of it compiles to standard POSIX code.

What got sacrificed

For all of that to fit, vanilla features that don't exist:

• Zero network compression -- zlib too expensive. The server generates chunks fast, but sending them is the bottleneck.
• Zero random ticks -- trees grow with bone meal or not. Mobs spawn at chunk borders.
• Zero item entities -- mined blocks go straight to inventory. The animation is purely visual.
• No inventory validation -- trust the client. 64 diamonds? OK. A chunk mined in 1 sec? OK. For use among trusted people.
• Zero server-side light -- torches sent after everything else, the client computes.
• Zero progressive fluids -- instant final state.

The final result

Ryzen 5 3600: ~0.5ms per chunk. $1 ESP32-C3: ~200ms per chunk. Playable.

3+ players: it lags. Comparable to 2b2t at peak hours, per the author.

The philosophy

p2r3: "I just love the idea that this tiny $1 chip consuming 0.5W can run something as advanced as Minecraft. Science isn't about 'why', it's about 'why not'."

Every line is a tradeoff:

• Perlin noise → interpolation: less pretty, 200x faster, zero memory
• Craft matrices → hardcoded matching: ugly code, zero bytes
• zlib → nothing: bad connection = death, but playable
• Validation → trust: zero security, zero compute

Every missing feature lets another exist within hardware limits.

The 3 points to remember:

1. Interpolation + RNG -- 4 seeded points, infinite terrain, zero storage, query without regenerating the chunk, 200ms generation. It's the genius move making everything else possible.
2. Every feature has a cost -- No compression, random ticks, or validation is a deliberate choice: it's what fits in 520KB.
3. Nasty hacks are the smartest -- Chests in the block array via memcpy, hunger via movement packets, instant furnace. The clean solution would have been too expensive.

If the project interests you, it's all on GitHub under GPLv3. It's nasty C, and I rarely had that much fun reading source code.

Introduction

Faire tourner un serveur Minecraft sur un microcontrôleur à 1 dollar, ça ressemble à une blague.

Je me suis posé la question, et la réponse c'est oui. Littéralement.

Y'a un projet qui s'appelle Bareiron, signé p2r3, et c'est probablement l'un des projets les plus fascinants que j'aie vus dans le monde Minecraft ces dernières années. On parle d'un binaire qui tient dans 300 kilooctets, 6800 lignes de C, zéro dépendance externe, pas de malloc, pas de threading, et ça tourne sur une ESP32 à 1 dollar.

Génération de terrain infinie. Des biomes. Des grottes. Du craft. De la mine. Des mobs. De la faim. Des coffres. Tout ce que t'attends d'un serveur survival.

Sur une puce qui consomme 0.5 Watt et qui a 160 MHz de clock.

Pour donner un ordre d'idée : un serveur Minecraft vanilla a besoin de plusieurs gigas de RAM. L'ESP32-C3, c'est 520 KB de SRAM (400 dispo après le boot). Les processeurs y'a 20 ans tournaient déjà en gigahertz -- celui-ci plafonne à 160 MHz. Le facteur entre les deux en puissance pure, c'est environ 20 000.

p2r3 a pas écrit un serveur Minecraft en C, il a réinventé chaque brique du serveur pour que ça tienne dans ces contraintes. On va regarder comment, en ouvrant le code source.

Le cerveau du projet : une génération de terrain sans mémoire

Le plus gros problème quand tu veux faire un serveur MC embarqué, c'est la génération de terrain.

Dans Minecraft vanilla, le monde est généré avec du Perlin noise : plusieurs couches superposées (des octaves), 6 paramètres biomiques (température, humidité, continentalité, érosion, weirdness, profondeur), et tout un système de caching pour pas avoir à tout recalculer à chaque fois.

Le résultat est magnifique. Mais c'est cher en calcul, et ça prend de la RAM pour stocker les chunks générés.

L'approche de Bareiron est radicalement différente. Au lieu d'empiler du bruit, il utilise de la bilinear interpolation sur 4 points générés par un RNG déterministe.

Tu sais quand tu agrandis une petite image pixelisée et que les bords deviennent flous ? C'est exactement ça.

// worldgen.c, lignes 117-171 (simplifié)

uint8_t interpolate (uint8_t a, uint8_t b, uint8_t c, uint8_t d, int x, int z) {
  uint16_t top    = a * (CHUNK_SIZE - x) + b * x;
  uint16_t bottom = c * (CHUNK_SIZE - x) + d * x;
  return (top * (CHUNK_SIZE - z) + bottom * z) / (CHUNK_SIZE * CHUNK_SIZE);
}

uint8_t getHeightAt (int x, int z) {
  int _x = floor(x / CHUNK_SIZE);  // chunk coordinates
  int _z = floor(z / CHUNK_SIZE);
  int rx = x % CHUNK_SIZE;          // offset inside chunk
  int rz = z % CHUNK_SIZE;
  uint32_t hash = getChunkHash(_x, _z);
  uint8_t biome = getChunkBiome(_x, _z);
  // interpolation between 4 corners seeded by hash + biome
  return getHeightAtFromHash(rx, rz, _x, _z, hash, biome);
}

L'interpolation bilinéaire standard : 4 coins, des poids selon la position, un seul uint8_t en sortie. CHUNK_SIZE est 8, donc ça se fait en multiplications entières, pas de float.

p2r3 le montre étape par étape dans la vidéo : d'abord les 4 coins du chunk, chacun avec une hauteur seedée par le RNG.

Puis l'interpolation entre ces 4 points crée une surface continue.

Et en répétant le pattern sur tous les chunks adjacents, on obtient un terrain qui s'étend à l'infini.

Le RNG déterministe

La clé qui rend tout ça possible, c'est le seeding. Chaque chunk a 4 coins, et chaque coin a besoin d'une valeur pseudo-aléatoire unique mais reproductible.

// worldgen.c, lignes 13-22

uint32_t getChunkHash (short x, short z) {
  uint8_t buf[8];
  memcpy(buf, &x, 2);          // 16 bits de coordonnée X
  memcpy(buf + 2, &z, 2);      // 16 bits de coordonnée Z
  memcpy(buf + 4, &world_seed, 4);  // 32 bits de seed globale
  return splitmix64(*((uint64_t *)buf));  // hash
}

Il packe les 16 bits de X, 16 bits de Z, et 32 bits de seed, dans un buffer de 8 bytes, et il passe le tout dans splitmix64. Résultat : une valeur déterministe unique pour chaque position, basée sur la seed du monde.

Tu captes la puissance du mécanisme ? Le serveur n'a pas besoin de stocker le terrain. Il recalcule à la volée quand le joueur arrive dans une nouvelle zone, et ça donne exactement le même résultat à chaque fois.

Le splitmix64 utilisé est un prng ultra-rapide conçu pour les hash 64 bits :

// worldgen.c (simplifié)

static uint32_t splitmix64 (uint64_t state) {
  state += 0x9E3779B97F4A7C15ull;
  uint64_t z = state;
  z = (z ^ (z >> 30)) * 0xBF58476D1CE4E5B9ull;
  z = (z ^ (z >> 27)) * 0x94D049BB133111EBull;
  return (z ^ (z >> 31)) >> 32;
}

3 opérations : addition, xor/shift, multiplication, xor/shift, multiplication, xor/shift. Le tout tient en opérations directes, sans table ni boucle. Il prend le buffer de 8 bytes (X + Z + seed), le traite comme un entier 64 bits, et renvoie 32 bits de hash. C'est déterministe, rapide, et tient en 5 lignes.

Pourquoi c'est pas du Perlin noise

p2r3 le dit lui-même dans la vidéo : "plus tu ajoutes de digits du nombre aléatoire, plus le terrain devient régulier, comme plus de lancers de pièces te rapprochent de 50/50". En pratique, c'est le nombre de bits du hash qu'il combine :

// worldgen.c, lignes 51-115

// Pour un biome plains : 4 facteurs combinés → terrain régulier
h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// Pour snowy plains : 2 facteurs → plus accidenté
h = (hash % 5) + ((hash >> 4) % 5);

Chaque biome choisit combien de extractions de bits il combine. Plus y en a, plus la distribution se stabilise -- comme plus de lancers de pièces qui approchent 50/50. Moins y en a, plus les variations locales sont fortes.

Avec seulement 2 facteurs, le snowy plains produit un terrain vallonné, presque montagneux. Les pics et les creux sont fréquents.

Avec 4 facteurs, les plaines restent plates et prévisibles. La distribution se stabilise.

Un chunk se génère en 200 ms sur ESP32 -- contre un temps non mesurable sur le même hardware avec Perlin noise tellement c'est cher.

Le détail qui tue : interroger un bloc sans générer tout le chunk

Tu joues, tu mines un bloc. Le serveur doit savoir quel item te donner. Naïvement, il faudrait générer tout le chunk pour ça.

Avec la bilinear interpolation, tu interroges n'importe quel point du plan directement depuis les coordonnées. Les coins du chunk s'obtiennent depuis la position du joueur, l'interpolation te donne la hauteur à n'importe quel offset. Une poignée d'opérations mathématiques, pas de génération de chunk.

p2r3 : "ce que je veux, c'est une fonction magique qui peut me dire quel bloc se trouve à une coordonnée donnée, sans accéder à la mémoire ni calculer des cartes de bruit chères". Exactement ce qu'il a fait.

Voici comment la hauteur devient des blocs concrets :

// worldgen.c (simplifié)

uint8_t getTerrainBlock (int x, uint8_t y, int z) {
  uint8_t surface = getHeightAt(x, z);

  if (y > surface)             return B_air;
  if (y == surface)            return biome_top[getChunkBiome(x, z)];
  if (y > surface - 4)         return B_dirt;
  if (y > surface - 16)        return B_stone;
  if (y > CAVE_BASE_DEPTH)     return B_deepslate;
                               return B_bedrock;
}

5 conditions. Une couche de grass/dirt/stone/deepslate/bedrock. Le bloc de surface dépend du biome via biome_top[] -- grass pour les plaines, sand pour le désert. Une simple cascade de if tombe dans la bonne couche, ce qui remplace boucle et switch.

Les grottes, mirror le plus paresseux

altitude_grotte = CAVE_BASE_DEPTH - (hauteur_surface - y);

Il mirror la hauteur de la surface sous terre. Ça ressemble aux grandes cavités deepslate. Zéro compute, une ligne.

Les minerais, version XOR

candidat = (chunk_x ^ col_x ^ col_z) % 100;
if (candidat < 5 && y < 16) -> diamond

Un XOR de coordonnées garantit un candidat par colonne. Le type dépend juste de l'altitude. Les diamants sont planqués sous le point le plus bas des grottes pour que creuser reste utile.

Les biomes en tile map

Chaque biome est une île circulaire dans une grille, son type déterminé par un pattern calculé depuis la seed. Gridé, prévisible, et gratuit.

Chaque biome a son propre jeu de paramètres encodé dans des tableaux :

// worldgen.c (simplifié)

static const uint8_t biome_base[] = {
  [BIOME_PLAINS]  = 48,   // hauteur de base : 48
  [BIOME_DESERT]  = 52,   // légèrement plus haut
  [BIOME_FOREST]  = 50,   // entre les deux
  [BIOME_TAIGA]   = 46,   // un peu plus bas
  [BIOME_SNOWY]   = 40,   // le plus bas
};

static const uint8_t biome_top[] = {
  [BIOME_PLAINS]  = B_grass,
  [BIOME_DESERT]  = B_sand,
  [BIOME_FOREST]  = B_grass,
  [BIOME_TAIGA]   = B_grass,
  [BIOME_SNOWY]   = B_snow_block,
};

static const uint8_t biome_factors[] = {
  [BIOME_PLAINS]  = 4,   // 4 extractions → très régulier
  [BIOME_DESERT]  = 3,   // 3 extractions → modéré
  [BIOME_FOREST]  = 4,   // 4 extractions → régulier, vallonné
  [BIOME_TAIGA]   = 3,   // 3 extractions → modéré
  [BIOME_SNOWY]   = 2,   // 2 extractions → très accidenté
};

Plains : hauteur 48, 4 facteurs → terrain très plat, herbe.

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// Résultat : variation de ±4 blocs max

Desert : hauteur 52, 3 facteurs, bloc surface = sable. Jamais sous le niveau de la mer.

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3);
// Résultat : variation de ±6 blocs max, clampé à SEA_LEVEL+1

Forest : hauteur 50, 4 facteurs comme plains mais base plus haute → collines boisées.

Taiga : hauteur 46, 3 facteurs → variations modérées, terrain froid.

Snowy plains : hauteur 40, seulement 2 facteurs → le plus accidenté.

h = (hash % 5) + ((hash >> 4) % 5);
// Résultat : variation de ±14 blocs max

Chaque biome est encodé en 3 tableaux de 5 entrées : hauteur de base, bloc de surface, nombre de facteurs. Quand getHeightAtFromHash reçoit le biome, elle consulte ces tableaux pour ajuster le terrain. 15 bytes de données pour remplacer tout le système de biomes de Minecraft.

Le détecteur de biome utilise la seed pour déterminer quel biome correspond à chaque chunk :

// worldgen.c (simplifié)

static const uint8_t biome_pattern[] = {
  BIOME_PLAINS, BIOME_FOREST, BIOME_PLAINS, BIOME_DESERT,
  BIOME_FOREST, BIOME_TAIGA,  BIOME_PLAINS, BIOME_SNOWY,
  BIOME_PLAINS, BIOME_FOREST, BIOME_DESERT,  BIOME_PLAINS,
  BIOME_SNOWY,  BIOME_PLAINS, BIOME_FOREST, BIOME_TAIGA,
};

uint8_t getChunkBiome (short cx, short cz) {
  uint32_t h = splitmix64(cx * 31 + cz * 97 + world_seed);
  uint8_t index = h % 16;
  return biome_pattern[index];
}

Un pattern de 16 entrées, un index seedé par les coordonnées du chunk. Ça donne une grille répétitive mais visuellement cohérente. 4 lignes de code pour remplacer tout le système de paramètres biomiques de Minecraft vanilla.

getHeightAtFromHash : l'assembleur de terrain

La fonction au cœur de la génération combine les 4 coins seedés par biome :

// worldgen.c (simplifié)

static uint8_t getHeightAtFromHash (int rx, int rz, short cx, short cz,
                                    uint32_t h, uint8_t biome) {
  // 4 coins extraits du hash, seed différente par coin
  uint8_t h1 = biome_base[biome] + (h & 0x0F);
  uint8_t h2 = biome_base[biome] + ((h >> 4) & 0x0F);
  uint8_t h3 = biome_base[biome] + ((h >> 8) & 0x0F);
  uint8_t h4 = biome_base[biome] + ((h >> 12) & 0x0F);

  // Contrainte biome : désert jamais sous l'eau
  if (biome == BIOME_DESERT) {
    h1 = max(h1, SEA_LEVEL + 1);
    h2 = max(h2, SEA_LEVEL + 1);
    h3 = max(h3, SEA_LEVEL + 1);
    h4 = max(h4, SEA_LEVEL + 1);
  }

  // Interpolation depuis les 4 coins
  return interpolate(h1, h2, h3, h4, rx, rz);
}

Chaque biome a une biome_base qui décale la hauteur de référence, et les 4 coins sont extraits du hash avec des décalages différents. Le désert force le min au-dessus du niveau de la mer -- une ligne de contrainte qui évite l'eau sans calcul biomique supplémentaire.

Arbres et cactus : placement probabiliste

La génération de surface utilise le même hash de chunk pour décider où planter :

// worldgen.c (simplifié)

static void genFoliage (uint8_t *chunk_data, short cx, short cz,
                        uint32_t hash, uint8_t biome) {
  if (biome == BIOME_DESERT) {
    // Cactus : un candidat par chunk, hash détermine la position
    int tx = (hash >> 8) & 7;
    int tz = (hash >> 12) & 7;
    int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
    if (chunk_data[ty * 64 + tz * 8 + tx] == B_sand)
      placeCactus(chunk_data, tx, ty + 1, tz);
  } else {
    // Arbres : hash détermine si on en pose et où
    int tree_count = (hash & 3);  // 0-3 arbres par chunk
    for (int i = 0; i < tree_count; i ++) {
      int tx = ((hash >> (4 + i * 4)) & 7);
      int tz = ((hash >> (6 + i * 4)) & 7);
      int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
      placeTree(chunk_data, tx, ty + 1, tz);
    }
  }
}

0-3 arbres par chunk pour les biomes verts, 1 cactus maximum pour le désert. Le hash du chunk est la seule source d'entropie -- un & 7 pour la position dans le chunk, un & 3 pour le compteur. Tout est déterministe, rien n'est stocké.

generateChunk : tout assembler

La fonction qui met tout ensemble pour produire un chunk complet de 8×8×256 blocs :

// worldgen.c (simplifié)

void generateChunk (uint8_t *chunk, short cx, short cz) {
  uint32_t hash = getChunkHash(cx, cz);
  uint8_t biome = getChunkBiome(cx, cz);

  // Pour chaque colonne du chunk (8×8 = 64)
  for (int x = 0; x < 8; x ++) {
    for (int z = 0; z < 8; z ++) {
      // Coordonnées monde absolues
      int wx = cx * 8 + x;
      int wz = cz * 8 + z;

      // Hauteur de la colonne
      uint8_t height = getHeightAt(wx, wz);

      // Remplir la colonne de bas en haut
      for (int y = 0; y < height; y ++) {
        uint8_t block = getTerrainBlock(wx, y, wz);
        chunk[y * 64 + z * 8 + x] = block;
      }
    }
  }

  // Ajouter les éléments de surface (arbres, cactus)
  genFoliage(chunk, cx, cz, hash, biome);
}

C'est tout. 3 boucles imbriquées : pour chaque colonne, trouver la hauteur, remplir les blocs, passer à la suivante. La sortie est un uint8_t[16384] (8 × 8 × 256) qui représente le chunk complet. Le chunk est généré puis envoyé direct au client, sans passer par du caching, du lazy loading ou de la compression.

Le stockage : des arrays statiques partout

L'architecture mémoire de Bareiron, c'est du C embarqué dans toute sa splendeur : seuls des tableaux globaux de taille fixe, ni malloc, ni hash maps, ni listes chaînées.

Les changements de blocs

// globals.h, lignes 191-196

typedef struct {
  short x;      // 2 bytes -- limite à 32 000 blocs horizontal
  short z;      // 2 bytes
  uint8_t y;    // 1 byte -- limite à 256 blocs vertical
  uint8_t block; // 1 byte -- limite à 256 types de blocs
} BlockChange;

20 000 entrées, soit environ 25 000 changements -- l'équivalent d'un chunk et demi entièrement déterré. Le champ block à 0xFF marque une entrée libre. La recherche est une scan linéaire :

// procedures.c

uint8_t getBlockChange (short x, uint8_t y, short z) {
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block == 0xFF) continue;
    if (block_changes[i].x == x && block_changes[i].y == y && block_changes[i].z == z)
      return block_changes[i].block;
    #ifdef ALLOW_CHESTS
      if (block_changes[i].block == B_chest) i += 14;  // skip chest data
    #endif
  }
  return 0xFF;
}

Ajouter un changement est aussi direct que la recherche :

static uint8_t changes_count = 0;

void addBlockChange (short x, short z, uint8_t y, uint8_t block) {
  if (changes_count >= MAX_CHANGES) return;
  block_changes[changes_count].x = x;
  block_changes[changes_count].z = z;
  block_changes[changes_count].y = y;
  block_changes[changes_count].block = block;
  changes_count ++;
}

Un compteur, un index, une écriture. Le tableau se contente d'empiler : aucun tri, aucune compaction, aucune gestion mémoire. Quand le tableau est plein, les nouveaux changements sont ignorés -- le terrain revient à son état généré.

Le commentaire de l'auteur sur la limite à 256 blocs : "je compte pas implémenter les escaliers en cuivre légèrement patinés cirés de si tôt."

Les mobs : 8 bytes par tête de pipe

// globals.h, lignes 240-251 (pragma pack(push, 1) pour éliminer le padding)

typedef struct {
  uint8_t type;   // 25=chicken, 28=cow, 95=pig, 106=sheep, 145=zombie
  short x;
  uint8_t y;      // si health=0, Y devient un timer avant suppression
  short z;
  uint8_t data;   // bits 0-4: health, bit 5: sheep sheared, bits 6-7: panic timer
} MobData;

8 bytes. 16 emplacements max. L'alignement et le padding passent à la trappe. Le data byte est un bitfield maison : 5 bits de vie, 1 bit de tonte, 2 bits de timer de panique. Et quand un mob meurt, le champ Y devient un timer avant suppression. Réutilisation de mémoire au niveau du bit.

Les joueurs : packés serré

Les données joueurs utilisent #pragma pack(push, 1) aussi -- coordonnées en short + uint8_t, inventaires en tableaux fixes de uint16_t + uint8_t, et un champ flags qui encode à la fois le cooldown d'attaque, l'état de spawn, sneak, sprint, eat, load, movement cooldown, et le lock de craft. Tout ça dans des bits individuels.

La boucle principale : while(true) et du non-bloquant

Le serveur entier tourne sur une boucle, un thread, zéro event library.

// main.c, lignes 594-720

while (true) {
  task_yield();  // laisse respirer le watchdog sur ESP32

  // Accepter une nouvelle connexion (non-bloquant)
  for (int i = 0; i < MAX_PLAYERS; i ++) {
    if (clients[i] != -1) continue;
    clients[i] = accept(server_fd, ...);
    if (clients[i] != -1) client_count ++;
    break;
  }

  // Tick serveur si le temps est écoulé
  if (get_program_time() - last_tick_time > TIME_BETWEEN_TICKS) {
    handleServerTick(time_since_last_tick);
    last_tick_time = get_program_time();
  }

  // Round-robin : un client, un packet par itération
  client_index = (client_index + 1) % MAX_PLAYERS;
  if (clients[client_index] == -1) continue;

  // Lire l'entête du packet : length + ID
  recv(client_fd, &recv_buffer, 2, MSG_PEEK);
  int length = readVarInt(client_fd);
  int packet_id = readVarInt(client_fd);
  handlePacket(client_fd, length - sizeVarInt(packet_id), packet_id, state);
}

Un seul client est traité par itération de la boucle, et un seul packet est lu à la fois. Le task_yield() au début de la boucle laisse le FreeRTOS idle task respirer sur ESP32 -- sans ça, le watchdog timer te reset la puce.

Le dispatch des packets, c'est un switch monstrueux de 400 lignes :

// main.c, lignes 68-497

void handlePacket (int client_fd, int length, int packet_id, int state) {
  switch (packet_id) {
    case 0x00:  // Handshake / Status / Login selon l'état
    case 0x01:  // Status ping
    case 0x02:  // Plugin message
    case 0x03:  // Login/configuration acknowledgment
    case 0x08:  // Chat
    case 0x0B:  // Client status (respawn)
    case 0x11:  // Click container (gère les coffres)
    case 0x19:  // Interact entity
    case 0x1D..0x20:  // Movement packets (le plus gros cas)
    case 0x28:  // Player action (dig/place)
    // ... 40+ cas
  }
}

Un switch compile en jump table statique, ce qui remplace jump table dynamique, vtable et map. Parfait pour de l'embarqué.

Le cas 0x1D-0x20 est le plus gros -- il gère les mises à jour de position, les dégâts de chute, les traversées de frontières de chunk, le spawn de mobs, la génération de chunks, ET la faim. Tout en un seul gros fall-through.

Le serveur tick et l'IA des mobs

La fonction handleServerTick est appelée toutes les 50 ms (20 TPS). Elle gère le monde pendant que la boucle principale s'occupe des joueurs :

// main.c (simplifié)

void handleServerTick (uint32_t delta) {
  // Mettre à jour chaque mob
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type == 0 || mobs[i].data == 0) continue;  // mort ou vide

    MobData *mob = &mobs[i];
    int px, pz;
    getNearestPlayer(mob->x, mob->z, &px, &pz);

    if (mob->type == MOB_ZOMBIE) {
      // Hostile : marche vers le joueur le plus proche
      if (px < mob->x) mob->x --;
      else if (px > mob->x) mob->x ++;
      if (pz < mob->z) mob->z --;
      else if (pz > mob->z) mob->z ++;
      // Dégâts de contact à 2 blocs
      if (abs(px - mob->x) <= 2 && abs(pz - mob->z) <= 2)
        damagePlayer(getNearestPlayerId(mob->x, mob->z), 3);
    } else {
      // Passif : 8 directions aléatoires
      uint8_t dir = getMobDir(mob);
      mob->x += dir_lookup[dir][0];
      mob->z += dir_lookup[dir][1];
      // Changement de direction toutes les ~40 ticks
      if (mob->data >> 6 < 1) setMobDir(mob, rand() & 7);
      mob->data = (mob->data & 0x3F) | ((mob->data - 0x40) & 0xC0);
    }

    // Réveiller les chunks autour du mob
    setChunkGenerated(mob->x / 8, mob->z / 8);
  }
}

L'IA des mobs hostiles, c'est une comparaison de coordonnées. Littéralement if (px < x) x--. Le zombie ignore pathfinding, A* et obstacle avoidance : il ajuste X et Z indépendamment vers le joueur -- il traverse les murs si y'en a.

Les dégâts de contact sont à 3 coeurs/sec. p2r3 l'a voulu élevé parce que l'absence de pathfinding rend les zombies faciles à kiter.

La formule d'armure est celle d'avant le combat update -- la plus simple possible :

// main.c (simplifié)

static uint8_t applyArmor (uint8_t damage, uint16_t armor_value) {
  // Formule pré-1.9 : réduction linéaire
  // Chaque point d'armure = 4% de réduction, max 80%
  uint8_t reduction = (armor_value * 4);
  if (reduction > 80) reduction = 80;
  return damage * (100 - reduction) / 100;
}

Full diamond = 80% de réduction. Un coup de zombie à 3 coeurs devient 0.6 coeurs. p2r3 a choisi cette vielle formule parce qu'elle se calcule en 2 opérations -- pas de seuils, pas de courbes, juste un pourcentage linéaire.

Les mobs passifs : 8 directions dans une lookup table, changement de cap toutes les ~40 ticks. Le champ data encode la direction en cours dans les 2 bits de poids fort, et le timer de changement de direction dans les 6 bits restants.

Le respawn des mobs

Les mobs ne spawnent pas avec des random ticks. Ils apparaissent quand le serveur tick rencontre une nouvelle frontière de chunk :

if (player crossed chunk boundary) {
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type != 0) continue;
    spawnMob(&mobs[i], new_chunk_coords, getChunkHash(cx, cz));
    break;
  }
}

Même RNG que le terrain, même seed de chunk. Si un emplacement mob est libre, le spawn est déterministe.

Le craft : pas de matrices, du if/else

// crafting.c, lignes 9-347 (simplifié)

void getCraftingOutput (PlayerData *player, uint8_t *count, uint16_t *item) {
  // Si le flag 0x80 est levé, le buffer de craft est utilisé par un coffre
  if (player->flags & 0x80) { *count = 0; *item = 0; return; }

  // Compter les slots, trouver le premier item, vérifier l'identité
  uint8_t filled = 0, first = 10, identical = true;
  for (int i = 0; i < 9; i ++) {
    if (player->craft_items[i]) {
      filled ++;
      if (first == 10) first = i;
      else if (player->craft_items[i] != player->craft_items[first])
        identical = false;
    }
  }

  switch (filled) {
    case 1:  /* planches, lingots... */
    case 2:  /* bâtons, cisailles, torches */
    case 3:  /* pelles, épées, dalles */
    case 4:  /* table de craft, boots */
    case 5:  /* pioches, haches, casques */
    case 7:  /* jambières, composteurs */
    case 8:  /* fourneau, coffre, plastron */
    case 9:  /* blocs complets (fer, or, etc.) */
  }
}

Le premier check : si le flag 0x80 est levé, le buffer de craft est recyclé en pointeur de coffre. Le craft reste verrouillé.

Ensuite, il compte les slots remplis, note le premier item, vérifie l'identité. Avec juste ça, tu mathes le fourneau en 4 checks :

if (count == 8 && first == cobblestone && all_identical && center_empty)
    return furnace;

Pour les formes complexes, il utilise l'index du premier item et check la position relative. Les recettes partagent une même fonction de matching -- le matériau détermine le résultat.

Les coffres : le hack en vrai

Le hack mémoire dont tout le monde parle, en vrai code :

// procedures.c, lignes 1262-1293

if (target == B_chest) {
  // Chercher l'entrée du coffre dans le tableau des blocs
  uint8_t *storage_ptr = NULL;
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block != B_chest) continue;
    if (block_changes[i].x != x || block_changes[i].y != y || block_changes[i].z != z)
      continue;
    storage_ptr = (uint8_t *)(&block_changes[i + 1]);  // pointe après le bloc coffre
    break;
  }
  if (storage_ptr == NULL) return;

  // Terrible memory hack!!
  // On copie le POINTEUR dans le tableau d'items de craft du joueur
  memcpy(player->craft_items, &storage_ptr, sizeof(storage_ptr));
  player->flags |= 0x80;  // lock le craft

  // Envoyer l'interface coffre au client
  sc_openScreen(player->client_fd, 2, "Chest", 5);
  for (int i = 0; i < 27; i ++) {
    uint16_t item;
    uint8_t count;
    memcpy(&item, storage_ptr + i * 3, 2);
    memcpy(&count, storage_ptr + i * 3 + 2, 1);
    sc_setContainerSlot(player->client_fd, 2, i, count, item);
  }
}

Et le commentaire dans le code : // Terrible memory hack!!1!

C'est exactement ça. Il prend l'adresse mémoire de l'entrée suivante dans block_changes[], il la copie dans player->craft_items (qui est un uint16_t[9], donc 18 bytes -- assez pour stocker un pointeur 32 bits), et il lève le flag pour que personne essaie de craft pendant ce temps.

Sur chaque clic dans l'inventaire du coffre :

// packets.c, lignes 620-638

uint8_t *storage_ptr;
memcpy(&storage_ptr, player->craft_items, sizeof(storage_ptr));
// storage_ptr pointe maintenant vers les données du coffre
uint16_t *p_item = (uint16_t *)(storage_ptr + (slot - 41) * 3);
uint8_t *p_count = storage_ptr + (slot - 41) * 3 + 2;

Il récupère le pointeur depuis le buffer de craft, et il accède aux slots avec un offset. Les données coffre sont stockées à raison de 3 bytes par slot (2 pour l'ID, 1 pour la quantité), collées les unes aux autres dans le tableau de blocs.

La faim : 5 lignes de génie

// main.c, lignes 293-305

// Les joueurs envoient des packets de mouvement à ~20/sec quand ils
// bougent, beaucoup moins quand ils sont immobiles. On corrèle ça
// avec l'activité pour simuler la faim gratuitement.
if (player->saturation == 0) {
  if (player->hunger > 0) player->hunger--;
  player->saturation = 200;
  sc_setHealth(client_fd, player->health, player->hunger, player->saturation);
} else if (player->flags & 0x08) {  // sprinting
  player->saturation -= 1;
}
}

C'est littéralement ça. 5 lignes. Chaque packet de mouvement décrémente la saturation. Quand la saturation arrive à zéro, la faim baisse et on reset la saturation. Le sprint (flag 0x08) double le drain.

Zéro timer, zéro mémoire allouée, zéro compute dédié. Un compteur qui se décrémente sur des packets qui existent déjà.

Les dégâts de chute

Le système de dégâts le plus simple du projet :

// Quand le joueur quitte le sol, on stocke son Y
// Quand il retouche le sol, on soustrait
degats = dernier_y_au_sol - y_actuel;

Une soustraction.

Miner et placer des blocs

Quand tu cliques sur un bloc, le packet 0x28 (Player Action) atterrit dans le switch. Le handler doit déterminer quel bloc se trouve à la position, le retirer, et mettre l'item dans l'inventaire :

// main.c, case 0x28 (simplifié)

void handlePlayerAction (int client_fd, uint8_t action, int x, uint8_t y, int z) {
  switch (action) {
    case START_DESTROY_BLOCK: {
      // Déterminer le type de bloc à la position cliquée
      uint8_t block = getBlockAt(x, y, z);

      if (block == B_chest) {
        openChest(client_fd, x, y, z);
        break;
      }

      // Ajouter aux block_changes
      addBlockChange(x, z, y, 0);  // 0 = air

      // Donner l'item au joueur (trust the client)
      addItemToPlayer(client_fd, block_to_item(block), 1);

      // Envoyer la mise à jour au client
      sc_blockChange(client_fd, x, y, z, 0);
      sc_ackBlockChange(client_fd, x, y, z, 0);
      break;
    }
    case PLACE_BLOCK: {
      // Lire le type de bloc depuis la main du joueur
      uint16_t item = getHeldItem(client_fd);
      uint8_t block = item_to_block(item);
      addBlockChange(x, z, y, block);
      removeItemFromPlayer(client_fd, item, 1);
      sc_blockChange(client_fd, x, y, z, block);
      break;
    }
  }
}

getBlockAt combine la génération de terrain ET les changements joueurs :

uint8_t getBlockAt (int x, uint8_t y, int z) {
  // D'abord vérifier les changements joueurs
  uint8_t change = getBlockChange(x, y, z);
  if (change != 0xFF) return change;

  // Sinon, lire depuis le terrain généré
  return getTerrainBlock(x, y, z);
}

Priorité aux changements, fallback sur le terrain. Zéro débat, zéro cache, zéro overhead. Le getTerrainBlock sous le capot, c'est getHeightAt + les couches de stone/dirt/grass/coal.

Le fourneau instantané

Le plus drôle : le fourneau n'existe pas en tant qu'entité. Si tu poses du cobblestone dans la case "cuisson" et du coal dans "fuel", le résultat apparaît immédiatement, sans timer ni chunk ticking : c'est juste un slot d'inventaire qui se vide quand tu mets les bons items.

La boucle ESP32 : un serveur MC dans 4 KB de stack

// main.c, lignes 732-779

#ifdef ESP_PLATFORM

void bareiron_main (void *pvParameters) {
  main();
  vTaskDelete(NULL);
}

static void wifi_event_handler (...) {
  if (/* connecté */) {
    xTaskCreate(bareiron_main, "bareiron", 4096, NULL, 5, NULL);
  }
}

void app_main () {
  esp_timer_early_init();
  wifi_init();
  // Le reste est géré par le event handler
}
#endif

Le serveur entier tourne dans une tâche FreeRTOS avec 4096 bytes de stack. C'est tout. Le main thread principal ne fait qu'initialiser le WiFi et attendre une connexion. Une fois connecté, il spawn bareiron_main qui appelle le main() standard.

Tout le code spécifique ESP32 est protégé par des #ifdef ESP_PLATFORM. Sur PC, tout ça compile en code POSIX standard.

Ce qui a été sacrifié

Pour que tout ça tienne, y'a des features vanilla qui existent pas :

• Zéro compression réseau -- zlib trop cher. Le serveur génère des chunks vite, mais les envoyer est le bottleneck.
• Zéro random ticks -- les arbres poussent avec de la bone meal ou pas. Les mobs spawnent aux frontières de chunk.
• Zéro entité item -- les blocs minés vont direct dans l'inventaire. L'animation est purement visuelle.
• Aucune vérification d'inventaire -- trust the client. 64 diamants ? OK. Un chunk miné en 1 sec ? OK. À utiliser entre gens de confiance.
• Zéro lumière serveur -- les torches sont envoyées après tout le reste, le client calcule.
• Zéro fluides progressifs -- état final instantané.

Le résultat final

Ryzen 5 3600 : ~0.5 ms par chunk. ESP32-C3 à 1$ : ~200 ms par chunk. Jouable.

3+ joueurs : ça rame. Comparable à 2b2t aux heures de pointe, dixit l'auteur.

La philosophie

p2r3 : "J'aime juste l'idée que cette toute petite puce à 1 balles qui consomme 0.5 Watt puisse faire tourner quelque chose d'aussi avancé que Minecraft. Science isn't about 'why', it's about 'why not'."

Chaque ligne est un tradeoff :

• Perlin noise → interpolation : moins joli, 200x plus rapide, zéro mémoire
• Matrices de craft → matching hardcodé : code dégueu, zéro byte
• zlib → rien : connexion pourrie = mort, mais jouable
• Validation → trust : zéro sécurité, zéro compute

Chaque feature absente permet à une autre d'exister dans les limites du hardware.

Les 3 points à retenir :

1. Interpolation + RNG -- 4 points seedés, terrain infini, zéro stockage, query sans regénérer le chunk, 200 ms de génération. C'est le move de génie qui rend tout le reste possible.
2. Chaque feature a un coût -- L'absence de compression, de random ticks et de validation relève du choix assumé : c'est ce qui permet de tenir dans 520 KB.
3. Les hacks dégueus sont les plus intelligents -- Coffres dans le tableau de blocs via memcpy, faim par packets de mouvement, fourneau instantané. La solution propre aurait été trop chère.

Si le projet t'intéresse, tout est sur GitHub en GPLv3. C'est du C bien sale, et j'ai rarement pris autant de plaisir à lire un code source.

引言

在 1 美元微控制器上跑 Minecraft 服务器，听着像笑话。

我问了自己行不行，答案是行。字面意义的行。

有个项目叫 Bareiron，作者 p2r3，大概是我这几年在 Minecraft 世界见过最迷人的项目之一。二进制 300KB，6800 行 C，零外部依赖，不 malloc，不开线程，跑在 1 美元的 ESP32 上。

无限地形生成。生物群系。洞穴。合成。挖矿。生物。饥饿。箱子。你对生存服务器期望的一切都有。

芯片功耗 0.5 瓦，主频 160 MHz。

给个量级：vanilla Minecraft 服务器要几个 G 内存。ESP32-C3 是 520 KB SRAM（启动后剩 400）。20 年前的处理器都跑 GHz 了，这个 160 MHz 封顶。纯算力差约 20000 倍。

p2r3 没写个 C 版 Minecraft 服务器，他把服务器的每个砖都重发明了一遍，塞进这些约束。下面打开源码看他怎么干的。

项目的大脑：无内存地形生成

嵌入式 MC 服务器最大的问题是地形生成。

vanilla Minecraft 用 Perlin 噪声生成世界：多层叠加（octaves），6 个生物参数（温度、湿度、大陆度、侵蚀、weirdness、深度），再加整套缓存不然每次全重算。

结果漂亮。但算得贵，存生成好的 chunk 要内存。

Bareiron 路子完全不同。不叠噪声，用双线性插值，4 个点由确定性 RNG 生成。

你把小像素图放大、边缘变模糊，就是那个感觉。

// worldgen.c，117-171 行（简化）

uint8_t interpolate (uint8_t a, uint8_t b, uint8_t c, uint8_t d, int x, int z) {
  uint16_t top    = a * (CHUNK_SIZE - x) + b * x;
  uint16_t bottom = c * (CHUNK_SIZE - x) + d * x;
  return (top * (CHUNK_SIZE - z) + bottom * z) / (CHUNK_SIZE * CHUNK_SIZE);
}

uint8_t getHeightAt (int x, int z) {
  int _x = floor(x / CHUNK_SIZE);  // chunk 坐标
  int _z = floor(z / CHUNK_SIZE);
  int rx = x % CHUNK_SIZE;          // chunk 内偏移
  int rz = z % CHUNK_SIZE;
  uint32_t hash = getChunkHash(_x, _z);
  uint8_t biome = getChunkBiome(_x, _z);
  // 按 hash + biome 插 4 个角
  return getHeightAtFromHash(rx, rz, _x, _z, hash, biome);
}

标准双线性插值：4 个角，按位置加权，输出一个 uint8_t。CHUNK_SIZE 是 8，全整数乘法，不用 float。

p2r3 在视频里一步步演示：先是 chunk 的 4 个角，每个由 RNG 定 seed。

然后 4 个点之间插值，连成面。

相邻 chunk 全套同样 pattern，无限连起来。

确定性 RNG

让一切成立的关键是 seed。每个 chunk 4 个角，每个角要唯一但可复现的伪随机值。

// worldgen.c，13-22 行

uint32_t getChunkHash (short x, short z) {
  uint8_t buf[8];
  memcpy(buf, &x, 2);          // 16 位 X 坐标
  memcpy(buf + 2, &z, 2);      // 16 位 Z 坐标
  memcpy(buf + 4, &world_seed, 4);  // 32 位全局 seed
  return splitmix64(*((uint64_t *)buf));  // 哈希
}

16 位 X 加 16 位 Z 加 32 位 seed，打包进 8 字节 buffer，全丢进 splitmix64。结果：每个位置基于世界 seed 的唯一确定值。

get 到机制的威力了吗？服务器不用存地形。玩家走到新区现算，每次结果一模一样。

splitmix64 是给 64 位哈希设计的超快 prng：

// worldgen.c（简化）

static uint32_t splitmix64 (uint64_t state) {
  state += 0x9E3779B97F4A7C15ull;
  uint64_t z = state;
  z = (z ^ (z >> 30)) * 0xBF58476D1CE4E5B9ull;
  z = (z ^ (z >> 27)) * 0x94D049BB133111EBull;
  return (z ^ (z >> 31)) >> 32;
}

3 步：加，异或/移位，乘，异或/移位，乘，异或/移位。全直接运算，无表无循环。8 字节 buffer（X + Z + seed）当 64 位整数吃，吐 32 位哈希。确定，快，5 行。

为什么不是 Perlin 噪声

p2r3 在视频里原话："随机数用的 digit 越多，地形越规则，像抛硬币越多越接近 50/50"。实际就是 hash 里拼多少个 bit：

// worldgen.c，51-115 行

// plains 群系：4 个因子拼 → 地形规则
h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// snowy plains：2 个因子 → 更崎岖
h = (hash % 5) + ((hash >> 4) % 5);

每个群系选拼几个 bit 抽取。拼越多分布越稳，像抛硬币多了趋近 50/50。拼越少局部起伏越狠。

2 个因子的 snowy plains 丘陵起伏，近乎山地。峰谷频繁。

4 个因子的平原又平又稳。分布收敛。

chunk 在 ESP32 上 200ms 生成，同硬件 Perlin 噪声贵到测不出时间。

最骚的：问一个方块不用生成整个 chunk

你玩，挖个方块。服务器要知道给你什么掉落。天真做法整块生成。

双线性插值下，平面上任何点直接拿坐标问。chunk 角从玩家位置得，插值得任意偏移的高度。几个数学运算，不生成 chunk。

p2r3："我想要个魔法函数，给坐标就告诉我那个方块是什么，不占内存，不算贵噪声图"。他真做出来了。

高度变具体方块长这样：

// worldgen.c（简化）

uint8_t getTerrainBlock (int x, uint8_t y, int z) {
  uint8_t surface = getHeightAt(x, z);

  if (y > surface)             return B_air;
  if (y == surface)            return biome_top[getChunkBiome(x, z)];
  if (y > surface - 4)         return B_dirt;
  if (y > surface - 16)        return B_stone;
  if (y > CAVE_BASE_DEPTH)     return B_deepslate;
                               return B_bedrock;
}

5 个条件。草/土/石/深板岩/基岩分层。表层块看群系查 biome_top[]，平原草、沙漠沙。一串 if 掉进对应层，替代循环和 switch。

洞穴，最懒的镜像

altitude_grotte = CAVE_BASE_DEPTH - (hauteur_surface - y);

地下把表层高度镜像下来。像深板岩大空洞。零算力，一行。

矿石，XOR 版

candidat = (chunk_x ^ col_x ^ col_z) % 100;
if (candidat < 5 && y < 16) -> diamond

坐标 XOR 保证每列一个候选。类型只看高度。钻石藏在洞穴最低点下面，挖洞永远有用。

生物群系 tilemap

每个群系是格子里一座圆形岛，类型由 seed 算出的 pattern 定。网格化，可预测，免费。

每个群系参数编码进表：

// worldgen.c（简化）

static const uint8_t biome_base[] = {
  [BIOME_PLAINS]  = 48,   // 基准高度：48
  [BIOME_DESERT]  = 52,   // 稍高
  [BIOME_FOREST]  = 50,   // 中间
  [BIOME_TAIGA]   = 46,   // 稍低
  [BIOME_SNOWY]   = 40,   // 最低
};

static const uint8_t biome_top[] = {
  [BIOME_PLAINS]  = B_grass,
  [BIOME_DESERT]  = B_sand,
  [BIOME_FOREST]  = B_grass,
  [BIOME_TAIGA]   = B_grass,
  [BIOME_SNOWY]   = B_snow_block,
};

static const uint8_t biome_factors[] = {
  [BIOME_PLAINS]  = 4,   // 4 个抽取 → 很规则
  [BIOME_DESERT]  = 3,   // 3 个抽取 → 中等
  [BIOME_FOREST]  = 4,   // 4 个抽取 → 规则，丘陵
  [BIOME_TAIGA]   = 3,   // 3 个抽取 → 中等
  [BIOME_SNOWY]   = 2,   // 2 个抽取 → 最崎岖
};

Plains：基准 48，4 因子，地形很平，草。

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// 结果：起伏最多 ±4 格

Desert：基准 52，3 因子，表层沙。永不低于海平面。

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3);
// 结果：起伏最多 ±6 格，钳到 SEA_LEVEL+1

Forest：基准 50，4 因子和平原一样，但基准高，树林丘陵。

Taiga：基准 46，3 因子，中等起伏，冷。

Snowy plains：基准 40，只 2 因子，最崎岖。

h = (hash % 5) + ((hash >> 4) % 5);
// 结果：起伏最多 ±14 格

每个群系编码进 3 张 5 项表：基准高度、表层块、因子数。getHeightAtFromHash 拿到群系查表调地形。15 字节数据替代 Minecraft 整套群系系统。

群系探测器用 seed 定每个 chunk 是什么群系：

// worldgen.c（简化）

static const uint8_t biome_pattern[] = {
  BIOME_PLAINS, BIOME_FOREST, BIOME_PLAINS, BIOME_DESERT,
  BIOME_FOREST, BIOME_TAIGA,  BIOME_PLAINS, BIOME_SNOWY,
  BIOME_PLAINS, BIOME_FOREST, BIOME_DESERT,  BIOME_PLAINS,
  BIOME_SNOWY,  BIOME_PLAINS, BIOME_FOREST, BIOME_TAIGA,
};

uint8_t getChunkBiome (short cx, short cz) {
  uint32_t h = splitmix64(cx * 31 + cz * 97 + world_seed);
  uint8_t index = h % 16;
  return biome_pattern[index];
}

16 项 pattern，index 由 chunk 坐标定 seed。格子重复但视觉连贯。4 行代码替代 vanilla 整套生物参数系统。

getHeightAtFromHash：地形组装器

核心生成函数，按群系拼 4 个定 seed 的角：

// worldgen.c（简化）

static uint8_t getHeightAtFromHash (int rx, int rz, short cx, short cz,
                                    uint32_t h, uint8_t biome) {
  // 4 个角从 hash 抽，不同角不同偏移
  uint8_t h1 = biome_base[biome] + (h & 0x0F);
  uint8_t h2 = biome_base[biome] + ((h >> 4) & 0x0F);
  uint8_t h3 = biome_base[biome] + ((h >> 8) & 0x0F);
  uint8_t h4 = biome_base[biome] + ((h >> 12) & 0x0F);

  // 群系约束：沙漠不下水
  if (biome == BIOME_DESERT) {
    h1 = max(h1, SEA_LEVEL + 1);
    h2 = max(h2, SEA_LEVEL + 1);
    h3 = max(h3, SEA_LEVEL + 1);
    h4 = max(h4, SEA_LEVEL + 1);
  }

  // 4 个角插值
  return interpolate(h1, h2, h3, h4, rx, rz);
}

每个群系一个 biome_base 错开基准高度，4 个角从 hash 不同偏移抽。沙漠强制最低高于海平面，一行约束，不用额外生物算力就避开水。

树和仙人掌：概率放

表层生成用同一个 chunk hash 定种哪里：

// worldgen.c（简化）

static void genFoliage (uint8_t *chunk_data, short cx, short cz,
                        uint32_t hash, uint8_t biome) {
  if (biome == BIOME_DESERT) {
    // 仙人掌：每 chunk 一个候选，hash 定位置
    int tx = (hash >> 8) & 7;
    int tz = (hash >> 12) & 7;
    int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
    if (chunk_data[ty * 64 + tz * 8 + tx] == B_sand)
      placeCactus(chunk_data, tx, ty + 1, tz);
  } else {
    // 树：hash 定种不种、种哪
    int tree_count = (hash & 3);  // 每 chunk 0-3 棵
    for (int i = 0; i < tree_count; i ++) {
      int tx = ((hash >> (4 + i * 4)) & 7);
      int tz = ((hash >> (6 + i * 4)) & 7);
      int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
      placeTree(chunk_data, tx, ty + 1, tz);
    }
  }
}

绿色群系每 chunk 0-3 棵树，沙漠最多 1 仙人掌。chunk hash 是唯一熵源，一个 & 7 定 chunk 内位置，一个 & 3 定数量。全确定，零存储。

generateChunk：全拼起来

拼完整 8x8x256 chunk 的函数：

// worldgen.c（简化）

void generateChunk (uint8_t *chunk, short cx, short cz) {
  uint32_t hash = getChunkHash(cx, cz);
  uint8_t biome = getChunkBiome(cx, cz);

  // chunk 每列（8x8 = 64）
  for (int x = 0; x < 8; x ++) {
    for (int z = 0; z < 8; z ++) {
      // 世界绝对坐标
      int wx = cx * 8 + x;
      int wz = cz * 8 + z;

      // 列高度
      uint8_t height = getHeightAt(wx, wz);

      // 从下往上填列
      for (int y = 0; y < height; y ++) {
        uint8_t block = getTerrainBlock(wx, y, wz);
        chunk[y * 64 + z * 8 + x] = block;
      }
    }
  }

  // 加表层东西（树、仙人掌）
  genFoliage(chunk, cx, cz, hash, biome);
}

就这些。3 层循环：每列算高度、填方块、下一列。输出 uint8_t[16384]（8 x 8 x 256）完整 chunk。chunk 现生成现发客户端，不缓存、不懒加载、不压缩。

存储：全静态数组

Bareiron 内存架构就是纯嵌入式 C 风：只有全局定长数组，无 malloc，无哈希表，无链表。

方块改动

// globals.h，191-196 行

typedef struct {
  short x;      // 2 字节，横向限 32000 格
  short z;      // 2 字节
  uint8_t y;    // 1 字节，纵向限 256 格
  uint8_t block; // 1 字节，限 256 种方块
} BlockChange;

20000 项，约 25000 次改动，相当于一个半 chunk 全挖空。block 为 0xFF 标空槽。查找线性扫：

// procedures.c

uint8_t getBlockChange (short x, uint8_t y, short z) {
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block == 0xFF) continue;
    if (block_changes[i].x == x && block_changes[i].y == y && block_changes[i].z == z)
      return block_changes[i].block;
    #ifdef ALLOW_CHESTS
      if (block_changes[i].block == B_chest) i += 14;  // 跳过箱子数据
    #endif
  }
  return 0xFF;
}

加改动一样直接：

static uint8_t changes_count = 0;

void addBlockChange (short x, short z, uint8_t y, uint8_t block) {
  if (changes_count >= MAX_CHANGES) return;
  block_changes[changes_count].x = x;
  block_changes[changes_count].z = z;
  block_changes[changes_count].y = y;
  block_changes[changes_count].block = block;
  changes_count ++;
}

计数器，index，写。数组只追加：不排序，不整理，不管内存。满了新改动直接扔，地形回生成态。

作者对 256 方块上限的原话："打蜡轻度锈蚀切制铜楼梯什么的就先不做了。"

生物：每头 8 字节

// globals.h，240-251 行（pragma pack(push, 1) 去 padding）

typedef struct {
  uint8_t type;   // 25=鸡，28=牛，95=猪，106=羊，145=僵尸
  short x;
  uint8_t y;      // 血量为 0 时，Y 变成删除前计时器
  short z;
  uint8_t data;   // bit 0-4：血，bit 5：羊剪没剪，bit 6-7：panic 计时器
} MobData;

8 字节。最多 16 个。对齐 padding 全扔。data 字节是手搓 bitfield：5 位血，1 位剪毛，2 位 panic 计时。生物一死 Y 字段变删除前计时。内存复用到 bit。

玩家：压得死死的

玩家数据也 #pragma pack(push, 1)，坐标 short + uint8_t，背包定长 uint16_t + uint8_t 数组，flags 字段把攻击冷却、出生状态、潜行、疾跑、吃、加载、移动冷却、合成锁全编进 bit。

主循环：while(true) 加非阻塞

整个服务器一个循环，一个线程，零事件库。

// main.c，594-720 行

while (true) {
  task_yield();  // ESP32 上让 watchdog 喘口气

  // 收新连接（非阻塞）
  for (int i = 0; i < MAX_PLAYERS; i ++) {
    if (clients[i] != -1) continue;
    clients[i] = accept(server_fd, ...);
    if (clients[i] != -1) client_count ++;
    break;
  }

  // 时间到跑服务器 tick
  if (get_program_time() - last_tick_time > TIME_BETWEEN_TICKS) {
    handleServerTick(time_since_last_tick);
    last_tick_time = get_program_time();
  }

  // 轮询：每次迭代一个客户端、一个包
  client_index = (client_index + 1) % MAX_PLAYERS;
  if (clients[client_index] == -1) continue;

  // 读包头：长度 + ID
  recv(client_fd, &recv_buffer, 2, MSG_PEEK);
  int length = readVarInt(client_fd);
  int packet_id = readVarInt(client_fd);
  handlePacket(client_fd, length - sizeVarInt(packet_id), packet_id, state);
}

每次循环只处理一个客户端，一次只读一个包。循环开头 task_yield() 让 ESP32 的 FreeRTOS idle 任务喘气，没有它 watchdog 定时器重启芯片。

包分发是 400 行的巨型 switch：

// main.c，68-497 行

void handlePacket (int client_fd, int length, int packet_id, int state) {
  switch (packet_id) {
    case 0x00:  // 按状态：握手 / 状态 / 登录
    case 0x01:  // 状态 ping
    case 0x02:  // 插件消息
    case 0x03:  // 登录/配置确认
    case 0x08:  // 聊天
    case 0x0B:  // 客户端状态（重生）
    case 0x11:  // 点容器（管箱子）
    case 0x19:  // 实体交互
    case 0x1D..0x20:  // 移动包（最大的一块）
    case 0x28:  // 玩家动作（挖/放）
    // ... 40+ 个 case
  }
}

switch 编译成静态跳转表，替代动态跳转表、虚表、map。嵌入式完美。

0x1D-0x20 这块最大，管位置更新、摔落伤害、跨 chunk 边界、刷怪、chunk 生成，还有饥饿。全并一个大 fall-through。

服务器 tick 和生物 AI

handleServerTick 每 50ms 跑一次（20 TPS）。主循环管玩家，它管世界：

// main.c（简化）

void handleServerTick (uint32_t delta) {
  // 更新每个生物
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type == 0 || mobs[i].data == 0) continue;  // 死的或空的

    MobData *mob = &mobs[i];
    int px, pz;
    getNearestPlayer(mob->x, mob->z, &px, &pz);

    if (mob->type == MOB_ZOMBIE) {
      // 敌对：朝最近玩家走
      if (px < mob->x) mob->x --;
      else if (px > mob->x) mob->x ++;
      if (pz < mob->z) mob->z --;
      else if (pz > mob->z) mob->z ++;
      // 2 格内接触伤害
      if (abs(px - mob->x) <= 2 && abs(pz - mob->z) <= 2)
        damagePlayer(getNearestPlayerId(mob->x, mob->z), 3);
    } else {
      // 被动：8 方向随机走
      uint8_t dir = getMobDir(mob);
      mob->x += dir_lookup[dir][0];
      mob->z += dir_lookup[dir][1];
      // 约每 40 tick 换方向
      if (mob->data >> 6 < 1) setMobDir(mob, rand() & 7);
      mob->data = (mob->data & 0x3F) | ((mob->data - 0x40) & 0xC0);
    }

    // 唤醒生物周围 chunk
    setChunkGenerated(mob->x / 8, mob->z / 8);
  }
}

敌对生物 AI 就是比坐标。字面 if (px < x) x--。僵尸不懂寻路、A*、避障：X Z 独立往玩家挪，有墙穿墙。

接触伤害 3 颗心/秒。p2r3 故意设高，因为没寻路的僵尸太好风筝。

护甲公式是战斗更新之前的老版，最简单的那个：

// main.c（简化）

static uint8_t applyArmor (uint8_t damage, uint16_t armor_value) {
  // 1.9 前公式：线性减伤
  // 每点护甲 = 4% 减伤，上限 80%
  uint8_t reduction = (armor_value * 4);
  if (reduction > 80) reduction = 80;
  return damage * (100 - reduction) / 100;
}

全钻石 80% 减伤。僵尸 3 心一巴掌变 0.6 心。p2r3 选老公式因为两步算完，无阈值无曲线，纯线性百分比。

被动生物：8 方向查表，约 40 tick 换向。data 字段高 2 位记当前方向，低 6 位记换向计时。

生物重生

生物不用随机 tick 刷。服务器 tick 遇到新 chunk 边界就刷：

if (player crossed chunk boundary) {
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type != 0) continue;
    spawnMob(&mobs[i], new_chunk_coords, getChunkHash(cx, cz));
    break;
  }
}

RNG 和地形同一套，chunk 同 seed。有空位就确定性刷。

合成：不要矩阵，if/else

// crafting.c，9-347 行（简化）

void getCraftingOutput (PlayerData *player, uint8_t *count, uint16_t *item) {
  // flag 0x80 起，被箱子占着合成 buffer
  if (player->flags & 0x80) { *count = 0; *item = 0; return; }

  // 数格子，找第一个物品，验全一样
  uint8_t filled = 0, first = 10, identical = true;
  for (int i = 0; i < 9; i ++) {
    if (player->craft_items[i]) {
      filled ++;
      if (first == 10) first = i;
      else if (player->craft_items[i] != player->craft_items[first])
        identical = false;
    }
  }

  switch (filled) {
    case 1:  /* 木板、锭…… */
    case 2:  /* 木棍、剪刀、火把 */
    case 3:  /* 铲、剑、台阶 */
    case 4:  /* 工作台、靴子 */
    case 5:  /* 镐、斧、头盔 */
    case 7:  /* 护腿、堆肥桶 */
    case 8:  /* 熔炉、箱子、胸甲 */
    case 9:  /* 整块（铁块、金块等） */
  }
}

先查 flag 0x80 起没，合成 buffer 被箱子指针征用就锁合成。

再数占了几格、第一个是什么、全一不一样。就这些，熔炉 4 个检查配出来：

if (count == 8 && first == cobblestone && all_identical && center_empty)
    return furnace;

复杂形状用第一个物品的 index 加相对位置查。配方共享一套匹配，材料定结果。

箱子：真 hack

大家都在说的内存 hack，上真代码：

// procedures.c，1262-1293 行

if (target == B_chest) {
  // 在方块数组里找这个箱子
  uint8_t *storage_ptr = NULL;
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block != B_chest) continue;
    if (block_changes[i].x != x || block_changes[i].y != y || block_changes[i].z != z)
      continue;
    storage_ptr = (uint8_t *)(&block_changes[i + 1]);  // 指向箱子块后一项
    break;
  }
  if (storage_ptr == NULL) return;

  // Terrible memory hack!!
  // 把指针拷进玩家合成物品数组
  memcpy(player->craft_items, &storage_ptr, sizeof(storage_ptr));
  player->flags |= 0x80;  // 锁合成

  // 发箱子界面给客户端
  sc_openScreen(player->client_fd, 2, "Chest", 5);
  for (int i = 0; i < 27; i ++) {
    uint16_t item;
    uint8_t count;
    memcpy(&item, storage_ptr + i * 3, 2);
    memcpy(&count, storage_ptr + i * 3 + 2, 1);
    sc_setContainerSlot(player->client_fd, 2, i, count, item);
  }
}

代码里原注释：// Terrible memory hack!!1!

就是字面意思。拿 block_changes[] 下一项的内存地址，拷进 player->craft_items（uint16_t[9]，18 字节，32 位指针塞得下），起 flag 让这期间没人能合成。

箱子背包每点一次：

// packets.c，620-638 行

uint8_t *storage_ptr;
memcpy(&storage_ptr, player->craft_items, sizeof(storage_ptr));
// storage_ptr 现在指向箱子数据
uint16_t *p_item = (uint16_t *)(storage_ptr + (slot - 41) * 3);
uint8_t *p_count = storage_ptr + (slot - 41) * 3 + 2;

从合成 buffer 取回指针，按偏移读写格子。箱子数据每格 3 字节（ID 2 字节加数量 1 字节），在方块数组里挨个排。

饥饿：5 行天才

// main.c，293-305 行

// 玩家动起来每秒约发 20 个移动包，
// 静止少得多。拿这个关联活跃度免费模拟饥饿。
if (player->saturation == 0) {
  if (player->hunger > 0) player->hunger--;
  player->saturation = 200;
  sc_setHealth(client_fd, player->health, player->hunger, player->saturation);
} else if (player->flags & 0x08) {  // 疾跑
  player->saturation -= 1;
}
}

字面就这些。每个移动包扣饱和度。饱和度到零扣饥饿、重置饱和度。疾跑（flag 0x08）双倍扣。

零计时器，零内存分配，零专用算力。现成的包当计数器。

摔落伤害

项目里最简单的伤害系统：

// 玩家离地存 Y
// 落地减
伤害 = last_y_ground - y_actuel;

一个减法。

挖放方块

点方块，0x28 包（玩家动作）进 switch。handler 查位置是什么方块，移除，给玩家背包塞东西：

// main.c，case 0x28（简化）

void handlePlayerAction (int client_fd, uint8_t action, int x, uint8_t y, int z) {
  switch (action) {
    case START_DESTROY_BLOCK: {
      // 查点的方块类型
      uint8_t block = getBlockAt(x, y, z);

      if (block == B_chest) {
        openChest(client_fd, x, y, z);
        break;
      }

      // 写 block_changes
      addBlockChange(x, z, y, 0);  // 0 = 空气

      // 给玩家东西（信客户端）
      addItemToPlayer(client_fd, block_to_item(block), 1);

      // 发更新给客户端
      sc_blockChange(client_fd, x, y, z, 0);
      sc_ackBlockChange(client_fd, x, y, z, 0);
      break;
    }
    case PLACE_BLOCK: {
      // 从玩家手里读方块类型
      uint16_t item = getHeldItem(client_fd);
      uint8_t block = item_to_block(item);
      addBlockChange(x, z, y, block);
      removeItemFromPlayer(client_fd, item, 1);
      sc_blockChange(client_fd, x, y, z, block);
      break;
    }
  }
}

getBlockAt 把地形生成加玩家改动合起来：

uint8_t getBlockAt (int x, uint8_t y, int z) {
  // 先查玩家改动
  uint8_t change = getBlockChange(x, y, z);
  if (change != 0xFF) return change;

  // 没有读生成地形
  return getTerrainBlock(x, y, z);
}

改动优先，没有回地形。零争论，零缓存，零开销。底下 getTerrainBlock 就是 getHeightAt 加石/土/草/煤分层。

秒烧熔炉

最搞笑的：熔炉不是实体。圆石放"烧制"格、煤放"燃料"格，结果立刻出，无计时无 chunk tick，就是背包格东西放对就清空。

ESP32 循环：4KB 栈里的 MC 服务器

// main.c，732-779 行

#ifdef ESP_PLATFORM

void bareiron_main (void *pvParameters) {
  main();
  vTaskDelete(NULL);
}

static void wifi_event_handler (...) {
  if (/* 已连接 */) {
    xTaskCreate(bareiron_main, "bareiron", 4096, NULL, 5, NULL);
  }
}

void app_main () {
  esp_timer_early_init();
  wifi_init();
  // 剩下事件 handler 接管
}
#endif

整个服务器跑在 FreeRTOS 任务里，4096 字节栈。就这些。主线程只初始化 WiFi 等连接。连上 spawn bareiron_main 调标准 main()。

全部 ESP32 专用代码包 #ifdef ESP_PLATFORM。PC 上全编成标准 POSIX。

砍掉的东西

塞进去的代价，vanilla 那些功能没有：

• 零网络压缩，zlib 太贵。服务器生成 chunk 快，发出去是瓶颈。
• 零随机 tick，树拿骨粉催不然不长。生物 chunk 边界刷。
• 零掉落实体，挖的块直接进背包。动画纯客户端。
• 背包零校验，信客户端。64 钻石？行。1 秒挖空 chunk？行。熟人局用。
• 零服务端光照，火把最后发，客户端自己算。
• 零渐进流体，直接终态。

最终结果

Ryzen 5 3600：每 chunk 约 0.5ms。 1 美元 ESP32-C3：每 chunk 约 200ms。能玩。

3+ 玩家：卡。作者原话堪比高峰期 2b2t。

哲学

p2r3："我就喜欢这个 1 美元、0.5 瓦的小芯片能跑 Minecraft 这种东西的想法。Science isn't about 'why', it's about 'why not'."

每行都是 trade-off：

• Perlin 噪声 → 插值：丑点，快 200 倍，零内存
• 合成矩阵 → 手写匹配：代码丑，零字节
• zlib → 无：烂网死，但能玩
• 校验 → 信：零安全，零算力

每个砍掉的功能都给另一个功能在硬件限制里让了位。

三点记住：

1. 插值 + RNG，4 个定 seed 点，无限地形，零存储，不用重生成 chunk 就能查，生成 200ms。这是让其余一切成立的神之一手。
2. 每个功能都有价，没压缩、没随机 tick、没校验是主动选择：这样才塞得进 520KB。
3. 最脏的 hack 最聪明，箱子 memcpy 进方块数组、移动包扣饥饿、秒烧熔炉。正经解法都太贵。

项目感兴趣，GitHub 全有 GPLv3：https://github.com/p2r3/bareiron/。C 写得又脏又爽，我好久没读源码读这么开心了。

はじめに

1ドルのマイコンでMinecraftサーバーを動かすなんて、冗談みたいに聞こえる。

私は自問した。答えはイエスだ。文字通りね。

Bareironっていうプロジェクトがあって、p2r3作で、ここ数年Minecraft界隈で見た中でたぶん一番魅惑的なプロジェクトの1つだ。300キロバイトに収まるバイナリ、6800行のC、外部依存ゼロ、mallocなし、スレッドなし。それが1ドルのESP32で動く。

無限地形生成。バイオーム。洞窟。クラフト。採掘。モブ。空腹。チェスト。サバイバルサーバーに期待するもの全部ある。

0.5ワット消費でクロック160MHzのチップの上でだ。

規模感を言うと、バニラのMinecraftサーバーは数ギガのRAMが要る。ESP32-C3はSRAM 520KB（起動後に残るのは400）。20年前のプロセッサはすでにギガヘルツで回ってたのに、こいつは160MHzが上限だ。純粋な性能差はざっと2万倍だ。

p2r3はMinecraftサーバーをCで書いたんじゃない。この制約に収めるためにサーバーの各部品を reinvent したんだ。ソースコードを開けてどうなってるか見ていこう。

プロジェクトの心臓部：メモリ不要の地形生成

組み込みMCサーバーを作りたいとき、一番の問題は地形生成だ。

バニラMinecraftでは世界はPerlinノイズで生成される。重ねた複数層（オクターブ）、6つのバイオームパラメータ（気温、湿度、大陸性、浸食、weirdness、深度）、毎回全部再計算しないためのキャッシュ機構いっぱいだ。

結果は壮麗だ。でも計算は重いし、生成済みチャンク保存にRAMを食う。

Bareironのアプローチは根本的に違う。ノイズを重ねる代わりに、決定的RNGが作る4点に対するbilinear補間を使う。

小さなピクセル画像を拡大したとき縁がぼやけるだろ。まさにあれだ。

// worldgen.c、117-171行目（簡略化）

uint8_t interpolate (uint8_t a, uint8_t b, uint8_t c, uint8_t d, int x, int z) {
  uint16_t top    = a * (CHUNK_SIZE - x) + b * x;
  uint16_t bottom = c * (CHUNK_SIZE - x) + d * x;
  return (top * (CHUNK_SIZE - z) + bottom * z) / (CHUNK_SIZE * CHUNK_SIZE);
}

uint8_t getHeightAt (int x, int z) {
  int _x = floor(x / CHUNK_SIZE);  // チャンク座標
  int _z = floor(z / CHUNK_SIZE);
  int rx = x % CHUNK_SIZE;          // チャンク内オフセット
  int rz = z % CHUNK_SIZE;
  uint32_t hash = getChunkHash(_x, _z);
  uint8_t biome = getChunkBiome(_x, _z);
  // ハッシュとバイオームを種にした4隅間の補間
  return getHeightAtFromHash(rx, rz, _x, _z, hash, biome);
}

標準の双線形補間だ。4つの隅、位置による重み、出力はuint8_t1つ。CHUNK_SIZEは8だから整数乗算だけでできて、floatなしだ。

p2r3は動画で段階的に見せてる。まずチャンクの4隅で、それぞれRNGを種にして高さを作る。

次にこの4点間に補間をかけて連続面を作る。

隣り合う全チャンクでパターンを繰り返せば、無限に広がる地形になる。

決定的RNG

これ全部を可能にする鍵はシード付けだ。各チャンクに4隅があって、各隅に一意で再現可能な疑似乱数値が要る。

// worldgen.c、13-22行目

uint32_t getChunkHash (short x, short z) {
  uint8_t buf[8];
  memcpy(buf, &x, 2);          // X座標16ビット
  memcpy(buf + 2, &z, 2);      // Z座標16ビット
  memcpy(buf + 4, &world_seed, 4);  // グローバルシード32ビット
  return splitmix64(*((uint64_t *)buf));  // ハッシュ
}

Xの16ビット、Zの16ビット、シードの32ビットを8バイトのバッファに詰めて、全部splitmix64に通す。結果は各位置に一意な決定的値で、ワールドシードを元にしてる。

この仕組みの強さ分かる？サーバーは地形を保存する必要がないんだ。プレイヤーが新しいゾーンに来たらその場で再計算する。毎回まったく同じ結果になる。

使ってるsplitmix64は64ビットハッシュ用の超高速prngだ。

// worldgen.c（簡略化）

static uint32_t splitmix64 (uint64_t state) {
  state += 0x9E3779B97F4A7C15ull;
  uint64_t z = state;
  z = (z ^ (z >> 30)) * 0xBF58476D1CE4E5B9ull;
  z = (z ^ (z >> 27)) * 0x94D049BB133111EBull;
  return (z ^ (z >> 31)) >> 32;
}

3つの演算だ。加算、xorとシフト、乗算、xorとシフト、乗算、xorとシフト。全部直接演算で、テーブルもループもなし。8バイトバッファ（XとZとシード）を64ビット整数として扱って、32ビットのハッシュを返す。決定的で、速くて、5行に収まる。

なぜPerlinノイズじゃないのか

p2r3自身が動画で言ってる。「乱数の桁を足すほど地形は規則的になる。コイン投げを増やすほど50/50に近づくようにね」。実際やってるのはハッシュの何ビットを組み合わせるかだ。

// worldgen.c、51-115行目

// plainsバイオーム：4因子の組み合わせから規則的な地形
h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// snowy plains：2因子から起伏が激しい
h = (hash % 5) + ((hash >> 4) % 5);

各バイオームは抽出ビットを何個組み合わせるか選ぶ。多いほど分布は安定する。コイン投げを増やして50/50に近づくようにね。少ないほど局所変動が強くなる。

2因子だけだと、snowy plainsは丘陵っぽい、ほぼ山な地形になる。起伏の山と谷が頻繁だ。

4因子だと平原は平らで予測可能に保たれる。分布が安定する。

チャンク生成はESP32で200msだ。同じハードでPerlinノイズだと重すぎて計測不能なくらいだ。

唸る詳細：チャンク全体を生成せずにブロックを問い合わせる

プレイしててブロックを掘る。サーバーはどのアイテムを渡すか知らなきゃいけない。素朴にはチャンク全体を生成することになる。

bilinear補間なら、座標から平面上の任意の点を直接問い合わせられる。チャンクの隅はプレイヤー位置から出る。補間が任意オフセットの高さをくれる。一握りの算術演算で、チャンク生成なしだ。

p2r3いわく「欲しいのは、メモリに触れず高価なノイズマップも計算せずに、指定座標にどのブロックがあるか言える魔法の関数だ」。まさに作ったものがそれだ。

高さが具体的なブロックになるのはこうだ。

// worldgen.c（簡略化）

uint8_t getTerrainBlock (int x, uint8_t y, int z) {
  uint8_t surface = getHeightAt(x, z);

  if (y > surface)             return B_air;
  if (y == surface)            return biome_top[getChunkBiome(x, z)];
  if (y > surface - 4)         return B_dirt;
  if (y > surface - 16)        return B_stone;
  if (y > CAVE_BASE_DEPTH)     return B_deepslate;
                               return B_bedrock;
}

5つの条件だ。grassとdirtとstoneとdeepslateとbedrockの層だ。表面ブロックはbiome_top[]経由でバイオーム依存になる。平原ならgrass、砂漠ならsandだ。単なるifカスケードで正しい層に落ちる。ループもswitchも置き換えてる。

洞窟、一番怠けたミラー

altitude_grotte = CAVE_BASE_DEPTH - (hauteur_surface - y);

地下で表面高さをミラーする。deepslateの大洞窟っぽく見える。計算ゼロ、1行だ。

鉱石、XOR版

candidat = (chunk_x ^ col_x ^ col_z) % 100;
if (candidat < 5 && y < 16) -> diamond

座標のXORで列ごとに候補を1つ保証する。種類は高度だけで決まる。ダイヤは掘る意味が残るよう洞窟最低点の下に隠してある。

タイルマップ式バイオーム

各バイオームはグリッド上の円形島で、種類はシードから計算したパターンで決まる。グリッド化、予測可能、タダだ。

各バイオームは独自パラメータをテーブルにエンコードして持つ。

// worldgen.c（簡略化）

static const uint8_t biome_base[] = {
  [BIOME_PLAINS]  = 48,   // 基準高さ：48
  [BIOME_DESERT]  = 52,   // 少し高め
  [BIOME_FOREST]  = 50,   // 中間
  [BIOME_TAIGA]   = 46,   // 少し低め
  [BIOME_SNOWY]   = 40,   // 最も低い
};

static const uint8_t biome_top[] = {
  [BIOME_PLAINS]  = B_grass,
  [BIOME_DESERT]  = B_sand,
  [BIOME_FOREST]  = B_grass,
  [BIOME_TAIGA]   = B_grass,
  [BIOME_SNOWY]   = B_snow_block,
};

static const uint8_t biome_factors[] = {
  [BIOME_PLAINS]  = 4,   // 4抽出からとても規則的
  [BIOME_DESERT]  = 3,   // 3抽出から中程度
  [BIOME_FOREST]  = 4,   // 4抽出から規則的で丘陵
  [BIOME_TAIGA]   = 3,   // 3抽出から中程度
  [BIOME_SNOWY]   = 2,   // 2抽出からとても起伏が激しい
};

平原：高さ48、4因子からとても平らな地形、草だ。

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// 結果：最大プラスマイナス4ブロックの変動

砂漠：高さ52、3因子、表面ブロックは砂。海面下には絶対ならない。

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3);
// 結果：最大プラスマイナス6ブロックの変動、SEA_LEVEL+1にクランプ

森：高さ50、平原と同じ4因子だが基準が高いから木の生えた丘になる。

タイガ：高さ46、3因子から中程度の変動、寒い地形だ。

雪原：高さ40、2因子だけだから一番起伏が激しい。

h = (hash % 5) + ((hash >> 4) % 5);
// 結果：最大プラスマイナス14ブロックの変動

各バイオームは5エントリのテーブル3つにエンコードされてる。基準高さ、表面ブロック、因子数だ。getHeightAtFromHashがバイオームを受け取ってこのテーブルを引いて地形を調整する。15バイトのデータでバニラMinecraftのバイオーム機構全部を置き換えてる。

バイオーム検出器はシードを使って各チャンクに対応するバイオームを決める。

// worldgen.c（簡略化）

static const uint8_t biome_pattern[] = {
  BIOME_PLAINS, BIOME_FOREST, BIOME_PLAINS, BIOME_DESERT,
  BIOME_FOREST, BIOME_TAIGA,  BIOME_PLAINS, BIOME_SNOWY,
  BIOME_PLAINS, BIOME_FOREST, BIOME_DESERT,  BIOME_PLAINS,
  BIOME_SNOWY,  BIOME_PLAINS, BIOME_FOREST, BIOME_TAIGA,
};

uint8_t getChunkBiome (short cx, short cz) {
  uint32_t h = splitmix64(cx * 31 + cz * 97 + world_seed);
  uint8_t index = h % 16;
  return biome_pattern[index];
}

16エントリのパターンと、チャンク座標を種にしたインデックスだ。繰り返すグリッドになるけど見た目は一貫してる。4行のコードでバニラのバイオームパラメータ機構全部を置き換えてる。

getHeightAtFromHash：地形の組み立て屋

生成の中心にある関数で、バイオームを種にした4隅を組み合わせる。

// worldgen.c（簡略化）

static uint8_t getHeightAtFromHash (int rx, int rz, short cx, short cz,
                                    uint32_t h, uint8_t biome) {
  // ハッシュから4隅を抽出、隅ごとに違うシフト
  uint8_t h1 = biome_base[biome] + (h & 0x0F);
  uint8_t h2 = biome_base[biome] + ((h >> 4) & 0x0F);
  uint8_t h3 = biome_base[biome] + ((h >> 8) & 0x0F);
  uint8_t h4 = biome_base[biome] + ((h >> 12) & 0x0F);

  // バイオーム制約：砂漠は水面下禁止
  if (biome == BIOME_DESERT) {
    h1 = max(h1, SEA_LEVEL + 1);
    h2 = max(h2, SEA_LEVEL + 1);
    h3 = max(h3, SEA_LEVEL + 1);
    h4 = max(h4, SEA_LEVEL + 1);
  }

  // 4隅からの補間
  return interpolate(h1, h2, h3, h4, rx, rz);
}

各バイオームはbiome_baseで基準高さをずらして、4隅はハッシュからずらし違いで抽出する。砂漠は海面以上を強制する。追加のバイオーム計算なしで水を避ける1行制約だ。

木とサボテン：確率的配置

表面生成は同じチャンクハッシュでどこに植えるか決める。

// worldgen.c（簡略化）

static void genFoliage (uint8_t *chunk_data, short cx, short cz,
                        uint32_t hash, uint8_t biome) {
  if (biome == BIOME_DESERT) {
    // サボテン：チャンクごとに1候補、ハッシュが位置を決める
    int tx = (hash >> 8) & 7;
    int tz = (hash >> 12) & 7;
    int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
    if (chunk_data[ty * 64 + tz * 8 + tx] == B_sand)
      placeCactus(chunk_data, tx, ty + 1, tz);
  } else {
    // 木：ハッシュが本数と位置を決める
    int tree_count = (hash & 3);  // チャンクあたり0-3本
    for (int i = 0; i < tree_count; i ++) {
      int tx = ((hash >> (4 + i * 4)) & 7);
      int tz = ((hash >> (6 + i * 4)) & 7);
      int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
      placeTree(chunk_data, tx, ty + 1, tz);
    }
  }
}

緑バイオームはチャンクあたり木0から3本、砂漠はサボテン最大1本。チャンクハッシュが唯一のエントロピー源だ。チャンク内位置に& 7、本数に& 3。全部決定的で、何も保存しない。

generateChunk：全部組み立てる

全部まとめて8かける8かける256ブロックの完全チャンクを作る関数だ。

// worldgen.c（簡略化）

void generateChunk (uint8_t *chunk, short cx, short cz) {
  uint32_t hash = getChunkHash(cx, cz);
  uint8_t biome = getChunkBiome(cx, cz);

  // チャンクの各列（8かける8で64）
  for (int x = 0; x < 8; x ++) {
    for (int z = 0; z < 8; z ++) {
      // 世界の絶対座標
      int wx = cx * 8 + x;
      int wz = cz * 8 + z;

      // 列の高さ
      uint8_t height = getHeightAt(wx, wz);

      // 下から上へ列を埋める
      for (int y = 0; y < height; y ++) {
        uint8_t block = getTerrainBlock(wx, y, wz);
        chunk[y * 64 + z * 8 + x] = block;
      }
    }
  }

  // 表面要素（木、サボテン）を追加
  genFoliage(chunk, cx, cz, hash, biome);
}

以上だ。3重ループで、各列の高さを見て、ブロックを埋めて、次へ進む。出力は完全チャンクを表すuint8_t[16384]（8かける8かける256）だ。チャンクは生成してクライアントに直接送る。キャッシュも遅延読み込みも圧縮もなしだ。

ストレージ：どこまでも静的配列

Bareironのメモリアーキテクチャは組み込みCの真骨頂だ。固定サイズのグローバル配列だけで、mallocもハッシュマップもリンクリストもなしだ。

ブロック変更

// globals.h、191-196行目

typedef struct {
  short x;      // 2バイト、水平32,000ブロックに制限
  short z;      // 2バイト
  uint8_t y;    // 1バイト、垂直256ブロックに制限
  uint8_t block; // 1バイト、256種のブロックに制限
} BlockChange;

2万エントリで、約25,000変更だ。チャンク1個半を丸ごと掘り返す相当だ。blockフィールドが0xFFなら空きエントリだ。検索は線形スキャンだ。

// procedures.c

uint8_t getBlockChange (short x, uint8_t y, short z) {
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block == 0xFF) continue;
    if (block_changes[i].x == x && block_changes[i].y == y && block_changes[i].z == z)
      return block_changes[i].block;
    #ifdef ALLOW_CHESTS
      if (block_changes[i].block == B_chest) i += 14;  // チェストデータをスキップ
    #endif
  }
  return 0xFF;
}

追加も検索と同じくらい直接的だ。

static uint8_t changes_count = 0;

void addBlockChange (short x, short z, uint8_t y, uint8_t block) {
  if (changes_count >= MAX_CHANGES) return;
  block_changes[changes_count].x = x;
  block_changes[changes_count].z = z;
  block_changes[changes_count].y = y;
  block_changes[changes_count].block = block;
  changes_count ++;
}

カウンタとインデックスと書き込み1回だ。テーブルは積むだけだ。ソートも圧縮もメモリ管理もなし。テーブルがいっぱいになったら新しい変更は無視される。地形は生成状態に戻る。

256ブロック制限についての作者コメントは「少し緑青を帯びた磨かれた銅の階段を実装する予定は当分ない」だ。

モブ：パイプ1本あたり8バイト

// globals.h、240-251行目（パディング排除のpragma pack(push, 1)）

typedef struct {
  uint8_t type;   // 25=ニワトリ、28=ウシ、95=ブタ、106=ヒツジ、145=ゾンビ
  short x;
  uint8_t y;      // health=0ならYは削除前タイマーになる
  short z;
  uint8_t data;   // ビット0-4:体力、ビット5:ヒツジの毛刈り、ビット6-7:パニックタイマー
} MobData;

8バイトだ。最大16体だ。アライメントもパディングも捨てる。dataバイトは自家製ビットフィールドで、体力5ビット、毛刈り1ビット、パニックタイマー2ビットだ。モブが死んだらYフィールドは削除前タイマーに転用される。ビット単位のメモリ再利用だ。

プレイヤー：きっちり詰める

プレイヤーデータも#pragma pack(push, 1)だ。座標はshortとuint8_t、インベントリはuint16_tとuint8_tの固定配列、flagsフィールドは攻撃クールダウン、スポーン状態、スニーク、スプリント、食事、load、移動クールダウン、クラフトロックをエンコードする。全部個別ビットだ。

メインループ：while(true)とノンブロッキング

サーバー全体はループ1つ、スレッド1つ、イベントライブラリゼロで回る。

// main.c、594-720行目

while (true) {
  task_yield();  // ESP32でウォッチドッグを休ませる

  // 新規接続を受け付ける（ノンブロッキング）
  for (int i = 0; i < MAX_PLAYERS; i ++) {
    if (clients[i] != -1) continue;
    clients[i] = accept(server_fd, ...);
    if (clients[i] != -1) client_count ++;
    break;
  }

  // 時間が来たらサーバーtick
  if (get_program_time() - last_tick_time > TIME_BETWEEN_TICKS) {
    handleServerTick(time_since_last_tick);
    last_tick_time = get_program_time();
  }

  // ラウンドロビン：1イテレーションで1クライアント1パケット
  client_index = (client_index + 1) % MAX_PLAYERS;
  if (clients[client_index] == -1) continue;

  // パケットヘッダを読む：lengthとID
  recv(client_fd, &recv_buffer, 2, MSG_PEEK);
  int length = readVarInt(client_fd);
  int packet_id = readVarInt(client_fd);
  handlePacket(client_fd, length - sizeVarInt(packet_id), packet_id, state);
}

ループ1周で処理するクライアントは1つだけで、読むパケットも1つだけだ。ループ頭のtask_yield()でFreeRTOSのidleタスクを呼吸させる。これがないとウォッチドッグタイマーがチップをリセットする。

パケット振り分けは400行の巨大switchだ。

// main.c、68-497行目

void handlePacket (int client_fd, int length, int packet_id, int state) {
  switch (packet_id) {
    case 0x00:  // 状態に応じたHandshakeやStatusやLogin
    case 0x01:  // Status ping
    case 0x02:  // Plugin message
    case 0x03:  // Loginやconfiguration acknowledgment
    case 0x08:  // Chat
    case 0x0B:  // Client status（リスポーン）
    case 0x11:  // Click container（チェストを扱う）
    case 0x19:  // Interact entity
    case 0x1D..0x20:  // Movementパケット（一番大きいケース）
    case 0x28:  // Player action（掘るや置く）
    // ... 40超のケース
  }
}

switchは静的ジャンプテーブルにコンパイルされる。動的ジャンプテーブルやvtableやmapの代わりだ。組み込みには最適だ。

0x1D-0x20ケースが一番大きくて、位置更新、落下ダメージ、チャンク境界横断、モブスポーン、チャンク生成、それに空腹まで扱う。全部1つの大きなfall-throughだ。

サーバーtickとモブAI

handleServerTick関数は50msごと（20TPS）に呼ばれる。メインループがプレイヤーを扱う間、世界を動かす。

// main.c（簡略化）

void handleServerTick (uint32_t delta) {
  // 各モブを更新
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type == 0 || mobs[i].data == 0) continue;  // 死亡か空き

    MobData *mob = &mobs[i];
    int px, pz;
    getNearestPlayer(mob->x, mob->z, &px, &pz);

    if (mob->type == MOB_ZOMBIE) {
      // 敵対：最寄りプレイヤーに向かって歩く
      if (px < mob->x) mob->x --;
      else if (px > mob->x) mob->x ++;
      if (pz < mob->z) mob->z --;
      else if (pz > mob->z) mob->z ++;
      // 2ブロック接触ダメージ
      if (abs(px - mob->x) <= 2 && abs(pz - mob->z) <= 2)
        damagePlayer(getNearestPlayerId(mob->x, mob->z), 3);
    } else {
      // 中立：8方向ランダム
      uint8_t dir = getMobDir(mob);
      mob->x += dir_lookup[dir][0];
      mob->z += dir_lookup[dir][1];
      // 約40tickごとに方向転換
      if (mob->data >> 6 < 1) setMobDir(mob, rand() & 7);
      mob->data = (mob->data & 0x3F) | ((mob->data - 0x40) & 0xC0);
    }

    // モブ周辺チャンクを起こす
    setChunkGenerated(mob->x / 8, mob->z / 8);
  }
}

敵対モブのAIは座標比較だ。文字通りif (px < x) x--だ。ゾンビはパスファインディングもA*も障害物回避も無視する。XとZを独立にプレイヤーへ調整する。壁があっても突っ込む。

接触ダメージは3ハート毎秒だ。パスファインディングなしだとゾンビは簡単にkiteできるから、p2r3はわざと高めにした。

防具式は戦闘アップデート前のもので、一番単純なやつだ。

// main.c（簡略化）

static uint8_t applyArmor (uint8_t damage, uint16_t armor_value) {
  // 1.9前の式：線形軽減
  // 防具1ごとに4%軽減、最大80%
  uint8_t reduction = (armor_value * 4);
  if (reduction > 80) reduction = 80;
  return damage * (100 - reduction) / 100;
}

フルダイヤは80%軽減だ。ゾンビの3ハート攻撃は0.6ハートになる。p2r3はこの古い式を選んだ。2演算で計算できるからだ。しきい値も曲線もなく、ただの線形パーセントだ。

中立モブは8方向のルックアップテーブルで、約40tickごとに進路変更する。dataフィールドは進行方向を上位2ビットに、方向転換タイマーを残り6ビットにエンコードする。

モブのリスポーン

モブはランダムtickで湧かない。サーバーtickが新しいチャンク境界に出会ったときに現れる。

if (player crossed chunk boundary) {
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type != 0) continue;
    spawnMob(&mobs[i], new_chunk_coords, getChunkHash(cx, cz));
    break;
  }
}

地形と同じRNGで、同じチャンクシードだ。空きモブ枠があればスポーンは決定的だ。

クラフト：行列なし、ifとelseだけ

// crafting.c、9-347行目（簡略化）

void getCraftingOutput (PlayerData *player, uint8_t *count, uint16_t *item) {
  // 0x80フラグが立ってたらクラフトバッファはチェスト用
  if (player->flags & 0x80) { *count = 0; *item = 0; return; }

  // スロット数え、最初のアイテム特定、同一性確認
  uint8_t filled = 0, first = 10, identical = true;
  for (int i = 0; i < 9; i ++) {
    if (player->craft_items[i]) {
      filled ++;
      if (first == 10) first = i;
      else if (player->craft_items[i] != player->craft_items[first])
        identical = false;
    }
  }

  switch (filled) {
    case 1:  /* 板材、インゴットなど */
    case 2:  /* 棒、ハサミ、松明 */
    case 3:  /* シャベル、剣、ハーフブロック */
    case 4:  /* 作業台、ブーツ */
    case 5:  /* ツルハシ、斧、ヘルメット */
    case 7:  /* レギンス、コンポスター */
    case 8:  /* かまど、チェスト、チェストプレート */
    case 9:  /* 完全ブロック（鉄、金など） */
  }
}

最初のチェック：0x80フラグが立ってたら、クラフトバッファはチェストポインタに転用中だ。クラフトは施錠される。

次に埋まったスロットを数えて、最初のアイテムをメモして、同一性を確認する。これだけでかまどは4チェックで当てられる。

if (count == 8 && first == cobblestone && all_identical && center_empty)
    return furnace;

複雑な形は最初のアイテムのインデックスを使って相対位置をチェックする。レシピは同じマッチ関数を共有する。素材が結果を決める。

チェスト：本物のハック

みんなが話すメモリハックを本物のコードで見よう。

// procedures.c、1262-1293行目

if (target == B_chest) {
  // ブロックテーブルでチェストエントリを探す
  uint8_t *storage_ptr = NULL;
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block != B_chest) continue;
    if (block_changes[i].x != x || block_changes[i].y != y || block_changes[i].z != z)
      continue;
    storage_ptr = (uint8_t *)(&block_changes[i + 1]);  // チェストブロックの次を指す
    break;
  }
  if (storage_ptr == NULL) return;

  // ひどいメモリハック！！
  // ポインタをプレイヤーのクラフトアイテム配列にコピー
  memcpy(player->craft_items, &storage_ptr, sizeof(storage_ptr));
  player->flags |= 0x80;  // クラフトを施錠

  // チェスト画面をクライアントに送る
  sc_openScreen(player->client_fd, 2, "Chest", 5);
  for (int i = 0; i < 27; i ++) {
    uint16_t item;
    uint8_t count;
    memcpy(&item, storage_ptr + i * 3, 2);
    memcpy(&count, storage_ptr + i * 3 + 2, 1);
    sc_setContainerSlot(player->client_fd, 2, i, count, item);
  }
}

コード内のコメントはこうだ。// Terrible memory hack!!1!

まさにそれだ。block_changes[]の次エントリのメモリアドレスを取って、player->craft_items（uint16_t[9]で18バイト。32ビットポインタを格納できる）にコピーして、その間クラフトされないようフラグを立てる。

チェストインベントリのクリックごとにこうだ。

// packets.c、620-638行目

uint8_t *storage_ptr;
memcpy(&storage_ptr, player->craft_items, sizeof(storage_ptr));
// storage_ptrはチェストデータを指す
uint16_t *p_item = (uint16_t *)(storage_ptr + (slot - 41) * 3);
uint8_t *p_count = storage_ptr + (slot - 41) * 3 + 2;

クラフトバッファからポインタを取り戻して、オフセットでスロットにアクセスする。チェストデータは1スロット3バイト（IDに2、個数に1）でブロックテーブル内にくっつけて格納される。

空腹：5行の天才

// main.c、293-305行目

// プレイヤーは動くと毎秒約20移動パケットを送る
// 止まってるとずっと少ない。これと
// 活動を結び付けてタダで空腹を再現する
if (player->saturation == 0) {
  if (player->hunger > 0) player->hunger--;
  player->saturation = 200;
  sc_setHealth(client_fd, player->health, player->hunger, player->saturation);
} else if (player->flags & 0x08) {  // スプリント中
  player->saturation -= 1;
}
}

文字通りこれだけだ。5行だ。各移動パケットが満腹度を減らす。満腹度がゼロになったら空腹が減って満腹度リセットだ。スプリント（フラグ0x08）は消耗2倍だ。

タイマーゼロ、確保メモリゼロ、専用計算ゼロ。既存パケットを減らすカウンタだ。

落下ダメージ

プロジェクト最単純のダメージ機構だ。

// プレイヤーが地面を離れたらYを保存
// 地面に戻ったら引き算
degats = dernier_y_au_sol - y_actuel;

引き算1つだ。

掘ると置く

ブロックをクリックすると0x28パケット（Player Action）がswitchに着弾する。ハンドラはその位置のブロック種を特定して、取り除いて、アイテムをインベントリに入れなきゃいけない。

// main.c、case 0x28（簡略化）

void handlePlayerAction (int client_fd, uint8_t action, int x, uint8_t y, int z) {
  switch (action) {
    case START_DESTROY_BLOCK: {
      // クリック位置のブロック種を特定
      uint8_t block = getBlockAt(x, y, z);

      if (block == B_chest) {
        openChest(client_fd, x, y, z);
        break;
      }

      // block_changesに追加
      addBlockChange(x, z, y, 0);  // 0 = 空気

      // アイテムをプレイヤーに渡す（クライアントを信頼）
      addItemToPlayer(client_fd, block_to_item(block), 1);

      // クライアントに更新を送る
      sc_blockChange(client_fd, x, y, z, 0);
      sc_ackBlockChange(client_fd, x, y, z, 0);
      break;
    }
    case PLACE_BLOCK: {
      // 手持ちからブロック種を読む
      uint16_t item = getHeldItem(client_fd);
      uint8_t block = item_to_block(item);
      addBlockChange(x, z, y, block);
      removeItemFromPlayer(client_fd, item, 1);
      sc_blockChange(client_fd, x, y, z, block);
      break;
    }
  }
}

getBlockAtは地形生成とプレイヤー変更を組み合わせる。

uint8_t getBlockAt (int x, uint8_t y, int z) {
  // まずプレイヤー変更を確認
  uint8_t change = getBlockChange(x, y, z);
  if (change != 0xFF) return change;

  // なければ生成地形から読む
  return getTerrainBlock(x, y, z);
}

変更優先、なければ地形だ。議論ゼロ、キャッシュゼロ、オーバーヘッドゼロ。中のgetTerrainBlockはgetHeightAtとstoneやdirtやgrassやcoalの層だ。

即時かまど

一番笑えるのは、かまどがエンティティとして存在しないことだ。「焼く」枠に丸石を、「燃料」に石炭を置いたら、結果は即出る。タイマーもチャンクtickもなしだ。正しいアイテムを置いたら空くインベントリ枠でしかない。

ESP32ループ：4KBスタックのMCサーバー

// main.c、732-779行目

#ifdef ESP_PLATFORM

void bareiron_main (void *pvParameters) {
  main();
  vTaskDelete(NULL);
}

static void wifi_event_handler (...) {
  if (/* 接続済み */) {
    xTaskCreate(bareiron_main, "bareiron", 4096, NULL, 5, NULL);
  }
}

void app_main () {
  esp_timer_early_init();
  wifi_init();
  // 残りはイベントハンドラが管理
}
#endif

サーバー全体は4096バイトのスタックを持つFreeRTOSタスクで回る。以上だ。メインスレッドはWiFi初期化して接続待ちするだけだ。接続されたら標準main()を呼ぶbareiron_mainをspawnする。

ESP32固有コードは全部#ifdef ESP_PLATFORMで守られてる。PCでは全部標準POSIXコードとしてコンパイルされる。

犠牲になったもの

全部収めるために、バニラの機能で存在しないものがある。

• ネットワーク圧縮ゼロ。zlibは高すぎる。サーバーはチャンクを速く作るけど、送る方がボトルネックだ。
• ランダムtickゼロ。木は骨粉かそのまま育つ。モブはチャンク境界で湧く。
• アイテムエンティティゼロ。掘ったブロックは直接インベントリ行きだ。アニメは純粋に見た目だけだ。
• インベントリ検証なし。クライアントを信頼する。ダイヤ64個？OKだ。1秒でチャンク1個掘る？OKだ。信頼できる仲間で使う用だ。
• サーバー側光源ゼロ。松明は全部の後に送られて、クライアントが計算する。
• 漸進流体ゼロ。即最終状態だ。

最終結果

Ryzen 5 3600：チャンクあたり約0.5ms。 1ドルのESP32-C3：チャンクあたり約200ms。遊べる。

3人以上プレイヤー：重くなる。作者いわくピーク時の2b2t並みだ。

哲学

p2r3いわく「0.5ワット消費の1ドル小チップがMinecraftみたいな高度なものを動かせるって発想が好きなんだ。科学は『なぜ』じゃなく『なぜやらないのか』だよ」。

各行がトレードオフだ。

• Perlinノイズから補間へ：見た目は劣る、200倍速い、メモリゼロ
• クラフト行列からハードコード照合へ：汚いコード、ゼロバイト
• zlibから無しへ：回線悪ければ死ぬ、でも遊べる
• 検証から信頼へ：安全ゼロ、計算ゼロ

欠けた各機能が、ハードの制限内で別の機能の存在を許してる。

覚えるべき3点：

1. 補間とRNG。種付き4点、無限地形、保存ゼロ、チャンク再生成なしの問い合わせ、生成200ms。これが他全部を可能にした天才の一手だ。
2. 各機能にコストがある。圧縮もランダムtickも検証もないのは自覚的な選択だ。520KBに収めるのを許してる。
3. 汚いハックが一番賢い。memcpy経由でブロックテーブルに入れるチェスト、移動パケットで回す空腹、即時かまど。きれいな解法は高すぎたんだ。

興味が出たら、全部GPLv3でGitHubにある。かなり汚いCだけど、ソース読んでこんなに楽しんだのは久しぶりだ。

소개

1달러짜리 마이크로컨트롤러에서 Minecraft 서버를 돌리기. 농담 같아 보여요.

저는 스스로 물었고, 답은 네예요. 말 그대로요.

p2r3 서명 Bareiron이라는 프로젝트가 있어요. 최근 몇 년 Minecraft 세상에서 본 가장 매혹적인 프로젝트 중 하나일 거예요. 300킬로바이트에 들어가는 바이너리, C 6800줄, 외부 의존성 제로, malloc 없음, 스레딩 없음, 1달러 ESP32에서 돌아가요.

무한 지형 만들기. 바이오옴. 동굴. 제작. 채굴. 몹. 배고픔. 상자. 서바이벌 서버에 기대하는 모든 것.

0.5와트를 쓰고 160MHz 클럭인 칩 위에서요.

감 잡으려고요. 바닐라 Minecraft 서버는 수 기가 RAM이 필요해요. ESP32-C3는 SRAM 520KB(부팅 뒤 400 사용 가능)예요. 20년 전 프로세서도 기가헤르츠로 돌았어요. 이것은 160MHz가 한계예요. 순수 힘의 차이가 약 20,000배예요.

p2r3는 Minecraft 서버를 C로 쓴 것이 아니라, 서버 벽돌마다 이 제약에 들어가도록 다시 발명했어요. 소스 코드를 열면서 어떻게 했는지 볼게요.

프로젝트 두뇌: 기억 없는 지형 만들기

임베디드 MC 서버를 만들고 싶을 때 가장 큰 문제가 지형 만들기예요.

바닐라 Minecraft에서 월드는 Perlin 노이즈로 만들어져요. 겹친 여러 층(옥타브), 바이오옴 매개변수 6개(온도와 습도, 대륙성, 침식, weirdness, 깊이), 매번 전부 다시 계산하지 않으려고 캐싱 시스템 전체.

결과는 아름다워요. 하지만 계산이 비싸고, 만든 청크를 저장하려고 RAM이 들어요.

Bareiron 접근은 근본적으로 달라요. 노이즈를 쌓는 대신 결정적 RNG가 만든 4개 점에 이중선형 보간을 써요.

작은 픽셀 이미지를 키우면 가장자리가 흐려지는 것 아시죠? 정확히 그거예요.

// worldgen.c, lignes 117-171 (simplifié)

uint8_t interpolate (uint8_t a, uint8_t b, uint8_t c, uint8_t d, int x, int z) {
  uint16_t top    = a * (CHUNK_SIZE - x) + b * x;
  uint16_t bottom = c * (CHUNK_SIZE - x) + d * x;
  return (top * (CHUNK_SIZE - z) + bottom * z) / (CHUNK_SIZE * CHUNK_SIZE);
}

uint8_t getHeightAt (int x, int z) {
  int _x = floor(x / CHUNK_SIZE);  // chunk coordinates
  int _z = floor(z / CHUNK_SIZE);
  int rx = x % CHUNK_SIZE;          // offset inside chunk
  int rz = z % CHUNK_SIZE;
  uint32_t hash = getChunkHash(_x, _z);
  uint8_t biome = getChunkBiome(_x, _z);
  // interpolation between 4 corners seeded by hash + biome
  return getHeightAtFromHash(rx, rz, _x, _z, hash, biome);
}

표준 이중선형 보간: 점 4개, 위치 따른 가중치, 출력 uint8_t 하나. CHUNK_SIZE가 8이라 정수 곱셈으로 돼요. float 없어요.

p2r3가 영상에서 단계별로 보여줘요. 먼저 청크 점 4개, 각자 RNG 시드 높이를 가져요.

다음에 이 4개 점 사이 보간이 연속 표면을 만들어요.

그리고 인접 모든 청크에 패턴을 반복하면 무한히 뻗는 지형이 나와요.

결정적 RNG

이 모든 것을 가능하게 하는 열쇠가 시딩이에요. 각 청크에 점 4개, 각 점에 고유하지만 재현 가능한 의사난수 값이 필요해요.

// worldgen.c, lignes 13-22

uint32_t getChunkHash (short x, short z) {
  uint8_t buf[8];
  memcpy(buf, &x, 2);          // 16 bits de coordonnée X
  memcpy(buf + 2, &z, 2);      // 16 bits de coordonnée Z
  memcpy(buf + 4, &world_seed, 4);  // 32 bits de seed globale
  return splitmix64(*((uint64_t *)buf));  // hash
}

X 16비트와 Z 16비트, 전역 시드 32비트를 8바이트 버퍼에 넣고, 전부 splitmix64에 통과시켜요. 결과: 위치마다 월드 시드 기반의 고유 결정적 값.

구조의 힘이 느껴지시죠? 서버가 지형을 저장할 필요가 없어요. 플레이어가 새 구역에 오면 그때그때 다시 계산하고, 매번 정확히 같은 결과가 나와요.

쓰는 splitmix64는 64비트 해시용 초고속 prng예요.

// worldgen.c (simplifié)

static uint32_t splitmix64 (uint64_t state) {
  state += 0x9E3779B97F4A7C15ull;
  uint64_t z = state;
  z = (z ^ (z >> 30)) * 0xBF58476D1CE4E5B9ull;
  z = (z ^ (z >> 27)) * 0x94D049BB133111EBull;
  return (z ^ (z >> 31)) >> 32;
}

연산 3개: 덧셈, xor와 시프트, 곱셈, xor와 시프트, 곱셈, xor와 시프트. 전부 직접 연산에 들어가요. 표도 루프도 없어요. 8바이트 버퍼(X + Z + seed)를 64비트 정수로 보고 32비트 해시를 돌려줘요. 결정적이고 빠르고 5줄이에요.

왜 Perlin 노이즈가 아닌지

p2r3가 영상에서 직접 말해요. "난수 자릿수를 많이 더할수록 지형이 규칙적으로 돼요. 동전 던지기를 많이 할수록 50대 50에 가까워지는 것처럼요." 실제로는 해시 비트를 몇 개 합치는지예요.

// worldgen.c, lignes 51-115

// plains 바이오옴: 4개 요소 합치기 → 규칙적 지형
h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// snowy plains: 2개 요소 → 더 험준
h = (hash % 5) + ((hash >> 4) % 5);

각 바이오옴이 비트 추출을 몇 개 합칠지 골라요. 많을수록 분포가 안정돼요. 동전을 많이 던져서 50대 50에 가까워지는 것처럼요. 적을수록 국소 변동이 강해요.

요소 2개만으로 snowy plains가 구릉지고 거의 산악인 지형을 만들어요. 봉우리와 골짜기가 잦아요.

요소 4개로 평원은 평평하고 예측 가능해져요. 분포가 안정돼요.

청크 하나가 ESP32에서 200ms 만에 만들어져요. 같은 하드웨어에서 Perlin 노이즈로는 너무 비싸서 측정할 수 없는 시간과 비교해요.

죽이는 세부 사항: 청크 전체를 만들지 않고 블록 묻기

플레이하고 블록을 캐요. 서버가 어떤 아이템을 줄지 알아야 해요. 순진하게는 청크 전체를 만들어야 해요.

이중선형 보간으로는 평면의 어떤 점이든 좌표에서 바로 물어봐요. 플레이어 위치에서 청크 점을 얻고, 보간이 어떤 오프셋이든 높이를 줘요. 수학 연산 몇 개, 청크 만들기 없어요.

p2r3: "제가 원하는 것은 메모리 접근도 비싼 노이즈 지도 계산도 없이 주어진 좌표에 어떤 블록이 있는지 말해주는 마법 함수예요." 정확히 만든 것이 그거예요.

높이가 구체 블록이 되는 방법은 이렇습니다.

// worldgen.c (simplifié)

uint8_t getTerrainBlock (int x, uint8_t y, int z) {
  uint8_t surface = getHeightAt(x, z);

  if (y > surface)             return B_air;
  if (y == surface)            return biome_top[getChunkBiome(x, z)];
  if (y > surface - 4)         return B_dirt;
  if (y > surface - 16)        return B_stone;
  if (y > CAVE_BASE_DEPTH)     return B_deepslate;
                               return B_bedrock;
}

조건 5개. grass와 dirt, stone, deepslate, bedrock 층 하나. 표면 블록은 biome_top[] 경유 바이오옴에 따라 달라요. 평원은 grass, 사막은 sand. 단순 if 연속이 맞는 층에 떨어져요. 루프와 switch를 대신해요.

동굴, 가장 게으른 거울

altitude_grotte = CAVE_BASE_DEPTH - (hauteur_surface - y);

표면 높이를 지하에 비춰요. 큰 deepslate 빈 곳처럼 보여요. 계산 제로, 한 줄.

광물, XOR 버전

candidat = (chunk_x ^ col_x ^ col_z) % 100;
if (candidat < 5 && y < 16) -> diamond

좌표 XOR이 열마다 후보 하나를 보장해요. 종류는 고도에만 달려 있어요. 다이아몬드는 파는 맛을 살리려고 동굴 최저점 아래 숨겨요.

타일 맵 바이오옴

각 바이오옴은 격자의 원형 섬이고, 종류는 시드에서 계산된 패턴으로 정해져요. 격자, 예측 가능, 무료.

각 바이오옴은 표에 인코딩된 자기 매개변수 묶음이 있어요.

// worldgen.c (simplifié)

static const uint8_t biome_base[] = {
  [BIOME_PLAINS]  = 48,   // hauteur de base : 48
  [BIOME_DESERT]  = 52,   // légèrement plus haut
  [BIOME_FOREST]  = 50,   // entre les deux
  [BIOME_TAIGA]   = 46,   // un peu plus bas
  [BIOME_SNOWY]   = 40,   // le plus bas
};

static const uint8_t biome_top[] = {
  [BIOME_PLAINS]  = B_grass,
  [BIOME_DESERT]  = B_sand,
  [BIOME_FOREST]  = B_grass,
  [BIOME_TAIGA]   = B_grass,
  [BIOME_SNOWY]   = B_snow_block,
};

static const uint8_t biome_factors[] = {
  [BIOME_PLAINS]  = 4,   // 4 extractions → très régulier
  [BIOME_DESERT]  = 3,   // 3 extractions → modéré
  [BIOME_FOREST]  = 4,   // 4 extractions → régulier, vallonné
  [BIOME_TAIGA]   = 3,   // 3 extractions → modéré
  [BIOME_SNOWY]   = 2,   // 2 extractions → très accidenté
};

Plains: 높이 48, 요소 4개 → 아주 평평한 지형, 풀.

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// 결과: 최대 앞뒤 4블록 변동

Desert: 높이 52, 요소 3개, 표면 블록 = 모래. 절대 해수면 아래 없어요.

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3);
// 결과: 최대 앞뒤 6블록 변동, SEA_LEVEL+1로 고정

Forest: 높이 50, plains처럼 요소 4개지만 토대가 높아요 → 숲 언덕.

Taiga: 높이 46, 요소 3개 → 중간 변동, 추운 지형.

Snowy plains: 높이 40, 요소 2개뿐 → 가장 험준.

h = (hash % 5) + ((hash >> 4) % 5);
// 결과: 최대 앞뒤 14블록 변동

각 바이오옴은 5개 항목 표 3개로 인코딩돼요. 토대 높이와 표면 블록, 요소 수. getHeightAtFromHash가 바이오옴을 받으면 이 표들을 봐서 지형을 조정해요. 바닐라 Minecraft 바이오옴 시스템 전체를 대신하는 자료 15바이트.

청크에 어떤 바이오옴이 해당하는지 시드로 정하는 바이오옴 감지기예요.

// worldgen.c (simplifié)

static const uint8_t biome_pattern[] = {
  BIOME_PLAINS, BIOME_FOREST, BIOME_PLAINS, BIOME_DESERT,
  BIOME_FOREST, BIOME_TAIGA,  BIOME_PLAINS, BIOME_SNOWY,
  BIOME_PLAINS, BIOME_FOREST, BIOME_DESERT,  BIOME_PLAINS,
  BIOME_SNOWY,  BIOME_PLAINS, BIOME_FOREST, BIOME_TAIGA,
};

uint8_t getChunkBiome (short cx, short cz) {
  uint32_t h = splitmix64(cx * 31 + cz * 97 + world_seed);
  uint8_t index = h % 16;
  return biome_pattern[index];
}

16개 항목 패턴 하나, 청크 좌표 시드 인덱스 하나. 반복 격자지만 시각적으로 일관돼요. 바닐라 Minecraft 바이오옴 매개변수 시스템 전체를 대신하는 코드 4줄.

getHeightAtFromHash: 지형 조립기

만들기 중심의 함수로 바이오옴 시드 점 4개를 합쳐요.

// worldgen.c (simplifié)

static uint8_t getHeightAtFromHash (int rx, int rz, short cx, short cz,
                                    uint32_t h, uint8_t biome) {
  // 해시에서 뽑은 점 4개, 점별 다른 시드
  uint8_t h1 = biome_base[biome] + (h & 0x0F);
  uint8_t h2 = biome_base[biome] + ((h >> 4) & 0x0F);
  uint8_t h3 = biome_base[biome] + ((h >> 8) & 0x0F);
  uint8_t h4 = biome_base[biome] + ((h >> 12) & 0x0F);

  // 바이오옴 제약: 사막은 절대 물속 없어요
  if (biome == BIOME_DESERT) {
    h1 = max(h1, SEA_LEVEL + 1);
    h2 = max(h2, SEA_LEVEL + 1);
    h3 = max(h3, SEA_LEVEL + 1);
    h4 = max(h4, SEA_LEVEL + 1);
  }

  // 4개 점에서 보간
  return interpolate(h1, h2, h3, h4, rx, rz);
}

각 바이오옴에 기준 높이를 옮기는 biome_base가 있고, 점 4개를 해시에서 다르게 이동시켜 뽑아요. 사막은 최소값을 해수면 위로 강제해요. 추가 바이오옴 계산 없이 물을 피하는 제약 한 줄.

나무와 선인장: 확률 배치

표면 만들기가 같은 청크 해시로 어디에 심을지 정해요.

// worldgen.c (simplifié)

static void genFoliage (uint8_t *chunk_data, short cx, short cz,
                        uint32_t hash, uint8_t biome) {
  if (biome == BIOME_DESERT) {
    // 선인장: 청크당 후보 하나, 해시가 위치를 정해요
    int tx = (hash >> 8) & 7;
    int tz = (hash >> 12) & 7;
    int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
    if (chunk_data[ty * 64 + tz * 8 + tx] == B_sand)
      placeCactus(chunk_data, tx, ty + 1, tz);
  } else {
    // 나무: 해시가 심는지 어디에 심는지 정해요
    int tree_count = (hash & 3);  // 청크당 나무 0-3그루
    for (int i = 0; i < tree_count; i ++) {
      int tx = ((hash >> (4 + i * 4)) & 7);
      int tz = ((hash >> (6 + i * 4)) & 7);
      int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
      placeTree(chunk_data, tx, ty + 1, tz);
    }
  }
}

초록 바이오옴에 청크당 나무 0~3그루, 사막에 선인장 최대 1개. 청크 해시가 유일한 엔트로피 원천이에요. 청크 속 위치에 & 7, 개수에 & 3. 전부 결정적이고 저장되는 것 없어요.

generateChunk: 전부 조립하기

8×8×256 블록 완전한 청크 하나를 만드는 모든 것을 합치는 함수예요.

// worldgen.c (simplifié)

void generateChunk (uint8_t *chunk, short cx, short cz) {
  uint32_t hash = getChunkHash(cx, cz);
  uint8_t biome = getChunkBiome(cx, cz);

  // 청크 각 열 (8×8 = 64)
  for (int x = 0; x < 8; x ++) {
    for (int z = 0; z < 8; z ++) {
      // 절대 월드 좌표
      int wx = cx * 8 + x;
      int wz = cz * 8 + z;

      // 열 높이
      uint8_t height = getHeightAt(wx, wz);

      // 아래에서 위로 열 채우기
      for (int y = 0; y < height; y ++) {
        uint8_t block = getTerrainBlock(wx, y, wz);
        chunk[y * 64 + z * 8 + x] = block;
      }
    }
  }

  // 표면 요소 더하기 (나무, 선인장)
  genFoliage(chunk, cx, cz, hash, biome);
}

그게 전부예요. 중첩 루프 3개: 열마다 높이를 찾고, 블록을 채우고, 다음으로 넘어가요. 출력은 완전한 청크를 나타내는 uint8_t[16384] (8 × 8 × 256)예요. 청크가 만들어지자마자 클라이언트에 바로 보내져요. 캐싱도 지연 불러오기도 압축도 거치지 않아요.

저장: 도처에 정적 배열

Bareiron 메모리 아키텍처가 임베디드 C 그 자체예요. 고정 크기 전역 표뿐. malloc도 해시 맵도 연결 리스트도 없어요.

블록 변경

// globals.h, lignes 191-196

typedef struct {
  short x;      // 2바이트: 가로 32,000블록 한도
  short z;      // 2바이트
  uint8_t y;    // 1바이트: 세로 256블록 한도
  uint8_t block; // 1바이트: 블록 종류 256개 한도
} BlockChange;

20,000개 항목, 약 25,000개 변경이에요. 청크 하나 반을 통째로 파낸 것과 같아요. block 필드 0xFF가 빈 항목 표시. 찾기는 선형 스캔이에요.

// procedures.c

uint8_t getBlockChange (short x, uint8_t y, short z) {
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block == 0xFF) continue;
    if (block_changes[i].x == x && block_changes[i].y == y && block_changes[i].z == z)
      return block_changes[i].block;
    #ifdef ALLOW_CHESTS
      if (block_changes[i].block == B_chest) i += 14;  // 상자 자료 건너뛰기
    #endif
  }
  return 0xFF;
}

변경 추가도 찾기만큼 직접적이에요.

static uint8_t changes_count = 0;

void addBlockChange (short x, short z, uint8_t y, uint8_t block) {
  if (changes_count >= MAX_CHANGES) return;
  block_changes[changes_count].x = x;
  block_changes[changes_count].z = z;
  block_changes[changes_count].y = y;
  block_changes[changes_count].block = block;
  changes_count ++;
}

카운터 하나, 인덱스 하나, 쓰기 하나. 표가 그냥 쌓아요. 정렬도 압축도 메모리 관리도 없어요. 표가 차면 새 변경이 무시돼요. 지형이 만든 상태로 돌아가요.

256블록 한도 저자 코멘트: "patiné légèrement ciré 구리 계단은 당분간 구현 안 할 거예요."

몹: 파이프 머리당 8바이트

// globals.h, lignes 240-251 (패딩 없애려고 pragma pack(push, 1))

typedef struct {
  uint8_t type;   // 25=닭, 28=소, 95=돼지, 106=양, 145=좀비
  short x;
  uint8_t y;      // health=0이면 Y가 삭제 전 타이머가 돼요
  short z;
  uint8_t data;   // 비트 0-4: 체력, 비트 5: 양털 깎임, 비트 6-7: 패닉 타이머
} MobData;

8바이트. 최대 16칸. 정렬과 패딩은 버려요. data 바이트는 집밥 비트필드예요. 체력 5비트, 깎임 1비트, 패닉 타이머 2비트. 그리고 몹이 죽으면 Y 필드가 삭제 전 타이머가 돼요. 비트 수준 메모리 재사용.

플레이어: 빽빽하게 넣기

플레이어 자료도 #pragma pack(push, 1)을 써요. 좌표는 short와 uint8_t, 인벤토리는 고정 uint16_t와 uint8_t 표, flags 필드가 공격 쿨다운과 스폰 상태, 숨기와 달리기, 먹기와 불러오기, 움직임 쿨다운, 제작 잠금을 비트 하나씩 인코딩해요. 전부 개별 비트에요.

주 루프: while(true)과 막히지 않기

서버 전체가 루프 하나로 돌아요. 스레드 하나, 이벤트 라이브러리 제로.

// main.c, lignes 594-720

while (true) {
  task_yield();  // ESP32에서 와치독이 숨 쉬게 해요

  // 새 연결 받기 (막히지 않아요)
  for (int i = 0; i < MAX_PLAYERS; i ++) {
    if (clients[i] != -1) continue;
    clients[i] = accept(server_fd, ...);
    if (clients[i] != -1) client_count ++;
    break;
  }

  // 시간이 됐으면 서버 틱
  if (get_program_time() - last_tick_time > TIME_BETWEEN_TICKS) {
    handleServerTick(time_since_last_tick);
    last_tick_time = get_program_time();
  }

  // 라운드 로빈: 반복마다 클라이언트 하나, 패킷 하나
  client_index = (client_index + 1) % MAX_PLAYERS;
  if (clients[client_index] == -1) continue;

  // 패킷 헤더 읽기: 길이 + ID
  recv(client_fd, &recv_buffer, 2, MSG_PEEK);
  int length = readVarInt(client_fd);
  int packet_id = readVarInt(client_fd);
  handlePacket(client_fd, length - sizeVarInt(packet_id), packet_id, state);
}

루프 반복마다 클라이언트 하나만 처리하고, 패킷 하나만 읽어요. 루프 앞 task_yield()가 ESP32에서 FreeRTOS idle 태스크가 숨 쉬게 해요. 없으면 와치독 타이머가 칩을 리셋해요.

패킷 보내기는 400줄 괴물 switch예요.

// main.c, lignes 68-497

void handlePacket (int client_fd, int length, int packet_id, int state) {
  switch (packet_id) {
    case 0x00:  // 상태 따라 Handshake와 Status, Login
    case 0x01:  // 상태 핑
    case 0x02:  // 플러그인 메시지
    case 0x03:  // 로그인과 설정 확인
    case 0x08:  // 채팅
    case 0x0B:  // 클라이언트 상태 (리스폰)
    case 0x11:  // 컨테이너 클릭 (상자 다뤄요)
    case 0x19:  // 개체 상호작용
    case 0x1D..0x20:  // 움직임 패킷 (가장 큰 경우)
    case 0x28:  // 플레이어 행동 (파기와 놓기)
    // ... 40개 이상 경우
  }
}

switch가 정적 점프 표로 컴파일돼서, 동적 점프 표와 vtable, 맵을 대신해요. 임베디드에 완벽해요.

0x1D-0x20 경우가 가장 커요. 위치 고치기와 낙하 피해, 청크 경계 넘기, 몹 스폰, 청크 만들기, 배고픔을 다뤄요. 하나의 큰 fall-through에 전부요.

서버 틱과 몹 AI

handleServerTick 함수가 50ms마다 (20 TPS) 불려요. 주 루프가 플레이어를 맡는 동안 월드를 다뤄요.

// main.c (simplifié)

void handleServerTick (uint32_t delta) {
  // 몹마다 고치기
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type == 0 || mobs[i].data == 0) continue;  // 죽었거나 빔

    MobData *mob = &mobs[i];
    int px, pz;
    getNearestPlayer(mob->x, mob->z, &px, &pz);

    if (mob->type == MOB_ZOMBIE) {
      // 적대적: 가장 가까운 플레이어 쪽으로 걸어요
      if (px < mob->x) mob->x --;
      else if (px > mob->x) mob->x ++;
      if (pz < mob->z) mob->z --;
      else if (pz > mob->z) mob->z ++;
      // 2블록 접촉 피해
      if (abs(px - mob->x) <= 2 && abs(pz - mob->z) <= 2)
        damagePlayer(getNearestPlayerId(mob->x, mob->z), 3);
    } else {
      // 수동적: 무작위 8방향
      uint8_t dir = getMobDir(mob);
      mob->x += dir_lookup[dir][0];
      mob->z += dir_lookup[dir][1];
      // ~40틱마다 방향 바꾸기
      if (mob->data >> 6 < 1) setMobDir(mob, rand() & 7);
      mob->data = (mob->data & 0x3F) | ((mob->data - 0x40) & 0xC0);
    }

    // 몹 주변 청크 깨우기
    setChunkGenerated(mob->x / 8, mob->z / 8);
  }
}

적대 몹 AI가 좌표 비교예요. 말 그대로 if (px < x) x--. 좀비는 길찾기, A*, 장애물 회피를 무시해요. X와 Z를 플레이어 쪽으로 독립 조정해요. 벽이 있으면 통과해요.

접촉 피해는 초당 3하트. 길찾기 부재 때문에 좀비가 끌고 다니기 쉬워서 p2r3가 높게 원했어요.

방어구 공식은 전투 고치기 전, 가장 단순한 것이에요.

// main.c (simplifié)

static uint8_t applyArmor (uint8_t damage, uint16_t armor_value) {
  // 1.9 전 공식: 선형 감소
  // 방어구 1점 = 4% 감소, 최대 80%
  uint8_t reduction = (armor_value * 4);
  if (reduction > 80) reduction = 80;
  return damage * (100 - reduction) / 100;
}

풀 다이아몬드 = 80% 감소. 좀비 타격 3하트가 0.6하트가 돼요. p2r3가 이 옛 공식을 고른 것은 연산 2개로 계산돼서예요. 임계도 곡선도 없고 그냥 선형 백분율.

수동 몹: 조회 표에 방향 8개, ~40틱마다 방향 바꾸기. data 필드가 진행 방향을 상위 2비트에, 방향 바꾸기 타이머를 나머지 6비트에 인코딩해요.

몹 리스폰

몹은 무작위 틱으로 스폰하지 않아요. 서버 틱이 새 청크 경계를 만나면 나타나고.

if (player crossed chunk boundary) {
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type != 0) continue;
    spawnMob(&mobs[i], new_chunk_coords, getChunkHash(cx, cz));
    break;
  }
}

지형과 같은 RNG, 같은 청크 시드. 몹 자리가 비었으면 스폰이 결정적이에요.

제작: 행렬 없이 if와 else

// crafting.c, lignes 9-347 (simplifié)

void getCraftingOutput (PlayerData *player, uint8_t *count, uint16_t *item) {
  // 0x80 깃발이 서면 제작 버퍼가 상자 포인터로 쓰여요
  if (player->flags & 0x80) { *count = 0; *item = 0; return; }

  // 칸 세기, 첫 아이템 찾기, 같은지 확인
  uint8_t filled = 0, first = 10, identical = true;
  for (int i = 0; i < 9; i ++) {
    if (player->craft_items[i]) {
      filled ++;
      if (first == 10) first = i;
      else if (player->craft_items[i] != player->craft_items[first])
        identical = false;
    }
  }

  switch (filled) {
    case 1:  /* 판자, 주괴... */
    case 2:  /* 막대, 가위, 횃불 */
    case 3:  /* 삽, 검, 반 블록 */
    case 4:  /* 작업대, 부츠 */
    case 5:  /* 곡괭이, 도끼, 투구 */
    case 7:  /* 바지, 퇴비통 */
    case 8:  /* 화로, 상자, 흉갑 */
    case 9:  /* 완전한 블록 (철, 금 등) */
  }
}

첫 확인: 0x80 깃발이 서면 제작 버퍼가 상자 포인터로 재활용돼요. 제작이 잠겨요.

다음에 찬 칸을 세고, 첫 아이템을 적고, 같은지 확인해요. 이것만으로 화로를 검사 4개로 맞춰요.

if (count == 8 && first == cobblestone && all_identical && center_empty)
    return furnace;

복잡한 모양은 첫 아이템 인덱스를 쓰고 상대 위치를 확인해요. 레시피가 같은 맞추기 함수를 공유해요. 재료가 결과를 정해요.

상자: 진짜 메모리 핵

모두가 말하는 메모리 핵, 진짜 코드로요.

// procedures.c, lignes 1262-1293

if (target == B_chest) {
  // 블록 표에서 상자 항목 찾기
  uint8_t *storage_ptr = NULL;
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block != B_chest) continue;
    if (block_changes[i].x != x || block_changes[i].y != y || block_changes[i].z != z)
      continue;
    storage_ptr = (uint8_t *)(&block_changes[i + 1]);  // 상자 블록 다음을 가리켜요
    break;
  }
  if (storage_ptr == NULL) return;

  // 끔찍한 메모리 핵!!
  // 포인터를 플레이어 제작 아이템 표에 복사해요
  memcpy(player->craft_items, &storage_ptr, sizeof(storage_ptr));
  player->flags |= 0x80;  // 제작을 잠가요

  // 클라이언트에 상자 인터페이스 보내기
  sc_openScreen(player->client_fd, 2, "Chest", 5);
  for (int i = 0; i < 27; i ++) {
    uint16_t item;
    uint8_t count;
    memcpy(&item, storage_ptr + i * 3, 2);
    memcpy(&count, storage_ptr + i * 3 + 2, 1);
    sc_setContainerSlot(player->client_fd, 2, i, count, item);
  }
}

코드 주석에도요. // Terrible memory hack!!1!

정확히 그거예요. block_changes[]의 다음 항목 메모리 주소를 가져와 player->craft_items(uint16_t[9], 18바이트라서 32비트 포인터를 저장하기 충분)에 복사하고, 그사이 아무도 제작하지 못하게 깃발을 세워요.

상자 인벤토리 클릭마다요.

// packets.c, lignes 620-638

uint8_t *storage_ptr;
memcpy(&storage_ptr, player->craft_items, sizeof(storage_ptr));
// storage_ptr이 이제 상자 자료를 가리켜요
uint16_t *p_item = (uint16_t *)(storage_ptr + (slot - 41) * 3);
uint8_t *p_count = storage_ptr + (slot - 41) * 3 + 2;

제작 버퍼에서 포인터를 가져와 오프셋으로 칸에 닿아요. 상자 자료가 칸마다 3바이트 (ID 2개, 수량 1개)로 블록 표에 붙어서 저장돼요.

배고픔: 5줄 천재

// main.c, lignes 293-305

// 플레이어가 움직이면 초당 ~20개, 가만히 있으면 훨씬 적은 움직임 패킷을 보내요.
// 공짜로 배고픔을 흉내 내려 활동과 연관시켜요.
if (player->saturation == 0) {
  if (player->hunger > 0) player->hunger--;
  player->saturation = 200;
  sc_setHealth(client_fd, player->health, player->hunger, player->saturation);
} else if (player->flags & 0x08) {  // 달리기
  player->saturation -= 1;
}
}

말 그대로 그거예요. 5줄. 움직임 패킷마다 포만감이 내려가요. 포만감이 0이 되면 배고픔이 내려가고 포만감을 리셋해요. 달리기(깃발 0x08)가 소모를 2배로 해요.

타이머 제로, 할당 메모리 제로, 전용 계산 제로. 이미 존재하는 패킷에 내려가는 카운터 하나.

낙하 피해

프로젝트에서 가장 단순한 피해 시스템이에요.

// 땅을 떠나면 Y를 저장해요
// 땅에 다시 닿으면 빼요
degats = dernier_y_au_sol - y_actuel;

뺄셈 하나.

블록 캐기와 놓기

블록을 누르면 패킷 0x28(Player Action)이 switch에 떨어져요. 핸들러가 위치에 어떤 블록이 있는지 정하고, 없애고, 아이템을 인벤토리에 넣어야 해요.

// main.c, case 0x28 (simplifié)

void handlePlayerAction (int client_fd, uint8_t action, int x, uint8_t y, int z) {
  switch (action) {
    case START_DESTROY_BLOCK: {
      // 누른 위치 블록 종류 정하기
      uint8_t block = getBlockAt(x, y, z);

      if (block == B_chest) {
        openChest(client_fd, x, y, z);
        break;
      }

      // block_changes에 더하기
      addBlockChange(x, z, y, 0);  // 0 = 공기

      // 플레이어에게 아이템 주기 (클라이언트를 믿어요)
      addItemToPlayer(client_fd, block_to_item(block), 1);

      // 클라이언트에 고치기 보내기
      sc_blockChange(client_fd, x, y, z, 0);
      sc_ackBlockChange(client_fd, x, y, z, 0);
      break;
    }
    case PLACE_BLOCK: {
      // 플레이어 손에서 블록 종류 읽기
      uint16_t item = getHeldItem(client_fd);
      uint8_t block = item_to_block(item);
      addBlockChange(x, z, y, block);
      removeItemFromPlayer(client_fd, item, 1);
      sc_blockChange(client_fd, x, y, z, block);
      break;
    }
  }
}

getBlockAt이 지형 만들기와 플레이어 변경을 합쳐요.

uint8_t getBlockAt (int x, uint8_t y, int z) {
  // 먼저 플레이어 변경 확인
  uint8_t change = getBlockChange(x, y, z);
  if (change != 0xFF) return change;

  // 아니면 만든 지형에서 읽기
  return getTerrainBlock(x, y, z);
}

변경 우선, 지형 폴백. 논쟁 제로, 캐시 제로, 부담 제로. 밑의 getTerrainBlock은 getHeightAt와 stone과 dirt, grass, coal 층이에요.

즉석 화로

가장 웃긴 것: 화로가 개체로 존재하지 않아요. "굽기" 칸에 조약돌을 놓고 "연료"에 석탄을 놓으면 결과물이 바로 나와요. 타이머도 청크 틱도 없어요. 맞는 아이템을 넣으면 비워지는 인벤토리 칸일 뿐이에요.

ESP32 루프: 4KB 스택 속 MC 서버

// main.c, lignes 732-779

#ifdef ESP_PLATFORM

void bareiron_main (void *pvParameters) {
  main();
  vTaskDelete(NULL);
}

static void wifi_event_handler (...) {
  if (/* connecté */) {
    xTaskCreate(bareiron_main, "bareiron", 4096, NULL, 5, NULL);
  }
}

void app_main () {
  esp_timer_early_init();
  wifi_init();
  // 나머지는 이벤트 핸들러가 다뤄요
}
#endif

서버 전체가 4096바이트 스택 FreeRTOS 태스크에서 돌아요. 그게 전부예요. 주 스레드는 WiFi를 초기화하고 연결을 기다릴 뿐이에요. 연결되면 표준 main()을 부르는 bareiron_main을 만들어요.

ESP32 전용 코드는 모두 #ifdef ESP_PLATFORM으로 지켜져요. PC에서는 전부 표준 POSIX 코드로 컴파일돼요.

희생된 것

이 모든 것이 들어가려고 바닐라 기능 중 없는 것들이 있어요.

• 네트워크 압축 제로: zlib가 너무 비싸요. 서버가 청크를 빨리 만들지만 보내는 것이 병목이에요.
• 무작위 틱 제로: 나무가 뼛가루로 자라거나 아니에요. 몹이 청크 경계에 스폰해요.
• 아이템 개체 제로: 캔 블록이 바로 인벤토리에 가요. 애니메이션은 순수 시각.
• 인벤토리 검사 없음: 클라이언트를 믿어요. 다이아몬드 64개? 좋아요. 1초에 캔 청크? 좋아요. 믿을 만한 사람들 사이에서 쓰세요.
• 서버 조명 제로: 횃불이 맨 마지막에 보내지고 클라이언트가 계산해요.
• 점진 유체 제로: 바로 최종 상태.

최종 결과

Ryzen 5 3600: 청크당 ~0.5ms. 1달러 ESP32-C3: 청크당 ~200ms. 할 만해요.

3명 이상 플레이어: 버벅여요. 저자 말로 피크 시간 2b2t와 비슷해요.

철학

p2r3: "0.5와트 먹는 1달러짜리 작은 칩이 Minecraft만큼 진보한 것을 돌릴 수 있다는 생각이 좋아요. 과학은 '왜'가 아니라 '왜 안 돼'가 아니에요."

매 줄이 맞바꾸기예요.

• Perlin 노이즈에서 보간: 덜 예쁘고 200배 빠르고 메모리 제로
• 제작 행렬에서 하드코딩 맞추기: 지저분한 코드, 바이트 제로
• zlib에서 없음: 연결이 구리면 죽음이지만 할 만해요
• 검증에서 믿음: 보안 제로, 계산 제로

빠진 기능마다 하드웨어 한도 안에서 다른 기능이 존재하게 해요.

기억할 3가지:

1. 보간 + RNG: 시드 점 4개, 무한 지형, 저장 제로, 청크 다시 만들지 않고 묻기, 200ms 만들기. 나머지 모두를 가능하게 하는 천재 수예요.
2. 기능마다 비용이 있어요: 압축과 무작위 틱, 검증 부재는 가정한 선택이에요. 520KB에 들어가는 것이 바로 그 덕분이에요.
3. 지저분한 핵이 가장 영리해요: memcpy로 블록 표 속 상자, 움직임 패킷으로 배고픔, 즉석 화로. 깔끔한 해법은 너무 비쌌을 거예요.

프로젝트에 관심 있으면 전부 GPLv3 GitHub에 있어요. 제대로 지저분한 C고, 소스 코드를 읽으면서 이렇게 즐거웠던 적이 드물어요.

Giriş

Hiç bir Minecraft sunucusunu 1 liraya bir mikrodenetleyicide çalıştırabileceğini merak ettin mi?

Ben ettim. Ve cevap evet. Resmen.

Bareiron diye bir proje var, p2r3 imzalı, ve muhtemelen son yıllarda Minecraft dünyasında gördüğüm en büyüleyici projelerden biri. 300 kilobayta sığan bir binary'den bahsediyoruz, 6800 satır C, sıfır harici bağımlılık, malloc yok, threading yok, ve 1 dolarlık bir ESP32'de çalışıyor.

Sonsuz arazi üretimi. Biyomlar. Mağaralar. Craft. Madencilik. Mob'lar. Açlık. Sandıklar. Bir survival sunucusundan beklediğin her şey.

0.5 Watt tüketen ve 160 MHz saat hızına sahip bir çipte.

Fikir vermesi açısından: vanilla bir Minecraft sunucusu birkaç giga RAM'e ihtiyaç duyar. ESP32-C3 ise 520 KB SRAM'e sahip (boot'tan sonra 400'ü kullanılabilir). 20 yıl önceki işlemciler zaten gigahertz'de çalışıyordu -- bu 160 MHz'de takılı kalıyor. Saf güç açısından ikisi arasındaki fark yaklaşık 20 000.

p2r3 C dilinde bir Minecraft sunucusu yazmadı, sunucunun her bir tuğlasını bu kısıtlamalara sığacak şekilde yeniden icat etti. Kaynak kodu açarak nasıl yaptığına bakalım.

Projenin beyni: hafızasız arazi üretimi

Gömülü bir MC sunucusu yapmak istediğinde en büyük sorun arazi üretimi.

Vanilla Minecraft'ta dünya Perlin gürültüsü ile üretilir: üst üste bindirilmiş birkaç katman (oktavlar), 6 biyomik parametre (sıcaklık, nem, karasallık, erozyon, tuhaflık, derinlik) ve her seferinde her şeyi yeniden hesaplamamak için kocaman bir önbellekleme sistemi.

Sonuç muhteşem. Ama hesaplama açısından pahalı ve üretilen chunk'ları depolamak için RAM gerektiriyor.

Bareiron'un yaklaşımı radikal biçimde farklı. Gürültü yığmak yerine, deterministik bir RNG tarafından üretilen 4 nokta üzerinde bilinear interpolasyon kullanıyor.

Küçük pikselli bir resmi büyüttüğünde kenarların bulanıklaştığını bilirsin? Aynen öyle.

// worldgen.c, satırlar 117-171 (basitleştirilmiş)

uint8_t interpolate (uint8_t a, uint8_t b, uint8_t c, uint8_t d, int x, int z) {
  uint16_t top    = a * (CHUNK_SIZE - x) + b * x;
  uint16_t bottom = c * (CHUNK_SIZE - x) + d * x;
  return (top * (CHUNK_SIZE - z) + bottom * z) / (CHUNK_SIZE * CHUNK_SIZE);
}

uint8_t getHeightAt (int x, int z) {
  int _x = floor(x / CHUNK_SIZE);  // chunk koordinatları
  int _z = floor(z / CHUNK_SIZE);
  int rx = x % CHUNK_SIZE;          // chunk içi offset
  int rz = z % CHUNK_SIZE;
  uint32_t hash = getChunkHash(_x, _z);
  uint8_t biome = getChunkBiome(_x, _z);
  // hash + biome ile tohumlanmış 4 köşe arasında interpolasyon
  return getHeightAtFromHash(rx, rz, _x, _z, hash, biome);
}

Standart bilinear interpolasyon: 4 köşe, pozisyona göre ağırlıklar, çıktıda tek bir uint8_t. CHUNK_SIZE 8, yani tamsayı çarpmalarıyla yapılıyor, float yok.

p2r3 bunu videoda adım adım gösteriyor: önce chunk'ın 4 köşesi, her biri RNG tarafından tohumlanmış bir yüksekliğe sahip.

Sonra bu 4 nokta arasındaki interpolasyon sürekli bir yüzey oluşturuyor.

Ve bu deseni tüm bitişik chunk'larda tekrarlayarak sonsuza uzanan bir arazi elde ediyorsun.

Deterministik RNG

Bunu mümkün kılan anahtar şey tohumlama. Her chunk'ın 4 köşesi var ve her köşenin benzersiz ama tekrarlanabilir bir sözde rastgele değere ihtiyacı var.

// worldgen.c, satırlar 13-22

uint32_t getChunkHash (short x, short z) {
  uint8_t buf[8];
  memcpy(buf, &x, 2);          // 16 bit X koordinatı
  memcpy(buf + 2, &z, 2);      // 16 bit Z koordinatı
  memcpy(buf + 4, &world_seed, 4);  // 32 bit global tohum
  return splitmix64(*((uint64_t *)buf));  // hash
}

16 bit X, 16 bit Z ve 32 bit tohumu 8 baytlık bir buffer'a paketliyor ve hepsini splitmix64'ten geçiriyor. Sonuç: dünyanın tohumuna dayalı olarak her pozisyon için deterministik benzersiz bir değer.

Olayın gücünü anlıyor musun? Sunucunun araziyi depolaması gerekmiyor. Oyuncu yeni bir bölgeye geldiğinde anında yeniden hesaplıyor ve her seferinde tam olarak aynı sonucu veriyor.

Kullanılan splitmix64, 64 bit hash'ler için tasarlanmış ultra hızlı bir prng:

// worldgen.c (basitleştirilmiş)

static uint32_t splitmix64 (uint64_t state) {
  state += 0x9E3779B97F4A7C15ull;
  uint64_t z = state;
  z = (z ^ (z >> 30)) * 0xBF58476D1CE4E5B9ull;
  z = (z ^ (z >> 27)) * 0x94D049BB133111EBull;
  return (z ^ (z >> 31)) >> 32;
}

3 işlem: toplama, xor/kaydırma, çarpma, xor/kaydırma, çarpma, xor/kaydırma. Lookup table yok, döngü yok. 8 baytlık buffer'ı (X + Z + tohum) alıyor, 64 bitlik bir tamsayı olarak işliyor ve 32 bit hash döndürüyor. Deterministik, hızlı ve 5 satıra sığıyor.

Neden Perlin gürültüsü değil

p2r3'ün videoda kendi dediği gibi: "rastgele sayıya ne kadar çok basamak eklersen, arazi o kadar düzenli hale gelir, tıpkı daha fazla yazı tura atmanın seni 50/50'ye yaklaştırması gibi". Pratikte, birleştirdiği hash bitlerinin sayısı:

// worldgen.c, satırlar 51-115

// Plains biyomu için: 4 birleştirilmiş faktör → düzenli arazi
h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// Snowy plains için: 2 faktör → daha engebeli
h = (hash % 5) + ((hash >> 4) % 5);

Her biyom kaç bit çıkarımı birleştireceğini seçiyor. Ne kadar çok olursa, dağılım o kadar dengelenir -- tıpkı 50/50'ye yaklaşan daha fazla yazı tura atışı gibi. Az olduğunda, yerel varyasyonlar daha güçlü olur.

Sadece 2 faktörle, snowy plains neredeyse dağlık, inişli çıkışlı bir arazi üretiyor. Tepe ve çukurlar sık.

4 faktörle, ovalar düz ve tahmin edilebilir kalıyor. Dağılım dengeleniyor.

Bir chunk, ESP32'de 200 ms'de üretiliyor -- aynı donanımda Perlin gürültüsüyle ölçülemeyecek kadar pahalıyken.

Can alıcı detay: tüm chunk'ı üretmeden bir bloğu sorgulamak

Oynuyorsun, bir bloğu kazıyorsun. Sunucu sana hangi item'i vereceğini bilmeli. Safça, bunun için tüm chunk'ı üretmek gerekirdi.

Bilinear interpolasyonla, düzlemdeki herhangi bir noktayı doğrudan koordinatlardan sorgulayabiliyorsun. Chunk'ın köşeleri oyuncunun konumundan elde ediliyor, interpolasyon sana herhangi bir offset'teki yüksekliği veriyor. Bir avuç matematik işlemi, chunk üretimi yok.

p2r3: "istediğim şey, bana verilen bir koordinattaki bloğu söyleyebilecek, hafızaya erişmeden veya pahalı gürültü haritaları hesaplamadan çalışan sihirli bir fonksiyon". Aynen yaptığı şey.

İşte yüksekliğin somut bloklara dönüşmesi:

// worldgen.c (basitleştirilmiş)

uint8_t getTerrainBlock (int x, uint8_t y, int z) {
  uint8_t surface = getHeightAt(x, z);

  if (y > surface)             return B_air;
  if (y == surface)            return biome_top[getChunkBiome(x, z)];
  if (y > surface - 4)         return B_dirt;
  if (y > surface - 16)        return B_stone;
  if (y > CAVE_BASE_DEPTH)     return B_deepslate;
                               return B_bedrock;
}

5 koşul. Bir katman grass/dirt/stone/deepslate/bedrock. Yüzey bloğu biome_top[] aracılığıyla biyoma bağlı -- ovalar için grass, çöl için sand. Döngü yok, switch yok, doğru katmana düşen bir if basamaklaması.

Mağaralar, en tembel mirror

mağara_yüksekliği = CAVE_BASE_DEPTH - (yüzey_yüksekliği - y);

Yüzey yüksekliğini yer altında aynalıyor. Büyük deepslate boşluklarına benziyor. Sıfır hesaplama, tek satır.

Cevherler, XOR versiyonu

aday = (chunk_x ^ col_x ^ col_z) % 100;
if (aday < 5 && y < 16) -> diamond

Koordinatların XOR'u sütun başına bir aday garantiliyor. Tür sadece yüksekliğe bağlı. Elmaslar mağaraların en alt noktasının altına saklanmış, böylece kazmak mantıklı kalıyor.

Biyomlar tile map'te

Her biyom bir ızgarada dairesel bir ada, türü tohumdan hesaplanan bir desenle belirleniyor. Izgaralı, tahmin edilebilir ve beleş.

Her biyomun dizilerde kodlanmış kendi parametre seti var:

// worldgen.c (basitleştirilmiş)

static const uint8_t biome_base[] = {
  [BIOME_PLAINS]  = 48,   // taban yükseklik: 48
  [BIOME_DESERT]  = 52,   // biraz daha yüksek
  [BIOME_FOREST]  = 50,   // ikisinin arası
  [BIOME_TAIGA]   = 46,   // biraz daha alçak
  [BIOME_SNOWY]   = 40,   // en alçak
};

static const uint8_t biome_top[] = {
  [BIOME_PLAINS]  = B_grass,
  [BIOME_DESERT]  = B_sand,
  [BIOME_FOREST]  = B_grass,
  [BIOME_TAIGA]   = B_grass,
  [BIOME_SNOWY]   = B_snow_block,
};

static const uint8_t biome_factors[] = {
  [BIOME_PLAINS]  = 4,   // 4 çıkarım → çok düzenli
  [BIOME_DESERT]  = 3,   // 3 çıkarım → orta
  [BIOME_FOREST]  = 4,   // 4 çıkarım → düzenli, inişli çıkışlı
  [BIOME_TAIGA]   = 3,   // 3 çıkarım → orta
  [BIOME_SNOWY]   = 2,   // 2 çıkarım → çok engebeli
};

Plains: yükseklik 48, 4 faktör → çok düz arazi, çimen.

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// Sonuç: maksimum ±4 blok varyasyon

Desert: yükseklik 52, 3 faktör, yüzey bloğu = kum. Asla deniz seviyesinin altında değil.

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3);
// Sonuç: maksimum ±6 blok varyasyon, SEA_LEVEL+1'e kenetlenmiş

Forest: yükseklik 50, plains gibi 4 faktör ama taban daha yüksek → ormanlık tepeler.

Taiga: yükseklik 46, 3 faktör → orta varyasyonlar, soğuk arazi.

Snowy plains: yükseklik 40, sadece 2 faktör → en engebelisi.

h = (hash % 5) + ((hash >> 4) % 5);
// Sonuç: maksimum ±14 blok varyasyon

Her biyom 3 dizi, 5 giriş ile kodlanmış: taban yükseklik, yüzey bloğu, faktör sayısı. getHeightAtFromHash biyomu aldığında, arazinin ayarlanması için bu dizilere bakıyor. Minecraft'ın tüm biyom sistemini değiştirmek için 15 byte veri.

Biyom dedektörü, her chunk'a hangi biyomun karşılık geldiğini belirlemek için tohumu kullanıyor:

// worldgen.c (basitleştirilmiş)

static const uint8_t biome_pattern[] = {
  BIOME_PLAINS, BIOME_FOREST, BIOME_PLAINS, BIOME_DESERT,
  BIOME_FOREST, BIOME_TAIGA,  BIOME_PLAINS, BIOME_SNOWY,
  BIOME_PLAINS, BIOME_FOREST, BIOME_DESERT,  BIOME_PLAINS,
  BIOME_SNOWY,  BIOME_PLAINS, BIOME_FOREST, BIOME_TAIGA,
};

uint8_t getChunkBiome (short cx, short cz) {
  uint32_t h = splitmix64(cx * 31 + cz * 97 + world_seed);
  uint8_t index = h % 16;
  return biome_pattern[index];
}

16 girişlik bir desen, chunk koordinatlarıyla tohumlanmış bir index. Tekrarlı ama görsel olarak tutarlı bir ızgara veriyor. Vanilla Minecraft'ın tüm biyomik parametre sistemini değiştirmek için 4 satır kod.

getHeightAtFromHash: arazi montajcısı

Üretimin kalbindeki fonksiyon, biyomla tohumlanmış 4 köşeyi birleştiriyor:

// worldgen.c (basitleştirilmiş)

static uint8_t getHeightAtFromHash (int rx, int rz, short cx, short cz,
                                    uint32_t h, uint8_t biome) {
  // Hashten çıkarılan 4 köşe, her köşe için farklı tohum
  uint8_t h1 = biome_base[biome] + (h & 0x0F);
  uint8_t h2 = biome_base[biome] + ((h >> 4) & 0x0F);
  uint8_t h3 = biome_base[biome] + ((h >> 8) & 0x0F);
  uint8_t h4 = biome_base[biome] + ((h >> 12) & 0x0F);

  // Biyom kısıtlaması: çöl asla su altında değil
  if (biome == BIOME_DESERT) {
    h1 = max(h1, SEA_LEVEL + 1);
    h2 = max(h2, SEA_LEVEL + 1);
    h3 = max(h3, SEA_LEVEL + 1);
    h4 = max(h4, SEA_LEVEL + 1);
  }

  // 4 köşeden interpolasyon
  return interpolate(h1, h2, h3, h4, rx, rz);
}

Her biyomun referans yüksekliği kaydıran bir biome_base'i var ve 4 köşe farklı kaydırmalarla hashten çıkarılıyor. Çöl, minimumu deniz seviyesinin üstüne zorluyor -- ek biyomik hesaplama gerektirmeden suyu önleyen tek satırlık bir kısıtlama.

Ağaçlar ve kaktüsler: olasılıksal yerleştirme

Yüzey üretimi, nereye dikeceğine karar vermek için aynı chunk hash'ini kullanıyor:

// worldgen.c (basitleştirilmiş)

static void genFoliage (uint8_t *chunk_data, short cx, short cz,
                        uint32_t hash, uint8_t biome) {
  if (biome == BIOME_DESERT) {
    // Kaktüs: chunk başına bir aday, hash pozisyonu belirliyor
    int tx = (hash >> 8) & 7;
    int tz = (hash >> 12) & 7;
    int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
    if (chunk_data[ty * 64 + tz * 8 + tx] == B_sand)
      placeCactus(chunk_data, tx, ty + 1, tz);
  } else {
    // Ağaçlar: hash koyup koymayacağını ve nereye koyacağını belirliyor
    int tree_count = (hash & 3);  // chunk başına 0-3 ağaç
    for (int i = 0; i < tree_count; i ++) {
      int tx = ((hash >> (4 + i * 4)) & 7);
      int tz = ((hash >> (6 + i * 4)) & 7);
      int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
      placeTree(chunk_data, tx, ty + 1, tz);
    }
  }
}

Yeşil biyomlar için chunk başına 0-3 ağaç, çöl için maksimum 1 kaktüs. Chunk'ın hash'i tek entropi kaynağı -- chunk içindeki pozisyon için & 7, sayaç için & 3. Her şey deterministik, hiçbir şey depolanmıyor.

generateChunk: hepsini birleştirmek

8×8×256 blokluk tam bir chunk üretmek için her şeyi bir araya getiren fonksiyon:

// worldgen.c (basitleştirilmiş)

void generateChunk (uint8_t *chunk, short cx, short cz) {
  uint32_t hash = getChunkHash(cx, cz);
  uint8_t biome = getChunkBiome(cx, cz);

  // Chunk'taki her sütun için (8×8 = 64)
  for (int x = 0; x < 8; x ++) {
    for (int z = 0; z < 8; z ++) {
      // Mutlak dünya koordinatları
      int wx = cx * 8 + x;
      int wz = cz * 8 + z;

      // Sütun yüksekliği
      uint8_t height = getHeightAt(wx, wz);

      // Sütunu aşağıdan yukarıya doldur
      for (int y = 0; y < height; y ++) {
        uint8_t block = getTerrainBlock(wx, y, wz);
        chunk[y * 64 + z * 8 + x] = block;
      }
    }
  }

  // Yüzey öğelerini ekle (ağaçlar, kaktüsler)
  genFoliage(chunk, cx, cz, hash, biome);
}

Hepsi bu kadar. 3 iç içe döngü: her sütun için, yüksekliği bul, blokları doldur, bir sonrakine geç. Çıktı, tam chunk'ı temsil eden bir uint8_t[16384] (8 × 8 × 256). Önbellekleme yok, lazy loading yok, sıkıştırma yok -- chunk üretilir ve direkt istemciye gönderilir.

Depolama: her yerde statik diziler

Bareiron'un bellek mimarisi, tüm ihtişamıyla gömülü C. Malloc yok, hash map yok, bağlı liste yok.

Her şey sabit boyutlu global dizilerde.

Blok değişiklikleri

// globals.h, satırlar 191-196

typedef struct {
  short x;      // 2 byte -- yatayda 32 000 blok sınırı
  short z;      // 2 byte
  uint8_t y;    // 1 byte -- dikeyde 256 blok sınırı
  uint8_t block; // 1 byte -- 256 blok türü sınırı
} BlockChange;

20 000 giriş, yani yaklaşık 25 000 değişiklik -- tamamen kazılmış bir buçuk chunk'a eşdeğer. 0xFF değerindeki block alanı boş bir girişi işaretler. Arama doğrusal taramadır:

// procedures.c

uint8_t getBlockChange (short x, uint8_t y, short z) {
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block == 0xFF) continue;
    if (block_changes[i].x == x && block_changes[i].y == y && block_changes[i].z == z)
      return block_changes[i].block;
    #ifdef ALLOW_CHESTS
      if (block_changes[i].block == B_chest) i += 14;  // sandık verilerini atla
    #endif
  }
  return 0xFF;
}

Değişiklik eklemek de arama kadar doğrudan:

```c
static uint8_t changes_count = 0;

void addBlockChange (short x, short z, uint8_t y, uint8_t block) {
  if (changes_count >= MAX_CHANGES) return;
  block_changes[changes_count].x = x;
  block_changes[changes_count].z = z;
  block_changes[changes_count].y = y;
  block_changes[changes_count].block = block;
  changes_count ++;
}

Bir sayaç, bir index, bir yazma. Sıralama yok, sıkıştırma yok, bellek yönetimi yok. Dizi dolduğunda, yeni değişiklikler yok sayılır -- arazi üretilmiş haline döner.

Yazarın 256 blok sınırı hakkındaki yorumu: "hafifçe patinalanmış cilalı bakır merdivenleri henüz uygulamayı düşünmüyorum."

Mob'lar: kelle başına 8 byte

// globals.h, satırlar 240-251 (padding'i yok etmek için pragma pack(push, 1))

typedef struct {
  uint8_t type;   // 25=tavuk, 28=inek, 95=domuz, 106=koyun, 145=zombi
  short x;
  uint8_t y;      // health=0 ise, Y silinmeden önce bir zamanlayıcı olur
  short z;
  uint8_t data;   // bit 0-4: can, bit 5: koyun kırkılmış, bit 6-7: panik zamanlayıcısı
} MobData;

8 byte. Maksimum 16 yuva. Hizalama yok, padding yok. data byte'ı ev yapımı bir bitfield: 5 bit can, 1 bit kırkma, 2 bit panik zamanlayıcısı. Bir mob öldüğünde, Y alanı silinmeden önce bir zamanlayıcı olur. Bit seviyesinde bellek yeniden kullanımı.

Oyuncular: sıkışık paketlenmiş

Oyuncu verileri de #pragma pack(push, 1) kullanır -- short + uint8 cinsinden koordinatlar, uint16_t + uint8_t sabit dizilerinde envanterler ve aynı anda saldırı bekleme süresini, spawn durumunu, sneak, sprint, eat, load, movement cooldown ve craft kilidini kodlayan bir flags alanı. Bunların hepsi tek tek bitlerde.

Ana döngü: while(true) ve bloklamayan

Tüm sunucu tek bir döngüde, tek bir thread'de, sıfır event library ile çalışıyor.

// main.c, satırlar 594-720

while (true) {
  task_yield();  // ESP32'de watchdog'u rahat bırak

  // Yeni bir bağlantı kabul et (bloklamayan)
  for (int i = 0; i < MAX_PLAYERS; i ++) {
    if (clients[i] != -1) continue;
    clients[i] = accept(server_fd, ...);
    if (clients[i] != -1) client_count ++;
    break;
  }

  // Zaman dolduysa sunucu tick'i
  if (get_program_time() - last_tick_time > TIME_BETWEEN_TICKS) {
    handleServerTick(time_since_last_tick);
    last_tick_time = get_program_time();
  }

  // Round-robin: her iterasyonda bir istemci, bir paket
  client_index = (client_index + 1) % MAX_PLAYERS;
  if (clients[client_index] == -1) continue;

  // Paket başlığını oku: uzunluk + ID
  recv(client_fd, &recv_buffer, 2, MSG_PEEK);
  int length = readVarInt(client_fd);
  int packet_id = readVarInt(client_fd);
  handlePacket(client_fd, length - sizeVarInt(packet_id), packet_id, state);
}

Döngünün her iterasyonunda tek bir istemci işlenir ve aynı anda tek bir paket okunur. Döngünun başındaki task_yield(), FreeRTOS boşta kalma görevinin ESP32'de nefes almasını sağlar -- bu olmadan watchdog timer çipi sıfırlar.

Paket dağıtımı, 400 satırlık devasa bir switch:

// main.c, satırlar 68-497

void handlePacket (int client_fd, int length, int packet_id, int state) {
  switch (packet_id) {
    case 0x00:  // Duruma göre Handshake / Status / Login
    case 0x01:  // Status ping
    case 0x02:  // Plugin mesajı
    case 0x03:  // Login/konfigürasyon onayı
    case 0x08:  // Sohbet
    case 0x0B:  // İstemci durumu (respawn)
    case 0x11:  // Container tıklama (sandıkları yönetir)
    case 0x19:  // Entity ile etkileşim
    case 0x1D..0x20:  // Hareket paketleri (en büyük durum)
    case 0x28:  // Oyuncu eylemi (kaz/yerleştir)
    // ... 40+ durum
  }
}

Dinamik jump table yok, vtable yok, map yok. Bir switch, statik jump table'a derlenir. Gömülü için mükemmel.

0x1D-0x20 durumu en büyüğü -- konum güncellemelerini, düşüş hasarını, chunk sınırı geçişlerini, mob spawn'ını, chunk üretimini VE açlığı yönetir. Hepsi tek bir büyük fall-through'da.

Sunucu tick'i ve mob yapay zekası

handleServerTick fonksiyonu her 50 ms'de bir (20 TPS) çağrılır. Ana döngü oyuncularla ilgilenirken dünyayı yönetir:

// main.c (basitleştirilmiş)

void handleServerTick (uint32_t delta) {
  // Her mob'u güncelle
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type == 0 || mobs[i].data == 0) continue;  // ölü veya boş

    MobData *mob = &mobs[i];
    int px, pz;
    getNearestPlayer(mob->x, mob->z, &px, &pz);

    if (mob->type == MOB_ZOMBIE) {
      // Düşman: en yakın oyuncuya yürü
      if (px < mob->x) mob->x --;
      else if (px > mob->x) mob->x ++;
      if (pz < mob->z) mob->z --;
      else if (pz > mob->z) mob->z ++;
      // 2 blokta temas hasarı
      if (abs(px - mob->x) <= 2 && abs(pz - mob->z) <= 2)
        damagePlayer(getNearestPlayerId(mob->x, mob->z), 3);
    } else {
      // Pasif: 8 rastgele yön
      uint8_t dir = getMobDir(mob);
      mob->x += dir_lookup[dir][0];
      mob->z += dir_lookup[dir][1];
      // ~40 tick'te bir yön değiştir
      if (mob->data >> 6 < 1) setMobDir(mob, rand() & 7);
      mob->data = (mob->data & 0x3F) | ((mob->data - 0x40) & 0xC0);
    }

    // Mob'ın etrafındaki chunk'ları uyandır
    setChunkGenerated(mob->x / 8, mob->z / 8);
  }
}

Düşman mob'ların yapay zekası, bir koordinat karşılaştırması. Resmen if (px < x) x--. Yol bulma yok, A* yok, engel kaçınma yok. Zombi, X ve Z'yi bağımsız olarak oyuncuya doğru ayarlar -- varsa duvarların içinden geçer.

Temas hasarı saniyede 3 kalp. p2r3 bunu yüksek tutmayı seçmiş çünkü yol bulma olmaması zombileri kitesi kolay hale getiriyor.

Zırh formülü, combat update öncesindeki en basit hal:

// main.c (basitleştirilmiş)

static uint8_t applyArmor (uint8_t damage, uint16_t armor_value) {
  // 1.9 öncesi formül: doğrusal azaltma
  // Her zırh puanı = %4 azaltma, maksimum %80
  uint8_t reduction = (armor_value * 4);
  if (reduction > 80) reduction = 80;
  return damage * (100 - reduction) / 100;
}

Full diamond = %80 azaltma. 3 kalplık bir zombi vuruşu 0.6 kalp olur. p2r3 bu eski formülü seçmiş çünkü 2 işlemde hesaplanıyor -- eşik yok, eğri yok, sadece doğrusal bir yüzde.

Pasif mob'lar: bir arama tablosunda 8 yön, ~40 tick'te bir yön değiştirme. data alanı, geçerli yönü üstteki 2 bitte ve yön değiştirme zamanlayıcısını kalan 6 bitte kodlar.

Mob'ların yeniden doğması

Mob'lar rastgele tick'lerle spawn olmaz. Sunucu tick'i yeni bir chunk sınırıyla karşılaştığında ortaya çıkarlar:

if (player crossed chunk boundary) {
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type != 0) continue;
    spawnMob(&mobs[i], new_chunk_coords, getChunkHash(cx, cz));
    break;
  }
}

Araziyle aynı RNG, aynı chunk tohumu. Bir mob yuvası boşsa, spawn deterministiktir.

Craft: matris yok, if/else var

// crafting.c, satırlar 9-347 (basitleştirilmiş)

void getCraftingOutput (PlayerData *player, uint8_t *count, uint16_t *item) {
  // 0x80 bayrağı kaldırılmışsa, craft buffer'ı bir sandık tarafından kullanılıyor
  if (player->flags & 0x80) { *count = 0; *item = 0; return; }

  // Yuvaları say, ilk item'i bul, kimliği doğrula
  uint8_t filled = 0, first = 10, identical = true;
  for (int i = 0; i < 9; i ++) {
    if (player->craft_items[i]) {
      filled ++;
      if (first == 10) first = i;
      else if (player->craft_items[i] != player->craft_items[first])
        identical = false;
    }
  }

  switch (filled) {
    case 1:  /* tahtalar, külçeler... */
    case 2:  /* çubuklar, makaslar, meşaleler */
    case 3:  /* kürekler, kılıçlar, döşemeler */
    case 4:  /* craft masası, botlar */
    case 5:  /* kazmalar, baltalar, kasklar */
    case 7:  /* pantolonlar, kompostlar */
    case 8:  /* fırın, sandık, zırh */
    case 9:  /* tam bloklar (demir, altın, vb.) */
  }
}

İlk kontrol: 0x80 bayrağı kaldırılmışsa, craft buffer'ı sandık işaretçisi olarak geri dönüştürülür. Craft mümkün değil.

Sonra doldurulan yuvaları sayar, ilk item'i not eder, kimliği doğrular. Sadece bununla, fırını 4 kontrolde eşleştirirsin:

if (count == 8 && first == cobblestone && all_identical && center_empty)
    return furnace;

Karmaşık şekiller için, ilk item'in index'ini kullanır ve göreceli pozisyonu kontrol eder. Tarifler aynı eşleme fonksiyonunu paylaşır -- malzeme sonucu belirler.

Sandıklar: gerçek hack

Herkesin bahsettiği bellek hack'i, gerçek koduyla:

// procedures.c, satırlar 1262-1293

if (target == B_chest) {
  // Blok dizisinde sandık girişini ara
  uint8_t *storage_ptr = NULL;
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block != B_chest) continue;
    if (block_changes[i].x != x || block_changes[i].y != y || block_changes[i].z != z)
      continue;
    storage_ptr = (uint8_t *)(&block_changes[i + 1]);  // sandık bloğunun sonrasını işaret et
    break;
  }
  if (storage_ptr == NULL) return;

  // Terrible memory hack!!
  // POINTER'I oyuncunun craft item dizisine kopyala
  memcpy(player->craft_items, &storage_ptr, sizeof(storage_ptr));
  player->flags |= 0x80;  // craft'ı kilitle

  // İstemciye sandık arayüzünü gönder
  sc_openScreen(player->client_fd, 2, "Chest", 5);
  for (int i = 0; i < 27; i ++) {
    uint16_t item;
    uint8_t count;
    memcpy(&item, storage_ptr + i * 3, 2);
    memcpy(&count, storage_ptr + i * 3 + 2, 1);
    sc_setContainerSlot(player->client_fd, 2, i, count, item);
  }
}

Ve koddaki yorum: // Terrible memory hack!!1!

Aynen öyle. block_changes[] içindeki bir sonraki girişin bellek adresini alıyor, player->craft_items'e kopyalıyor (ki bu bir uint16_t[9], yani 18 byte -- 32 bitlik bir işaretçiyi depolamak için yeterli) ve bu süre boyunca kimsenin craft yapmaya çalışmaması için bayrağı kaldırıyor.

Sandık envanterindeki her tıklamada:

// packets.c, satırlar 620-638

uint8_t *storage_ptr;
memcpy(&storage_ptr, player->craft_items, sizeof(storage_ptr));
// storage_ptr şimdi sandık verilerini işaret ediyor
uint16_t *p_item = (uint16_t *)(storage_ptr + (slot - 41) * 3);
uint8_t *p_count = storage_ptr + (slot - 41) * 3 + 2;

İşaretçiyi craft buffer'ından geri alıyor ve yuvalara bir offset ile erişiyor. Sandık verileri, blok dizisinde yan yana, yuva başına 3 byte (2'si ID, 1'i miktar) olarak depolanıyor.

Açlık: 5 satır deha

// main.c, satırlar 293-305

// Oyuncular hareket ederken ~20/saniye, hareketsizken çok daha az
// hareket paketi gönderir. Açlığı bedavaya simüle etmek için
// bunu aktiviteyle ilişkilendiriyoruz.
if (player->saturation == 0) {
  if (player->hunger > 0) player->hunger--;
  player->saturation = 200;
  sc_setHealth(client_fd, player->health, player->hunger, player->saturation);
} else if (player->flags & 0x08) {  // sprint
  player->saturation -= 1;
}

Resmen bu kadar. 5 satır. Her hareket paketi doygunluğu azaltır. Doygunluk sıfıra ulaştığında, açlık düşer ve doygunluk sıfırlanır. Sprint (0x08 bayrağı) tüketimi ikiye katlar.

Sıfır zamanlayıcı, sıfır ayrılmış bellek, sıfır özel hesaplama. Zaten var olan paketler üzerinde azalan bir sayaç.

Düşüş hasarı

Projenin en basit hasar sistemi:

// Oyuncu yerden ayrıldığında Y'sini sakla
// Yere tekrar değdiğinde çıkar
hasar = son_yerdeki_y - mevcut_y;

Bir çıkarma işlemi.

Blok kazma ve yerleştirme

Bir bloğa tıkladığında, 0x28 (Player Action) paketi switch'e düşer. İşleyici, pozisyondaki bloğu belirlemeli, onu kaldırmalı ve item'i envantere koymalı:

// main.c, case 0x28 (basitleştirilmiş)

void handlePlayerAction (int client_fd, uint8_t action, int x, uint8_t y, int z) {
  switch (action) {
    case START_DESTROY_BLOCK: {
      // Tıklanan pozisyondaki blok türünü belirle
      uint8_t block = getBlockAt(x, y, z);

      if (block == B_chest) {
        openChest(client_fd, x, y, z);
        break;
      }

      // block_changes'e ekle
      addBlockChange(x, z, y, 0);  // 0 = air

      // Oyuncuya item'i ver (client'a güven)
      addItemToPlayer(client_fd, block_to_item(block), 1);

      // İstemciye güncellemeyi gönder
      sc_blockChange(client_fd, x, y, z, 0);
      sc_ackBlockChange(client_fd, x, y, z, 0);
      break;
    }
    case PLACE_BLOCK: {
      // Blok türünü oyuncunun elinden oku
      uint16_t item = getHeldItem(client_fd);
      uint8_t block = item_to_block(item);
      addBlockChange(x, z, y, block);
      removeItemFromPlayer(client_fd, item, 1);
      sc_blockChange(client_fd, x, y, z, block);
      break;
    }
  }
}

getBlockAt, arazi üretimini VE oyuncu değişikliklerini birleştirir:

uint8_t getBlockAt (int x, uint8_t y, int z) {
  // Önce oyuncu değişikliklerini kontrol et
  uint8_t change = getBlockChange(x, y, z);
  if (change != 0xFF) return change;

  // Yoksa, üretilen araziden oku
  return getTerrainBlock(x, y, z);
}

Değişikliklere öncelik, araziye geri dönüş. Sıfır tartışma, sıfır önbellek, sıfır ek yük. Kaputun altındaki getTerrainBlock, getHeightAt + stone/dirt/grass/coal katmanlarıdır.

Anında fırın

En komiği: fırın bir entity olarak mevcut değil. "Pişirme" yuvasına cobblestone ve "yakıt" yuvasına coal koyarsan, sonuç anında belirir. Zamanlayıcı yok, chunk ticking yok. Doğru item'leri koyduğunda boşalan bir envanter yuvası.

ESP32 döngüsü: 4 KB stack'te bir MC sunucusu

// main.c, satırlar 732-779

#ifdef ESP_PLATFORM

void bareiron_main (void *pvParameters) {
  main();
  vTaskDelete(NULL);
}

static void wifi_event_handler (...) {
  if (/* bağlandı */) {
    xTaskCreate(bareiron_main, "bareiron", 4096, NULL, 5, NULL);
  }
}

void app_main () {
  esp_timer_early_init();
  wifi_init();
  // Gerisi event handler tarafından yönetilir
}
#endif

Tüm sunucu, 4096 byte stack ile bir FreeRTOS görevinde çalışır. Hepsi bu. Ana main thread sadece WiFi'i başlatır ve bir bağlantı bekler. Bağlantı kurulduğunda, standart main()'i çağıran bareiron_main'i spawn eder.

ESP32'ye özgü tüm kod, #ifdef ESP_PLATFORM ile korunur. PC'de bunların hepsi standart POSIX koduna derlenir.

Feda edilenler

Bunların hepsinin sığması için, var olmayan vanilla özellikleri var:

• Ağ sıkıştırması yok -- zlib çok pahalı. Sunucu chunk'ları hızlı üretir ama göndermek darboğazdır.
• Rastgele tick yok -- ağaçlar bone meal ile büyür ya da büyümez. Mob'lar chunk sınırlarında spawn olur.
• Item entity'si yok -- kazılan bloklar doğrudan envantere gider. Animasyon tamamen görseldir.
• Hiçbir envanter doğrulaması yok -- client'a güven. 64 elmas? Sorun değil. 1 saniyede kazılmış bir chunk? Sorun değil. Güvendiğin kişilerle kullanılacak.
• Sunucu tarafı ışık yok -- meşaleler her şeyden sonra gönderilir, istemci hesaplar.
• Aşamalı sıvı yok -- anında nihai durum.

Nihai sonuç

Ryzen 5 3600: chunk başına ~0.5 ms. 1$'lık ESP32-C3: chunk başına ~200 ms. Oynanabilir.

3+ oyuncu: kasıyor. Yazarın deyimiyle, 2b2t'nin yoğun saatleriyle karşılaştırılabilir.

Felsefe

p2r3: "Sadece 0.5 Watt tüketen bu küçücük 1$'lık çipin Minecraft kadar gelişmiş bir şeyi çalıştırabilmesi fikrini seviyorum. Science isn't about 'why', it's about 'why not'."

Her satır bir takas:

• Perlin gürültüsü → interpolasyon: daha az güzel, 200 kat hızlı, sıfır bellek
• Craft matrisleri → hardcodlanmış eşleme: iğrenç kod, sıfır byte
• zlib → hiçbir şey: kötü bağlantı = ölüm, ama oynanabilir
• Doğrulama → güven: sıfır güvenlik, sıfır hesaplama

Eksik her özellik, bir başkasının donanım sınırları içinde var olmasını sağlıyor.

Unutulmaması gereken 3 şey:

1. Interpolasyon + RNG -- 4 tohumlanmış nokta, sonsuz arazi, sıfır depolama, chunk'ı yeniden üretmeden sorgulama, 200 ms üretim. Geri kalan her şeyi mümkün kılan deha hamlesi.
2. Her özelliğin bir maliyeti var -- Sıkıştırma yok, rastgele tick yok, doğrulama yok. Bunlar unutkanlık değil, 520 KB'da kalmanın bedeli.
3. En iğrenç hack'ler en zekileridir -- memcpy ile blok dizisindeki sandıklar, hareket paketleriyle açlık, anında fırın. Temiz çözüm çok pahalı olurdu.

Proje ilgini çekiyorsa, her şey GitHub'da GPLv3 lisansıyla. Oldukça pis bir C kodu ve bir kaynak kodu okumaktan bu kadar zevk aldığım nadir olmuştur xD

Introduzione

Far girare un server Minecraft su un microcontrollore da 1 dollaro, sembra uno scherzo.

Mi sono fatto la domanda, e la risposta è sì. Letteralmente.

C'è un progetto che si chiama Bareiron, firmato p2r3, ed è probabilmente uno dei progetti più affascinanti che abbia visto nel mondo Minecraft in questi ultimi anni. Parliamo di un binario che sta in 300 kilobyte, 6800 righe di C, zero dipendenze esterne, niente malloc, niente threading, e gira su una ESP32 da 1 dollaro.

Generazione di terreno infinita. Biomi. Grotte. Craft. Miniere. Mob. Fame. Casse. Tutto ciò che ti aspetti da un server survival.

Su un chip che consuma 0.5 Watt e che ha 160 MHz di clock.

Per dare un ordine di idea: un server Minecraft vanilla ha bisogno di vari giga di RAM. L'ESP32-C3, sono 520 KB di SRAM (400 disponibili dopo il boot). I processori 20 anni fa giravano già in gigahertz: questo si ferma a 160 MHz. Il fattore tra i due in potenza pura, è circa 20 000.

p2r3 non ha scritto un server Minecraft in C, ha reinventato ogni mattone del server perché stesse in questi vincoli. Guardiamo come, aprendo il codice sorgente.

Il cervello del progetto: una generazione di terreno senza memoria

Il problema più grosso quando vuoi fare un server MC embedded, è la generazione del terreno.

In Minecraft vanilla, il mondo è generato con Perlin noise: più strati sovrapposti (ottave), 6 parametri biomici (temperatura, umidità, continentalità, erosione, weirdness, profondità), e tutto un sistema di caching per non dover ricalcolare tutto ogni volta.

Il risultato è magnifico. Ma costa in calcolo, e prende RAM per salvare i chunk generati.

L'approccio di Bareiron è radicalmente diverso. Invece di impilare rumore, usa bilinear interpolation su 4 punti generati da un RNG deterministico.

Sai quando ingrandisci una piccola immagine pixelata e i bordi diventano sfocati? È esattamente quello.

// worldgen.c, righe 117-171 (semplificato)

// interpola i 4 angoli in base alla posizione nel chunk
uint8_t interpolate (uint8_t a, uint8_t b, uint8_t c, uint8_t d, int x, int z) {
  uint16_t top    = a * (CHUNK_SIZE - x) + b * x;
  uint16_t bottom = c * (CHUNK_SIZE - x) + d * x;
  return (top * (CHUNK_SIZE - z) + bottom * z) / (CHUNK_SIZE * CHUNK_SIZE);
}

// altezza del terreno in un punto dalle coordinate mondo
uint8_t getHeightAt (int x, int z) {
  int _x = floor(x / CHUNK_SIZE);  // coordinate chunk
  int _z = floor(z / CHUNK_SIZE);
  int rx = x % CHUNK_SIZE;          // offset dentro il chunk
  int rz = z % CHUNK_SIZE;
  uint32_t hash = getChunkHash(_x, _z);
  uint8_t biome = getChunkBiome(_x, _z);
  // interpolazione tra 4 angoli seminati da hash + bioma
  return getHeightAtFromHash(rx, rz, _x, _z, hash, biome);
}

L'interpolazione bilineare standard: 4 angoli, pesi secondo la posizione, un solo uint8_t in uscita. CHUNK_SIZE è 8, quindi si fa in moltiplicazioni intere, niente float.

p2r3 lo mostra passo passo nel video: prima i 4 angoli del chunk, ognuno con un'altezza seminata dal RNG.

Poi l'interpolazione tra questi 4 punti crea una superficie continua.

E ripetendo il pattern su tutti i chunk adiacenti, si ottiene un terreno che si estende all'infinito.

L'RNG deterministico

La chiave che rende tutto questo possibile, è il seeding. Ogni chunk ha 4 angoli, e ogni angolo ha bisogno di un valore pseudo-casuale unico ma riproducibile.

// worldgen.c, righe 13-22

// hash unico per chunk da coordinate + seed mondo
uint32_t getChunkHash (short x, short z) {
  uint8_t buf[8];
  memcpy(buf, &x, 2);          // 16 bit di coordinata X
  memcpy(buf + 2, &z, 2);      // 16 bit di coordinata Z
  memcpy(buf + 4, &world_seed, 4);  // 32 bit di seed globale
  return splitmix64(*((uint64_t *)buf));  // hash
}

Impacchetta i 16 bit di X, 16 bit di Z, e 32 bit di seed, in un buffer di 8 byte, e passa il tutto in splitmix64. Risultato: un valore deterministico unico per ogni posizione, basato sulla seed del mondo.

Cogli la potenza del meccanismo? Il server non ha bisogno di salvare il terreno. Ricalcola al volo quando il giocatore arriva in una nuova zona, e dà esattamente lo stesso risultato ogni volta.

Lo splitmix64 usato è un prng ultra-rapido pensato per gli hash a 64 bit:

// worldgen.c (semplificato)

// prng veloce per hash a 64 bit
static uint32_t splitmix64 (uint64_t state) {
  state += 0x9E3779B97F4A7C15ull;
  uint64_t z = state;
  z = (z ^ (z >> 30)) * 0xBF58476D1CE4E5B9ull;
  z = (z ^ (z >> 27)) * 0x94D049BB133111EBull;
  return (z ^ (z >> 31)) >> 32;
}

3 operazioni: addizione, xor/shift, moltiplicazione, xor/shift, moltiplicazione, xor/shift. Il tutto sta in operazioni dirette, senza tabella né ciclo. Prende il buffer di 8 byte (X + Z + seed), lo tratta come un intero a 64 bit, e restituisce 32 bit di hash. È deterministico, rapido, e sta in 5 righe.

Perché non è Perlin noise

p2r3 lo dice lui stesso nel video: "più aggiungi cifre del numero casuale, più il terreno diventa regolare, come più lanci di moneta ti avvicinano a 50/50". In pratica, è il numero di bit dell'hash che combina:

// worldgen.c, righe 51-115

// Per un bioma pianure: 4 fattori combinati → terreno regolare
h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// Per pianure innevate: 2 fattori → più accidentato
h = (hash % 5) + ((hash >> 4) % 5);

Ogni bioma sceglie quante estrazioni di bit combina. Più ce ne sono, più la distribuzione si stabilizza: come più lanci di moneta che si avvicinano a 50/50. Meno ce ne sono, più le variazioni locali sono forti.

Con solo 2 fattori, le pianure innevate producono un terreno collinare, quasi montuoso. Picchi e avvallamenti sono frequenti.

Con 4 fattori, le pianure restano piatte e prevedibili. La distribuzione si stabilizza.

Un chunk si genera in 200 ms su ESP32: contro un tempo non misurabile sullo stesso hardware con Perlin noise, tanto costa.

Il dettaglio che spacca: interrogare un blocco senza generare tutto il chunk

Giochi, mini un blocco. Il server deve sapere che item darti. Ingenuamente, servirebbe generare tutto il chunk per questo.

Con la bilinear interpolation, interroghi qualsiasi punto del piano direttamente dalle coordinate. Gli angoli del chunk si ottengono dalla posizione del giocatore, l'interpolazione ti dà l'altezza a qualsiasi offset. Una manciata di operazioni matematiche, niente generazione di chunk.

p2r3: "quello che voglio, è una funzione magica che può dirmi che blocco si trova a una coordinata data, senza accedere alla memoria né calcolare costose mappe di rumore". Esattamente ciò che ha fatto.

Ecco come l'altezza diventa blocchi concreti:

// worldgen.c (semplificato)

// restituisce il tipo di blocco a una coordinata
uint8_t getTerrainBlock (int x, uint8_t y, int z) {
  uint8_t surface = getHeightAt(x, z);

  if (y > surface)             return B_air;
  if (y == surface)            return biome_top[getChunkBiome(x, z)];
  if (y > surface - 4)         return B_dirt;
  if (y > surface - 16)        return B_stone;
  if (y > CAVE_BASE_DEPTH)     return B_deepslate;
                               return B_bedrock;
}

5 condizioni. Uno strato di grass/dirt/stone/deepslate/bedrock. Il blocco di superficie dipende dal bioma via biome_top[]: grass per le pianure, sand per il deserto. Una semplice cascata di if cade nello strato giusto, e questo sostituisce ciclo e switch.

Le grotte, mirror più pigro

// altezza grotta = mirror della superficie in profondità
altitude_grotte = CAVE_BASE_DEPTH - (hauteur_surface - y);

Fa il mirror dell'altezza della superficie sottoterra. Assomiglia alle grandi cavità deepslate. Zero compute, una riga.

I minerali, versione XOR

// un candidato per colonna via XOR di coordinate
candidat = (chunk_x ^ col_x ^ col_z) % 100;
if (candidat < 5 && y < 16) -> diamond

Uno XOR di coordinate garantisce un candidato per colonna. Il tipo dipende solo dall'altitudine. I diamanti sono nascosti sotto il punto più basso delle grotte perché scavare resti utile.

I biomi in tile map

Ogni bioma è un'isola circolare in una griglia, il suo tipo determinato da un pattern calcolato dalla seed. Grigliato, prevedibile, e gratis.

Ogni bioma ha il suo set di parametri codificato in tabelle:

// worldgen.c (semplificato)

// altezze di base per bioma
static const uint8_t biome_base[] = {
  [BIOME_PLAINS]  = 48,   // altezza di base: 48
  [BIOME_DESERT]  = 52,   // leggermente più alto
  [BIOME_FOREST]  = 50,   // in mezzo
  [BIOME_TAIGA]   = 46,   // un po' più basso
  [BIOME_SNOWY]   = 40,   // il più basso
};

// blocco di superficie per bioma
static const uint8_t biome_top[] = {
  [BIOME_PLAINS]  = B_grass,
  [BIOME_DESERT]  = B_sand,
  [BIOME_FOREST]  = B_grass,
  [BIOME_TAIGA]   = B_grass,
  [BIOME_SNOWY]   = B_snow_block,
};

// numero di fattori di rumore per bioma
static const uint8_t biome_factors[] = {
  [BIOME_PLAINS]  = 4,   // 4 estrazioni → molto regolare
  [BIOME_DESERT]  = 3,   // 3 estrazioni → moderato
  [BIOME_FOREST]  = 4,   // 4 estrazioni → regolare, collinare
  [BIOME_TAIGA]   = 3,   // 3 estrazioni → moderato
  [BIOME_SNOWY]   = 2,   // 2 estrazioni → molto accidentato
};

Plains: altezza 48, 4 fattori, poi terreno molto piatto, erba.

// pianure: 4 fattori → variazione di ±4 blocchi max
h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// Risultato: variazione di ±4 blocchi max

Desert: altezza 52, 3 fattori, blocco superficie = sabbia. Mai sotto il livello del mare.

// deserto: 3 fattori → variazione di ±6 blocchi max
h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3);
// Risultato: variazione di ±6 blocchi max, limitato a SEA_LEVEL+1

Forest: altezza 50, 4 fattori come le pianure ma base più alta, poi colline boscose.

Taiga: altezza 46, 3 fattori, poi variazioni moderate, terreno freddo.

Snowy plains: altezza 40, solo 2 fattori, poi il più accidentato.

// pianure innevate: 2 fattori → variazione di ±14 blocchi max
h = (hash % 5) + ((hash >> 4) % 5);
// Risultato: variazione di ±14 blocchi max

Ogni bioma è codificato in 3 tabelle da 5 voci: altezza di base, blocco di superficie, numero di fattori. Quando getHeightAtFromHash riceve il bioma, consulta queste tabelle per regolare il terreno. 15 byte di dati per sostituire tutto il sistema di biomi di Minecraft.

Il rilevatore di bioma usa la seed per determinare che bioma corrisponde a ogni chunk:

// worldgen.c (semplificato)

// pattern di 16 voci per assegnare i biomi
static const uint8_t biome_pattern[] = {
  BIOME_PLAINS, BIOME_FOREST, BIOME_PLAINS, BIOME_DESERT,
  BIOME_FOREST, BIOME_TAIGA,  BIOME_PLAINS, BIOME_SNOWY,
  BIOME_PLAINS, BIOME_FOREST, BIOME_DESERT,  BIOME_PLAINS,
  BIOME_SNOWY,  BIOME_PLAINS, BIOME_FOREST, BIOME_TAIGA,
};

// bioma di un chunk da coordinate + seed
uint8_t getChunkBiome (short cx, short cz) {
  uint32_t h = splitmix64(cx * 31 + cz * 97 + world_seed);
  uint8_t index = h % 16;
  return biome_pattern[index];
}

Un pattern di 16 voci, un indice seminato dalle coordinate del chunk. Dà una griglia ripetitiva ma visivamente coerente. 4 righe di codice per sostituire tutto il sistema di parametri biomici di Minecraft vanilla.

getHeightAtFromHash: l'assemblatore di terreno

La funzione al cuore della generazione combina i 4 angoli seminati per bioma:

// worldgen.c (semplificato)

// combina i 4 angoli seminati e interpola
static uint8_t getHeightAtFromHash (int rx, int rz, short cx, short cz,
                                    uint32_t h, uint8_t biome) {
  // 4 angoli estratti dall'hash, seed diversa per angolo
  uint8_t h1 = biome_base[biome] + (h & 0x0F);
  uint8_t h2 = biome_base[biome] + ((h >> 4) & 0x0F);
  uint8_t h3 = biome_base[biome] + ((h >> 8) & 0x0F);
  uint8_t h4 = biome_base[biome] + ((h >> 12) & 0x0F);

  // Vincolo bioma: deserto mai sott'acqua
  if (biome == BIOME_DESERT) {
    h1 = max(h1, SEA_LEVEL + 1);
    h2 = max(h2, SEA_LEVEL + 1);
    h3 = max(h3, SEA_LEVEL + 1);
    h4 = max(h4, SEA_LEVEL + 1);
  }

  // Interpolazione dai 4 angoli
  return interpolate(h1, h2, h3, h4, rx, rz);
}

Ogni bioma ha una biome_base che sposta l'altezza di riferimento, e i 4 angoli sono estratti dall'hash con scostamenti diversi. Il deserto forza il minimo sopra il livello del mare: una riga di vincolo che evita l'acqua senza calcolo biomico extra.

Alberi e cactus: piazzamento probabilistico

La generazione di superficie usa lo stesso hash di chunk per decidere dove piantare:

// worldgen.c (semplificato)

// piazza alberi o cactus in base a hash e bioma
static void genFoliage (uint8_t *chunk_data, short cx, short cz,
                        uint32_t hash, uint8_t biome) {
  if (biome == BIOME_DESERT) {
    // Cactus: un candidato per chunk, hash decide la posizione
    int tx = (hash >> 8) & 7;
    int tz = (hash >> 12) & 7;
    int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
    if (chunk_data[ty * 64 + tz * 8 + tx] == B_sand)
      placeCactus(chunk_data, tx, ty + 1, tz);
  } else {
    // Alberi: hash decide se metterne e dove
    int tree_count = (hash & 3);  // 0-3 alberi per chunk
    for (int i = 0; i < tree_count; i ++) {
      int tx = ((hash >> (4 + i * 4)) & 7);
      int tz = ((hash >> (6 + i * 4)) & 7);
      int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
      placeTree(chunk_data, tx, ty + 1, tz);
    }
  }
}

0-3 alberi per chunk per i biomi verdi, 1 cactus massimo per il deserto. L'hash del chunk è l'unica fonte di entropia: un & 7 per la posizione nel chunk, un & 3 per il contatore. Tutto è deterministico, niente è salvato.

generateChunk: assemblare tutto

La funzione che mette tutto insieme per produrre un chunk completo di 8×8×256 blocchi:

// worldgen.c (semplificato)

// genera un chunk completo colonna per colonna
void generateChunk (uint8_t *chunk, short cx, short cz) {
  uint32_t hash = getChunkHash(cx, cz);
  uint8_t biome = getChunkBiome(cx, cz);

  // Per ogni colonna del chunk (8×8 = 64)
  for (int x = 0; x < 8; x ++) {
    for (int z = 0; z < 8; z ++) {
      // Coordinate mondo assolute
      int wx = cx * 8 + x;
      int wz = cz * 8 + z;

      // Altezza della colonna
      uint8_t height = getHeightAt(wx, wz);

      // Riempi la colonna dal basso in alto
      for (int y = 0; y < height; y ++) {
        uint8_t block = getTerrainBlock(wx, y, wz);
        chunk[y * 64 + z * 8 + x] = block;
      }
    }
  }

  // Aggiungi gli elementi di superficie (alberi, cactus)
  genFoliage(chunk, cx, cz, hash, biome);
}

È tutto. 3 cicli annidati: per ogni colonna, trova l'altezza, riempi i blocchi, passa alla successiva. L'uscita è un uint8_t[16384] (8 × 8 × 256) che rappresenta il chunk completo. Il chunk è generato poi inviato diretto al client, senza passare da caching, lazy loading o compressione.

Lo storage: array statici ovunque

L'architettura memoria di Bareiron, è C embedded in tutto il suo splendore: solo tabelle globali di taglia fissa, né malloc, né hash map, né liste concatenate.

I cambiamenti di blocchi

// globals.h, righe 191-196

// un cambio di blocco fatto dal giocatore
typedef struct {
  short x;      // 2 byte: limite a 32 000 blocchi orizzontale
  short z;      // 2 byte
  uint8_t y;    // 1 byte: limite a 256 blocchi verticale
  uint8_t block; // 1 byte: limite a 256 tipi di blocchi
} BlockChange;

20 000 voci, cioè circa 25 000 cambiamenti: l'equivalente di un chunk e mezzo interamente scavato. Il campo block a 0xFF segna una voce libera. La ricerca è una scansione lineare:

// procedures.c

// cerca un cambio giocatore a una posizione
uint8_t getBlockChange (short x, uint8_t y, short z) {
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block == 0xFF) continue;
    if (block_changes[i].x == x && block_changes[i].y == y && block_changes[i].z == z)
      return block_changes[i].block;
    #ifdef ALLOW_CHESTS
      if (block_changes[i].block == B_chest) i += 14;  // salta dati cassa
    #endif
  }
  return 0xFF;
}

Aggiungere un cambiamento è diretto come la ricerca:

// accoda un cambio di blocco
static uint8_t changes_count = 0;

void addBlockChange (short x, short z, uint8_t y, uint8_t block) {
  if (changes_count >= MAX_CHANGES) return;
  block_changes[changes_count].x = x;
  block_changes[changes_count].z = z;
  block_changes[changes_count].y = y;
  block_changes[changes_count].block = block;
  changes_count ++;
}

Un contatore, un indice, una scrittura. La tabella si limita ad accodare: nessun ordinamento, nessuna compattazione, nessuna gestione memoria. Quando la tabella è piena, i nuovi cambiamenti sono ignorati: il terreno torna al suo stato generato.

Il commento dell'autore sul limite a 256 blocchi: "non conto di implementare le scale in rame leggermente patinato cerato tanto presto."

I mob: 8 byte per testa di pipe

// globals.h, righe 240-251 (pragma pack(push, 1) per eliminare il padding)

// stato di un mob in 8 byte
typedef struct {
  uint8_t type;   // 25=chicken, 28=cow, 95=pig, 106=sheep, 145=zombie
  short x;
  uint8_t y;      // se health=0, Y diventa un timer prima della rimozione
  short z;
  uint8_t data;   // bit 0-4: health, bit 5: sheep sheared, bit 6-7: panic timer
} MobData;

8 byte. 16 slot max. Allineamento e padding vanno a farsi friggere. Il byte data è un bitfield casalingo: 5 bit di vita, 1 bit di tosatura, 2 bit di timer di panico. E quando un mob muore, il campo Y diventa un timer prima della rimozione. Riuso di memoria a livello di bit.

I giocatori: impacchettati stretti

I dati giocatori usano #pragma pack(push, 1) anche loro: coordinate in short + uint8_t, inventari in tabelle fisse di uint16_t + uint8_t, e un campo flags che codifica sia il cooldown di attacco, lo stato di spawn, sneak, sprint, eat, load, movement cooldown, e il lock di craft. Tutto in singoli bit.

Il ciclo principale: while(true) e non-bloccante

Il server intero gira su un ciclo, un thread, zero event library.

// main.c, righe 594-720

// ciclo principale: accetta client, ticka, elabora un pacchetto
while (true) {
  task_yield();  // lascia respirare il watchdog su ESP32

  // Accetta una nuova connessione (non bloccante)
  for (int i = 0; i < MAX_PLAYERS; i ++) {
    if (clients[i] != -1) continue;
    clients[i] = accept(server_fd, ...);
    if (clients[i] != -1) client_count ++;
    break;
  }

  // Tick server se il tempo è scaduto
  if (get_program_time() - last_tick_time > TIME_BETWEEN_TICKS) {
    handleServerTick(time_since_last_tick);
    last_tick_time = get_program_time();
  }

  // Round-robin: un client, un pacchetto per iterazione
  client_index = (client_index + 1) % MAX_PLAYERS;
  if (clients[client_index] == -1) continue;

  // Leggi l'intestazione del pacchetto: length + ID
  recv(client_fd, &recv_buffer, 2, MSG_PEEK);
  int length = readVarInt(client_fd);
  int packet_id = readVarInt(client_fd);
  handlePacket(client_fd, length - sizeVarInt(packet_id), packet_id, state);
}

Un solo client è trattato per iterazione del ciclo, e un solo pacchetto è letto alla volta. Il task_yield() all'inizio del ciclo lascia il task idle di FreeRTOS respirare su ESP32: senza, il timer watchdog ti resetta il chip.

Il dispatch dei pacchetti, è uno switch mostruoso di 400 righe:

// main.c, righe 68-497

// smista un pacchetto in base al suo ID
void handlePacket (int client_fd, int length, int packet_id, int state) {
  switch (packet_id) {
    case 0x00:  // Handshake / Status / Login secondo lo stato
    case 0x01:  // Status ping
    case 0x02:  // Plugin message
    case 0x03:  // Login/configuration acknowledgment
    case 0x08:  // Chat
    case 0x0B:  // Client status (respawn)
    case 0x11:  // Click container (gestisce le casse)
    case 0x19:  // Interact entity
    case 0x1D..0x20:  // Pacchetti movimento (il caso più grosso)
    case 0x28:  // Player action (dig/place)
    // ... oltre 40 casi
  }
}

Uno switch compila in jump table statica, e questo sostituisce jump table dinamica, vtable e map. Perfetto per l'embedded.

Il caso 0x1D-0x20 è il più grosso: gestisce gli aggiornamenti di posizione, i danni da caduta, gli attraversamenti di frontiere di chunk, lo spawn di mob, la generazione di chunk, E la fame. Tutto in un solo grosso fall-through.

Il tick server e l'IA dei mob

La funzione handleServerTick è chiamata ogni 50 ms (20 TPS). Gestisce il mondo mentre il ciclo principale si occupa dei giocatori:

// main.c (semplificato)

// aggiorna i mob a ogni tick server
void handleServerTick (uint32_t delta) {
  // Aggiorna ogni mob
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type == 0 || mobs[i].data == 0) continue;  // morto o vuoto

    MobData *mob = &mobs[i];
    int px, pz;
    getNearestPlayer(mob->x, mob->z, &px, &pz);

    if (mob->type == MOB_ZOMBIE) {
      // Ostile: cammina verso il giocatore più vicino
      if (px < mob->x) mob->x --;
      else if (px > mob->x) mob->x ++;
      if (pz < mob->z) mob->z --;
      else if (pz > mob->z) mob->z ++;
      // Danni da contatto a 2 blocchi
      if (abs(px - mob->x) <= 2 && abs(pz - mob->z) <= 2)
        damagePlayer(getNearestPlayerId(mob->x, mob->z), 3);
    } else {
      // Passivo: 8 direzioni casuali
      uint8_t dir = getMobDir(mob);
      mob->x += dir_lookup[dir][0];
      mob->z += dir_lookup[dir][1];
      // Cambio di direzione ogni ~40 tick
      if (mob->data >> 6 < 1) setMobDir(mob, rand() & 7);
      mob->data = (mob->data & 0x3F) | ((mob->data - 0x40) & 0xC0);
    }

    // Risveglia i chunk intorno al mob
    setChunkGenerated(mob->x / 8, mob->z / 8);
  }
}

L'IA dei mob ostili, è un confronto di coordinate. Letteralmente if (px < x) x--. Lo zombie ignora pathfinding, A* e obstacle avoidance: regola X e Z in modo indipendente verso il giocatore: attraversa i muri se ce ne sono.

I danni da contatto sono a 3 cuori/sec. p2r3 l'ha voluto alto perché l'assenza di pathfinding rende gli zombie facili da kitare.

La formula di armatura è quella di prima del combat update: la più semplice possibile:

// main.c (semplificato)

// riduzione danno lineare pre-1.9
static uint8_t applyArmor (uint8_t damage, uint16_t armor_value) {
  // Formula pre-1.9: riduzione lineare
  // Ogni punto di armatura = 4% di riduzione, max 80%
  uint8_t reduction = (armor_value * 4);
  if (reduction > 80) reduction = 80;
  return damage * (100 - reduction) / 100;
}

Full diamond = 80% di riduzione. Un colpo di zombie da 3 cuori diventa 0.6 cuori. p2r3 ha scelto questa vecchia formula perché si calcola in 2 operazioni: niente soglie, niente curve, solo una percentuale lineare.

I mob passivi: 8 direzioni in una lookup table, cambio di rotta ogni ~40 tick. Il campo data codifica la direzione in corso nei 2 bit di peso forte, e il timer di cambio direzione nei 6 bit restanti.

Il respawn dei mob

I mob non spawnano con random tick. Appaiono quando il tick server incontra una nuova frontiera di chunk:

// spawn deterministico alle frontiere di chunk
if (player crossed chunk boundary) {
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type != 0) continue;
    spawnMob(&mobs[i], new_chunk_coords, getChunkHash(cx, cz));
    break;
  }
}

Stesso RNG del terreno, stessa seed di chunk. Se uno slot mob è libero, lo spawn è deterministico.

Il craft: niente matrici, if/else

// crafting.c, righe 9-347 (semplificato)

// calcola il risultato del craft dal contenuto della griglia
void getCraftingOutput (PlayerData *player, uint8_t *count, uint16_t *item) {
  // Se il flag 0x80 è alzato, il buffer di craft è usato da una cassa
  if (player->flags & 0x80) { *count = 0; *item = 0; return; }

  // Conta gli slot, trova il primo item, verifica l'identità
  uint8_t filled = 0, first = 10, identical = true;
  for (int i = 0; i < 9; i ++) {
    if (player->craft_items[i]) {
      filled ++;
      if (first == 10) first = i;
      else if (player->craft_items[i] != player->craft_items[first])
        identical = false;
    }
  }

  switch (filled) {
    case 1:  /* assi, lingotti... */
    case 2:  /* bastoni, cesoie, torce */
    case 3:  /* pale, spade, lastre */
    case 4:  /* tavolo di craft, stivali */
    case 5:  /* picconi, asce, elmi */
    case 7:  /* gambali, compostatori */
    case 8:  /* forno, cassa, corazza */
    case 9:  /* blocchi completi (ferro, oro, ecc.) */
  }
}

Il primo check: se il flag 0x80 è alzato, il buffer di craft è riciclato in puntatore di cassa. Il craft resta bloccato.

Poi, conta gli slot riempiti, nota il primo item, verifica l'identità. Con solo questo, becchi il forno in 4 check:

// forno: 8 di ciottolo identici col centro vuoto
if (count == 8 && first == cobblestone && all_identical && center_empty)
    return furnace;

Per le forme complesse, usa l'indice del primo item e controlla la posizione relativa. Le ricette condividono una stessa funzione di matching: il materiale determina il risultato.

Le casse: l'hack in vero

L'hack memoria di cui parlano tutti, in vero codice:

// procedures.c, righe 1262-1293

// apri una cassa: punta ai suoi dati nel buffer di craft
if (target == B_chest) {
  // Cerca la voce della cassa nella tabella dei blocchi
  uint8_t *storage_ptr = NULL;
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block != B_chest) continue;
    if (block_changes[i].x != x || block_changes[i].y != y || block_changes[i].z != z)
      continue;
    storage_ptr = (uint8_t *)(&block_changes[i + 1]);  // punta dopo il blocco cassa
    break;
  }
  if (storage_ptr == NULL) return;

  // Terrible memory hack!!
  // Copia il PUNTATORE nella tabella di item di craft del giocatore
  memcpy(player->craft_items, &storage_ptr, sizeof(storage_ptr));
  player->flags |= 0x80;  // blocca il craft

  // Invia l'interfaccia cassa al client
  sc_openScreen(player->client_fd, 2, "Chest", 5);
  for (int i = 0; i < 27; i ++) {
    uint16_t item;
    uint8_t count;
    memcpy(&item, storage_ptr + i * 3, 2);
    memcpy(&count, storage_ptr + i * 3 + 2, 1);
    sc_setContainerSlot(player->client_fd, 2, i, count, item);
  }
}

E il commento nel codice: // Terrible memory hack!!1!

È esattamente quello. Prende l'indirizzo memoria della voce successiva in block_changes[], lo copia in player->craft_items (che è un uint16_t[9], quindi 18 byte: abbastanza per salvare un puntatore a 32 bit), e alza il flag perché nessuno provi a craftare nel frattempo.

Su ogni clic nell'inventario della cassa:

// packets.c, righe 620-638

// recupera il puntatore cassa dal buffer di craft
uint8_t *storage_ptr;
memcpy(&storage_ptr, player->craft_items, sizeof(storage_ptr));
// storage_ptr punta ormai ai dati della cassa
uint16_t *p_item = (uint16_t *)(storage_ptr + (slot - 41) * 3);
uint8_t *p_count = storage_ptr + (slot - 41) * 3 + 2;

Recupera il puntatore dal buffer di craft, e accede agli slot con un offset. I dati cassa sono salvati a colpi di 3 byte per slot (2 per l'ID, 1 per la quantità), incollati gli uni agli altri nella tabella di blocchi.

La fame: 5 righe di genio

// main.c, righe 293-305

// I giocatori inviano pacchetti di movimento a ~20/sec quando si
// muovono, molto meno quando sono immobili. Lo correliamo
// con l'attività per simulare la fame gratis.
if (player->saturation == 0) {
  if (player->hunger > 0) player->hunger--;
  player->saturation = 200;
  sc_setHealth(client_fd, player->health, player->hunger, player->saturation);
} else if (player->flags & 0x08) {  // sprinting
  player->saturation -= 1;
}
}

È letteralmente quello. 5 righe. Ogni pacchetto di movimento decrementa la saturazione. Quando la saturazione arriva a zero, la fame cala e si resetta la saturazione. Lo sprint (flag 0x08) raddoppia il consumo.

Zero timer, zero memoria allocata, zero compute dedicato. Un contatore che si decrementa su pacchetti che esistono già.

I danni da caduta

Il sistema di danni più semplice del progetto:

// Quando il giocatore lascia il suolo, salviamo il suo Y
// Quando ritocca il suolo, sottraiamo
degats = dernier_y_au_sol - y_actuel;

Una sottrazione.

Minare e piazzare blocchi

Quando clicchi su un blocco, il pacchetto 0x28 (Player Action) atterra nello switch. L'handler deve determinare che blocco si trova alla posizione, rimuoverlo, e mettere l'item nell'inventario:

// main.c, case 0x28 (semplificato)

// gestisce distruzione e piazzamento blocchi
void handlePlayerAction (int client_fd, uint8_t action, int x, uint8_t y, int z) {
  switch (action) {
    case START_DESTROY_BLOCK: {
      // Determina il tipo di blocco alla posizione cliccata
      uint8_t block = getBlockAt(x, y, z);

      if (block == B_chest) {
        openChest(client_fd, x, y, z);
        break;
      }

      // Aggiungi ai block_changes
      addBlockChange(x, z, y, 0);  // 0 = aria

      // Dai l'item al giocatore (fidati del client)
      addItemToPlayer(client_fd, block_to_item(block), 1);

      // Invia l'aggiornamento al client
      sc_blockChange(client_fd, x, y, z, 0);
      sc_ackBlockChange(client_fd, x, y, z, 0);
      break;
    }
    case PLACE_BLOCK: {
      // Leggi il tipo di blocco dalla mano del giocatore
      uint16_t item = getHeldItem(client_fd);
      uint8_t block = item_to_block(item);
      addBlockChange(x, z, y, block);
      removeItemFromPlayer(client_fd, item, 1);
      sc_blockChange(client_fd, x, y, z, block);
      break;
    }
  }
}

getBlockAt combina la generazione di terreno E i cambiamenti giocatori:

// priorità ai cambi giocatori, fallback sul terreno
uint8_t getBlockAt (int x, uint8_t y, int z) {
  // Prima verifica i cambiamenti giocatori
  uint8_t change = getBlockChange(x, y, z);
  if (change != 0xFF) return change;

  // Altrimenti, leggi dal terreno generato
  return getTerrainBlock(x, y, z);
}

Priorità ai cambiamenti, fallback sul terreno. Zero dibattito, zero cache, zero overhead. Il getTerrainBlock sotto il cofano, è getHeightAt + gli strati di stone/dirt/grass/coal.

Il forno istantaneo

Il più divertente: il forno non esiste come entità. Se metti del ciottolo nella casella "cottura" e del carbone in "fuel", il risultato appare subito, senza timer né chunk ticking: è solo uno slot di inventario che si svuota quando metti gli item giusti.

Il ciclo ESP32: un server MC in 4 KB di stack

// main.c, righe 732-779

#ifdef ESP_PLATFORM

// task FreeRTOS che lancia il server
void bareiron_main (void *pvParameters) {
  main();
  vTaskDelete(NULL);
}

// al WiFi connesso, crea la task server
static void wifi_event_handler (...) {
  if (/* connesso */) {
    xTaskCreate(bareiron_main, "bareiron", 4096, NULL, 5, NULL);
  }
}

// init timer + WiFi, il resto lo gestisce l'event handler
void app_main () {
  esp_timer_early_init();
  wifi_init();
  // Il resto è gestito dall'event handler
}
#endif

Il server intero gira in un task FreeRTOS con 4096 byte di stack. È tutto. Il thread main principale fa solo inizializzare il WiFi e aspettare una connessione. Una volta connesso, crea bareiron_main che chiama il main() standard.

Tutto il codice specifico ESP32 è protetto da #ifdef ESP_PLATFORM. Su PC, tutto questo compila in codice POSIX standard.

Cosa è stato sacrificato

Perché tutto questo stia, ci sono feature vanilla che non esistono:

• Zero compressione rete: zlib troppo costoso. Il server genera chunk in fretta, ma inviarli è il bottleneck.
• Zero random tick: gli alberi crescono con bone meal o no. I mob spawnano alle frontiere di chunk.
• Zero entità item: i blocchi minati vanno diretto nell'inventario. L'animazione è puramente visiva.
• Nessuna verifica di inventario: fidati del client. 64 diamanti? OK. Un chunk minato in 1 sec? OK. Da usare tra gente di fiducia.
• Zero luce server: le torce sono inviate dopo tutto il resto, il client calcola.
• Zero fluidi progressivi: stato finale istantaneo.

Il risultato finale

Ryzen 5 3600: circa 0.5 ms per chunk. ESP32-C3 da 1$: circa 200 ms per chunk. Giocabile.

3+ giocatori: arranca. Paragonabile a 2b2t nelle ore di punta, dice l'autore.

La filosofia

p2r3: "Mi piace solo l'idea che questo piccolissimo chip da 1 dollaro che consuma 0.5 Watt possa far girare qualcosa di avanzato come Minecraft. Science isn't about 'why', it's about 'why not'."

Ogni riga è un tradeoff:

• Perlin noise, poi interpolazione: meno bello, 200x più rapido, zero memoria
• Matrici di craft, poi matching hardcodato: codice schifoso, zero byte
• zlib, poi niente: connessione scarsa = morte, ma giocabile
• Validazione, poi fiducia: zero sicurezza, zero compute

Ogni feature assente permette a un'altra di esistere nei limiti dell'hardware.

I 3 punti da ricordare:

1. Interpolazione + RNG: 4 punti seminati, terreno infinito, zero storage, query senza rigenerare il chunk, 200 ms di generazione. È la mossa geniale che rende tutto il resto possibile.
2. Ogni feature ha un costo: l'assenza di compressione, random tick e validazione è scelta voluta: è ciò che permette di stare in 520 KB.
3. Gli hack schifosi sono i più intelligenti: casse nella tabella di blocchi via memcpy, fame via pacchetti di movimento, forno istantaneo. La soluzione pulita sarebbe costata troppo.

Se il progetto ti interessa, tutto è su GitHub in GPLv3. È C bello sporco, e raramente ho preso tanto piacere a leggere un codice sorgente.

Einleitung

Einen Minecraft-Server auf einem 1-Dollar-Mikrocontroller laufen lassen klingt wie ein Witz.

Ich stellte mir die Frage, und die Antwort ist ja. Buchstäblich.

Es gibt ein Projekt namens Bareiron, signiert p2r3, und es ist wahrscheinlich eines der faszinierendsten Projekte, die ich in den letzten Jahren in der Minecraft-Welt gesehen habe. Man redet von einem Binary, das in 300 Kilobyte passt, 6800 Zeilen C, null externe Abhängigkeiten, kein malloc, kein Threading, und es läuft auf einem 1-Dollar-ESP32.

Unendliche Terraingenerierung. Biome. Höhlen. Craften. Minen. Mobs. Hunger. Truhen. Alles, was du von einem Survival-Server erwartest.

Auf einem Chip, der 0.5 Watt verbraucht und 160 MHz Clock hat.

Zur Größenordnung: Ein Vanilla-Minecraft-Server braucht mehrere GB RAM. Der ESP32-C3 hat 520 KB SRAM (400 verfügbar nach Boot). Prozessoren vor 20 Jahren liefen schon im Gigahertz, dieser cappt bei 160 MHz. Der Faktor zwischen beiden in purer Power ist etwa 20.000.

p2r3 schrieb keinen Minecraft-Server in C, er erfand jeden Baustein des Servers neu, damit er in diese Constraints passt. Wir schauen wie, indem wir den Sourcecode öffnen.

Das Gehirn des Projekts: speicherlose Terraingenerierung

Das größte Problem, wenn du einen eingebetteten MC-Server machen willst, ist Terraingenerierung.

In Vanilla-Minecraft wird die Welt mit Perlin Noise generiert: Mehrere überlagerte Schichten (Oktaven), 6 biomische Parameter (Temperatur, Feuchte, Kontinentalität, Erosion, Weirdness, Tiefe) und ein ganzes Caching-System, um nicht alles jedes Mal neu berechnen zu müssen.

Das Ergebnis ist wunderschön. Aber es ist rechenintensiv und braucht RAM, um generierte Chunks zu speichern.

Bareirons Ansatz ist radikal anders. Statt Noise zu stapeln, nutzt er bilineare Interpolation auf 4 von einem deterministischen RNG generierten Punkten.

Du weißt, wenn du ein kleines verpixeltes Bild vergrößerst und die Kanten verschwimmen? Genau das.

// worldgen.c, Zeilen 117-171 (vereinfacht)

uint8_t interpolate (uint8_t a, uint8_t b, uint8_t c, uint8_t d, int x, int z) {
  uint16_t top    = a * (CHUNK_SIZE - x) + b * x;
  uint16_t bottom = c * (CHUNK_SIZE - x) + d * x;
  return (top * (CHUNK_SIZE - z) + bottom * z) / (CHUNK_SIZE * CHUNK_SIZE);
}

uint8_t getHeightAt (int x, int z) {
  int _x = floor(x / CHUNK_SIZE);  // Chunk-Koordinaten
  int _z = floor(z / CHUNK_SIZE);
  int rx = x % CHUNK_SIZE;          // Offset im Chunk
  int rz = z % CHUNK_SIZE;
  uint32_t hash = getChunkHash(_x, _z);
  uint8_t biome = getChunkBiome(_x, _z);
  // Interpolation zwischen 4 Ecken geseedet von Hash + Biom
  return getHeightAtFromHash(rx, rz, _x, _z, hash, biome);
}

Standard-bilineare Interpolation: 4 Ecken, Gewichte nach Position, ein einziges uint8_t Output. CHUNK_SIZE ist 8, also passiert das in Integer-Multiplikationen, kein Float.

p2r3 zeigt es Schritt für Schritt im Video: Erst die 4 Chunk-Ecken, jede mit einer vom RNG geseedeten Höhe.

Dann erzeugt die Interpolation zwischen diesen 4 Punkten eine kontinuierliche Oberfläche.

Und durch Wiederholen des Patterns auf allen angrenzenden Chunks erhält man ein Terrain, das sich ins Unendliche erstreckt.

Der deterministische RNG

Der Schlüssel, der das alles möglich macht, ist das Seeding. Jeder Chunk hat 4 Ecken, und jede Ecke braucht einen einzigartigen aber reproduzierbaren Pseudozufallswert.

// worldgen.c, Zeilen 13-22

uint32_t getChunkHash (short x, short z) {
  uint8_t buf[8];
  memcpy(buf, &x, 2);          // 16 Bit X-Koordinate
  memcpy(buf + 2, &z, 2);      // 16 Bit Z-Koordinate
  memcpy(buf + 4, &world_seed, 4);  // 32 Bit globale Seed
  return splitmix64(*((uint64_t *)buf));  // Hash
}

Er packt 16 Bit X, 16 Bit Z und 32 Bit Seed in einen 8-Byte-Buffer und schickt alles durch splitmix64. Ergebnis: Ein deterministischer einzigartiger Wert für jede Position, basierend auf der Welt-Seed.

Du kapierst die Power des Mechanismus? Der Server muss das Terrain nicht speichern. Er berechnet neu on the fly, wenn der Spieler in eine neue Zone kommt, und das gibt jedes Mal exakt dasselbe Ergebnis.

Das genutzte splitmix64 ist ein ultraschneller PRNG designed für 64-bit-Hashes:

// worldgen.c (vereinfacht)

static uint32_t splitmix64 (uint64_t state) {
  state += 0x9E3779B97F4A7C15ull;
  uint64_t z = state;
  z = (z ^ (z >> 30)) * 0xBF58476D1CE4E5B9ull;
  z = (z ^ (z >> 27)) * 0x94D049BB133111EBull;
  return (z ^ (z >> 31)) >> 32;
}

3 Operationen: Addition, Xor/Shift, Multiplikation, Xor/Shift, Multiplikation, Xor/Shift. Alles passt in direkte Operationen, ohne Tabelle oder Schleife. Es nimmt den 8-Byte-Buffer (X + Z + Seed), behandelt ihn wie eine 64-bit-Ganzzahl und gibt 32 Bit Hash zurück. Deterministisch, schnell, und passt in 5 Zeilen.

Warum das kein Perlin Noise ist

p2r3 sagt es selbst im Video: "Je mehr Digits der Zufallszahl du hinzufügst, desto regelmäßiger wird das Terrain, wie mehr Münzwürfe dich näher an 50/50 bringen". In der Praxis ist es die Zahl der Hash-Bits, die er kombiniert:

// worldgen.c, Zeilen 51-115

// Für Plains-Biom : 4 kombinierte Faktoren → regelmäßiges Terrain
h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// Für Snowy Plains : 2 Faktoren → hügeliger
h = (hash % 5) + ((hash >> 4) % 5);

Jedes Biom wählt, wie viele Bit-Extraktionen es kombiniert. Je mehr, desto mehr stabilisiert sich die Verteilung, wie mehr Münzwürfe, die sich 50/50 annähern. Je weniger, desto stärker die lokalen Variationen.

Mit nur 2 Faktoren produziert Snowy Plains hügeliges, fast bergiges Terrain. Peaks und Täler sind häufig.

Mit 4 Faktoren bleiben Plains flach und vorhersehbar. Die Verteilung stabilisiert sich.

Ein Chunk generiert sich in 200 ms auf ESP32, gegen unmessbare Zeit auf selber Hardware mit Perlin Noise, so teuer ist es.

Das Killer-Detail: einen Block abfragen ohne den ganzen Chunk zu generieren

Du spielst, du minst einen Block. Der Server muss wissen, welches Item er dir geben muss. Naiv müsste er dafür den ganzen Chunk generieren.

Mit bilinearer Interpolation fragst du jeden Punkt der Ebene direkt aus Koordinaten ab. Die Chunk-Ecken bekommt man aus der Spielerposition, die Interpolation gibt die Höhe bei jedem Offset. Eine Handvoll Matheoperationen, keine Chunk-Generierung.

p2r3: "Was ich will, ist eine magische Funktion, die mir sagen kann, welcher Block an einer gegebenen Koordinate ist, ohne auf Speicher zuzugreifen oder teure Noise-Maps zu berechnen". Exakt was er machte.

So wird Höhe zu konkreten Blöcken:

// worldgen.c (vereinfacht)

uint8_t getTerrainBlock (int x, uint8_t y, int z) {
  uint8_t surface = getHeightAt(x, z);

  if (y > surface)             return B_air;
  if (y == surface)            return biome_top[getChunkBiome(x, z)];
  if (y > surface - 4)         return B_dirt;
  if (y > surface - 16)        return B_stone;
  if (y > CAVE_BASE_DEPTH)     return B_deepslate;
                               return B_bedrock;
}

5 Bedingungen. Eine Grass/Dirt/Stone/Deepslate/Bedrock-Schicht. Der Oberflächenblock hängt via biome_top[] vom Biom ab, Grass für Plains, Sand für Wüste. Eine simple If-Kaskade fällt in die richtige Schicht, was Schleife und Switch ersetzt.

Die Höhlen, faulster Mirror

Höhlenhöhe = CAVE_BASE_DEPTH - (Oberflächenhöhe - y);

Er mirrort die Oberflächenhöhe unter Erde. Sieht aus wie große Deepslate-Kavernen. Null Compute, eine Zeile.

Die Erze, XOR-Version

Kandidat = (chunk_x ^ col_x ^ col_z) % 100;
if (Kandidat < 5 && y < 16) -> Diamant

Ein Koordinaten-XOR garantiert einen Kandidaten pro Spalte. Der Typ hängt nur von der Höhe ab. Diamanten verstecken sich unter dem tiefsten Punkt der Höhlen, damit Graben nützlich bleibt.

Die Biome als Tile Map

Jedes Biom ist eine kreisförmige Insel in einem Grid, sein Typ bestimmt von einem aus der Seed berechneten Pattern. Gegridet, vorhersehbar und gratis.

Jedes Biom hat seinen eigenen Parametersatz kodiert in Tabellen:

// worldgen.c (vereinfacht)

static const uint8_t biome_base[] = {
  [BIOME_PLAINS]  = 48,   // Basishöhe : 48
  [BIOME_DESERT]  = 52,   // etwas höher
  [BIOME_FOREST]  = 50,   // dazwischen
  [BIOME_TAIGA]   = 46,   // etwas tiefer
  [BIOME_SNOWY]   = 40,   // am tiefsten
};

static const uint8_t biome_top[] = {
  [BIOME_PLAINS]  = B_grass,
  [BIOME_DESERT]  = B_sand,
  [BIOME_FOREST]  = B_grass,
  [BIOME_TAIGA]   = B_grass,
  [BIOME_SNOWY]   = B_snow_block,
};

static const uint8_t biome_factors[] = {
  [BIOME_PLAINS]  = 4,   // 4 Extraktionen → sehr regelmäßig
  [BIOME_DESERT]  = 3,   // 3 Extraktionen → moderat
  [BIOME_FOREST]  = 4,   // 4 Extraktionen → regelmäßig, hügelig
  [BIOME_TAIGA]   = 3,   // 3 Extraktionen → moderat
  [BIOME_SNOWY]   = 2,   // 2 Extraktionen → sehr hügelig
};

Plains: Höhe 48, 4 Faktoren → sehr flaches Terrain, Gras.

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3) + ((hash >> 12) % 3);
// Ergebnis : Variation max ±4 Blöcke

Desert: Höhe 52, 3 Faktoren, Oberflächenblock = Sand. Nie unter Meeresspiegel.

h = (hash % 3) + ((hash >> 4) % 3) + ((hash >> 8) % 3);
// Ergebnis : Variation max ±6 Blöcke, geclampt auf SEA_LEVEL+1

Forest: Höhe 50, 4 Faktoren wie Plains aber höhere Basis → bewaldete Hügel.

Taiga: Höhe 46, 3 Faktoren → moderate Variationen, kaltes Terrain.

Snowy Plains: Höhe 40, nur 2 Faktoren → am hügeligsten.

h = (hash % 5) + ((hash >> 4) % 5);
// Ergebnis : Variation max ±14 Blöcke

Jedes Biom ist in 3 Tabellen zu 5 Einträgen kodiert: Basishöhe, Oberflächenblock, Faktorenzahl. Wenn getHeightAtFromHash das Biom empfängt, konsultiert es diese Tabellen, um das Terrain anzupassen. 15 Byte Daten, um das ganze Vanilla-Minecraft-Biomsystem zu ersetzen.

Der Biomdetektor nutzt die Seed, um zu bestimmen, welches Biom zu jedem Chunk passt:

// worldgen.c (vereinfacht)

static const uint8_t biome_pattern[] = {
  BIOME_PLAINS, BIOME_FOREST, BIOME_PLAINS, BIOME_DESERT,
  BIOME_FOREST, BIOME_TAIGA,  BIOME_PLAINS, BIOME_SNOWY,
  BIOME_PLAINS, BIOME_FOREST, BIOME_DESERT,  BIOME_PLAINS,
  BIOME_SNOWY,  BIOME_PLAINS, BIOME_FOREST, BIOME_TAIGA,
};

uint8_t getChunkBiome (short cx, short cz) {
  uint32_t h = splitmix64(cx * 31 + cz * 97 + world_seed);
  uint8_t index = h % 16;
  return biome_pattern[index];
}

Ein 16-Einträge-Pattern, ein von Chunk-Koordinaten geseedeter Index. Das gibt ein repetitives aber visuell kohärentes Grid. 4 Codezeilen, um das ganze biomische Vanilla-Minecraft-Parametersystem zu ersetzen.

getHeightAtFromHash: der Terrain-Assembler

Die Kernfunktion der Generierung kombiniert die 4 biomgeseedeten Ecken:

// worldgen.c (vereinfacht)

static uint8_t getHeightAtFromHash (int rx, int rz, short cx, short cz,
                                    uint32_t h, uint8_t biome) {
  // 4 Ecken aus Hash extrahiert, andere Seed pro Ecke
  uint8_t h1 = biome_base[biome] + (h & 0x0F);
  uint8_t h2 = biome_base[biome] + ((h >> 4) & 0x0F);
  uint8_t h3 = biome_base[biome] + ((h >> 8) & 0x0F);
  uint8_t h4 = biome_base[biome] + ((h >> 12) & 0x0F);

  // Biom-Bedingung : Wüste nie unter Wasser
  if (biome == BIOME_DESERT) {
    h1 = max(h1, SEA_LEVEL + 1);
    h2 = max(h2, SEA_LEVEL + 1);
    h3 = max(h3, SEA_LEVEL + 1);
    h4 = max(h4, SEA_LEVEL + 1);
  }

  // Interpolation aus den 4 Ecken
  return interpolate(h1, h2, h3, h4, rx, rz);
}

Jedes Biom hat eine biome_base, die die Referenzhöhe verschiebt, und die 4 Ecken werden mit verschiedenen Shifts aus dem Hash extrahiert. Die Wüste forct das Min über Meeresspiegel, eine Bedingungszeile, die Wasser ohne zusätzliche biomische Berechnung vermeidet.

Bäume und Kakteen: probabilistisches Platzieren

Die Oberflächengenerierung nutzt denselben Chunk-Hash, um zu entscheiden, wo zu pflanzen:

// worldgen.c (vereinfacht)

static void genFoliage (uint8_t *chunk_data, short cx, short cz,
                        uint32_t hash, uint8_t biome) {
  if (biome == BIOME_DESERT) {
    // Kaktus : ein Kandidat pro Chunk, Hash bestimmt Position
    int tx = (hash >> 8) & 7;
    int tz = (hash >> 12) & 7;
    int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
    if (chunk_data[ty * 64 + tz * 8 + tx] == B_sand)
      placeCactus(chunk_data, tx, ty + 1, tz);
  } else {
    // Bäume : Hash bestimmt ob und wo
    int tree_count = (hash & 3);  // 0-3 Bäume pro Chunk
    for (int i = 0; i < tree_count; i ++) {
      int tx = ((hash >> (4 + i * 4)) & 7);
      int tz = ((hash >> (6 + i * 4)) & 7);
      int ty = getHeightAt(cx * 8 + tx, cz * 8 + tz);
      placeTree(chunk_data, tx, ty + 1, tz);
    }
  }
}

0-3 Bäume pro Chunk für grüne Biome, max 1 Kaktus für Wüste. Der Chunk-Hash ist die einzige Entropiequelle, ein & 7 für Position im Chunk, ein & 3 für Zähler. Alles deterministisch, nichts gespeichert.

generateChunk: alles zusammensetzen

Die Funktion, die alles zusammenfügt, um einen kompletten 8×8×256-Block-Chunk zu produzieren:

// worldgen.c (vereinfacht)

void generateChunk (uint8_t *chunk, short cx, short cz) {
  uint32_t hash = getChunkHash(cx, cz);
  uint8_t biome = getChunkBiome(cx, cz);

  // Für jede Chunk-Spalte (8×8 = 64)
  for (int x = 0; x < 8; x ++) {
    for (int z = 0; z < 8; z ++) {
      // Absolute Weltkoordinaten
      int wx = cx * 8 + x;
      int wz = cz * 8 + z;

      // Spaltenhöhe
      uint8_t height = getHeightAt(wx, wz);

      // Spalte von unten nach oben füllen
      for (int y = 0; y < height; y ++) {
        uint8_t block = getTerrainBlock(wx, y, wz);
        chunk[y * 64 + z * 8 + x] = block;
      }
    }
  }

  // Oberflächenelemente hinzufügen (Bäume, Kakteen)
  genFoliage(chunk, cx, cz, hash, biome);
}

Das ist alles. 3 verschachtelte Schleifen: Für jede Spalte Höhe finden, Blöcke füllen, weiter. Output ist ein uint8_t[16384] (8 × 8 × 256), das den kompletten Chunk darstellt. Der Chunk wird generiert und direkt an den Client geschickt, ohne Caching, Lazy Loading oder Kompression.

Der Speicher: überall statische Arrays

Bareirons Speicherarchitektur ist eingebettetes C in voller Pracht: Nur globale fixgroße Tabellen, kein malloc, keine Hash Maps, keine Linked Lists.

Die Blockänderungen

// globals.h, Zeilen 191-196

typedef struct {
  short x;      // 2 Bytes, limitiert auf 32.000 horizontale Blöcke
  short z;      // 2 Bytes
  uint8_t y;    // 1 Byte, limitiert auf 256 vertikale Blöcke
  uint8_t block; // 1 Byte, limitiert auf 256 Blocktypen
} BlockChange;

20.000 Einträge, also etwa 25.000 Änderungen, das Äquivalent von anderthalb komplett umgegrabenen Chunks. Das block-Feld auf 0xFF markiert einen freien Eintrag. Suche ist linearer Scan:

// procedures.c

uint8_t getBlockChange (short x, uint8_t y, short z) {
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block == 0xFF) continue;
    if (block_changes[i].x == x && block_changes[i].y == y && block_changes[i].z == z)
      return block_changes[i].block;
    #ifdef ALLOW_CHESTS
      if (block_changes[i].block == B_chest) i += 14;  // Truhendaten überspringen
    #endif
  }
  return 0xFF;
}

Änderung hinzufügen ist so direkt wie Suche:

static uint8_t changes_count = 0;

void addBlockChange (short x, short z, uint8_t y, uint8_t block) {
  if (changes_count >= MAX_CHANGES) return;
  block_changes[changes_count].x = x;
  block_changes[changes_count].z = z;
  block_changes[changes_count].y = y;
  block_changes[changes_count].block = block;
  changes_count ++;
}

Ein Zähler, ein Index, ein Write. Die Tabelle stapelt nur: Kein Sortieren, keine Kompaktierung, kein Speichermanagement. Wenn die Tabelle voll ist, werden neue Änderungen ignoriert, das Terrain kehrt zu generiertem Zustand zurück.

Der Autorenkommentar zum 256-Block-Limit: "Ich habe nicht vor, die leicht patiniert gewachste Kupfertrappe so bald zu implementieren."

Die Mobs: 8 Bytes pro Pipe-Kopf

// globals.h, Zeilen 240-251 (pragma pack(push, 1) um Padding zu eliminieren)

typedef struct {
  uint8_t type;   // 25=Huhn, 28=Kuh, 95=Schwein, 106=Schaf, 145=Zombie
  short x;
  uint8_t y;      // wenn Health=0, wird Y Timer vor Löschung
  short z;
  uint8_t data;   // Bits 0-4 : Health, Bit 5 : Schaf geschoren, Bits 6-7 : Panik-Timer
} MobData;

8 Bytes. Max 16 Slots. Alignment und Padding fliegen raus. Das data-Byte ist ein Haus-Bitfield: 5 Bit Leben, 1 Bit Schur, 2 Bit Panik-Timer. Und wenn ein Mob stirbt, wird das Y-Feld Timer vor Löschung. Speichernutzung auf Bitebene.

Die Spieler: eng gepackt

Spielerdaten nutzen auch #pragma pack(push, 1), Koordinaten in short + uint8_t, Inventare in fixen uint16_t- + uint8_t-Tabellen, und ein flags-Feld, das zugleich Angriffs-Cooldown, Spawn-State, Sneak, Sprint, Eat, Load, Movement-Cooldown und Craft-Lock kodiert. Alles in individuellen Bits.

Die Hauptschleife: while(true) und non-blocking

Der ganze Server läuft auf einer Schleife, einem Thread, null Event-Library.

// main.c, Zeilen 594-720

while (true) {
  task_yield();  // lässt Watchdog auf ESP32 atmen

  // Neue Verbindung akzeptieren (non-blocking)
  for (int i = 0; i < MAX_PLAYERS; i ++) {
    if (clients[i] != -1) continue;
    clients[i] = accept(server_fd, ...);
    if (clients[i] != -1) client_count ++;
    break;
  }

  // Server-Tick wenn Zeit um
  if (get_program_time() - last_tick_time > TIME_BETWEEN_TICKS) {
    handleServerTick(time_since_last_tick);
    last_tick_time = get_program_time();
  }

  // Round-Robin : ein Client, ein Paket pro Iteration
  client_index = (client_index + 1) % MAX_PLAYERS;
  if (clients[client_index] == -1) continue;

  // Paket-Header lesen : Length + ID
  recv(client_fd, &recv_buffer, 2, MSG_PEEK);
  int length = readVarInt(client_fd);
  int packet_id = readVarInt(client_fd);
  handlePacket(client_fd, length - sizeVarInt(packet_id), packet_id, state);
}

Ein einziger Client wird pro Schleifeniteration behandelt, und ein einziges Paket auf einmal gelesen. Das task_yield() am Schleifenanfang lässt den FreeRTOS-Idle-Task auf ESP32 atmen, ohne das resettet dich der Watchdog-Timer den Chip.

Der Paket-Dispatch ist ein monströser 400-Zeilen-Switch:

// main.c, Zeilen 68-497

void handlePacket (int client_fd, int length, int packet_id, int state) {
  switch (packet_id) {
    case 0x00:  // Handshake / Status / Login je nach State
    case 0x01:  // Status-Ping
    case 0x02:  // Plugin-Message
    case 0x03:  // Login/Config-Acknowledgment
    case 0x08:  // Chat
    case 0x0B:  // Client-Status (Respawn)
    case 0x11:  // Click Container (handhabt Truhen)
    case 0x19:  // Interact Entity
    case 0x1D..0x20:  // Movement-Pakete (größter Fall)
    case 0x28:  // Player Action (Dig/Place)
    // ... 40+ Fälle
  }
}

Ein Switch kompiliert zu statischer Jump Table, was dynamische Jump Table, Vtable und Map ersetzt. Perfekt für Embedded.

Der 0x1D-0x20-Fall ist der größte, er handhabt Positionsupdates, Fallschaden, Chunk-Grenzüberquerungen, Mob-Spawn, Chunk-Generierung UND Hunger. Alles in einem einzigen großen Fall-through.

Der Server-Tick und Mob-KI

Die handleServerTick-Funktion wird alle 50 ms aufgerufen (20 TPS). Sie handhabt die Welt, während die Hauptschleife sich um Spieler kümmert:

// main.c (vereinfacht)

void handleServerTick (uint32_t delta) {
  // Jeden Mob updaten
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type == 0 || mobs[i].data == 0) continue;  // tot oder leer

    MobData *mob = &mobs[i];
    int px, pz;
    getNearestPlayer(mob->x, mob->z, &px, &pz);

    if (mob->type == MOB_ZOMBIE) {
      // Hostil : läuft zum nächsten Spieler
      if (px < mob->x) mob->x --;
      else if (px > mob->x) mob->x ++;
      if (pz < mob->z) mob->z --;
      else if (pz > mob->z) mob->z ++;
      // Kontaktschaden auf 2 Blöcke
      if (abs(px - mob->x) <= 2 && abs(pz - mob->z) <= 2)
        damagePlayer(getNearestPlayerId(mob->x, mob->z), 3);
    } else {
      // Passiv : 8 Zufallsrichtungen
      uint8_t dir = getMobDir(mob);
      mob->x += dir_lookup[dir][0];
      mob->z += dir_lookup[dir][1];
      // Richtungswechsel etwa alle 40 Ticks
      if (mob->data >> 6 < 1) setMobDir(mob, rand() & 7);
      mob->data = (mob->data & 0x3F) | ((mob->data - 0x40) & 0xC0);
    }

    // Chunks um Mob wecken
    setChunkGenerated(mob->x / 8, mob->z / 8);
  }
}

Hostile Mob-KI ist ein Koordinatenvergleich. Buchstäblich if (px < x) x--. Der Zombie ignoriert Pathfinding, A* und Obstacle Avoidance: Er justiert X und Z unabhängig zum Spieler, er läuft durch Wände, wenn welche da sind.

Kontaktschaden ist 3 Herzen/Sek. p2r3 wollte ihn hoch, weil fehlendes Pathfinding Zombies leicht kitbar macht.

Die Rüstungsformel ist die von vor dem Combat Update, die simpelstmögliche:

// main.c (vereinfacht)

static uint8_t applyArmor (uint8_t damage, uint16_t armor_value) {
  // Prä-1.9-Formel : lineare Reduktion
  // Jeder Rüstungspunkt = 4% Reduktion, max 80%
  uint8_t reduction = (armor_value * 4);
  if (reduction > 80) reduction = 80;
  return damage * (100 - reduction) / 100;
}

Full Diamond = 80% Reduktion. Ein 3-Herzen-Zombieschlag wird 0.6 Herzen. p2r3 wählte diese alte Formel, weil sie sich in 2 Operationen berechnet, keine Schwellen, keine Kurven, nur linearer Prozentsatz.

Passive Mobs: 8 Richtungen in einer Lookup-Table, Kurswechsel etwa alle 40 Ticks. Das data-Feld kodiert die laufende Richtung in den 2 hochwertigen Bits und den Richtungswechsel-Timer in den 6 restlichen Bits.

Der Mob-Respawn

Mobs spawnen nicht mit Random Ticks. Sie erscheinen, wenn der Server-Tick auf eine neue Chunk-Grenze trifft:

if (player crossed chunk boundary) {
  for (int i = 0; i < MOB_COUNT; i ++) {
    if (mobs[i].type != 0) continue;
    spawnMob(&mobs[i], new_chunk_coords, getChunkHash(cx, cz));
    break;
  }
}

Derselbe RNG wie Terrain, dieselbe Chunk-Seed. Wenn ein Mob-Slot frei ist, ist der Spawn deterministisch.

Das Craften: keine Matrizen, if/else

// crafting.c, Zeilen 9-347 (vereinfacht)

void getCraftingOutput (PlayerData *player, uint8_t *count, uint16_t *item) {
  // Wenn Flag 0x80 gesetzt, wird Craft-Buffer von Truhe benutzt
  if (player->flags & 0x80) { *count = 0; *item = 0; return; }

  // Slots zählen, erstes Item finden, Identität prüfen
  uint8_t filled = 0, first = 10, identical = true;
  for (int i = 0; i < 9; i ++) {
    if (player->craft_items[i]) {
      filled ++;
      if (first == 10) first = i;
      else if (player->craft_items[i] != player->craft_items[first])
        identical = false;
    }
  }

  switch (filled) {
    case 1:  /* Bretter, Barren... */
    case 2:  /* Stöcke, Scheren, Fackeln */
    case 3:  /* Schaufeln, Schwerter, Stufen */
    case 4:  /* Werktisch, Boots */
    case 5:  /* Spitzhacken, Äxte, Helme */
    case 7:  /* Beinschienen, Komposter */
    case 8:  /* Ofen, Truhe, Brustpanzer */
    case 9:  /* komplette Blöcke (Eisen, Gold usw.) */
  }
}

Der erste Check: Wenn Flag 0x80 gesetzt, wird Craft-Buffer als Truhenpointer recycelt. Craften bleibt verriegelt.

Danach zählt er gefüllte Slots, notiert erstes Item, prüft Identität. Schon damit matchst du den Ofen in 4 Checks:

if (count == 8 && first == cobblestone && all_identical && center_empty)
    return furnace;

Für komplexe Formen nutzt er den Erst-Item-Index und prüft relative Position. Rezepte teilen dieselbe Matching-Funktion, das Material bestimmt Ergebnis.

Die Truhen: der Hack live

Der Speichern-Hack, über den alle reden, in echtem Code:

// procedures.c, Zeilen 1262-1293

if (target == B_chest) {
  // Truheneintrag in Blocktabelle suchen
  uint8_t *storage_ptr = NULL;
  for (int i = 0; i < block_changes_count; i ++) {
    if (block_changes[i].block != B_chest) continue;
    if (block_changes[i].x != x || block_changes[i].y != y || block_changes[i].z != z)
      continue;
    storage_ptr = (uint8_t *)(&block_changes[i + 1]);  // zeigt hinter Truhenblock
    break;
  }
  if (storage_ptr == NULL) return;

  // Terrible memory hack!!
  // Wir kopieren den POINTER in das Spieler-Craft-Item-Array
  memcpy(player->craft_items, &storage_ptr, sizeof(storage_ptr));
  player->flags |= 0x80;  // verriegelt Craften

  // Truheninterface an Client schicken
  sc_openScreen(player->client_fd, 2, "Chest", 5);
  for (int i = 0; i < 27; i ++) {
    uint16_t item;
    uint8_t count;
    memcpy(&item, storage_ptr + i * 3, 2);
    memcpy(&count, storage_ptr + i * 3 + 2, 1);
    sc_setContainerSlot(player->client_fd, 2, i, count, item);
  }
}

Und der Kommentar im Code: // Terrible memory hack!!1!

Genau das. Er nimmt die Speicheradresse des folgenden Eintrags in block_changes[], kopiert sie in player->craft_items (das ein uint16_t[9] ist, also 18 Bytes, genug um einen 32-bit-Pointer zu speichern), und hebt das Flag, damit niemand währenddessen craftet.

Bei jedem Klick in Truheninventar:

// packets.c, Zeilen 620-638

uint8_t *storage_ptr;
memcpy(&storage_ptr, player->craft_items, sizeof(storage_ptr));
// storage_ptr zeigt jetzt auf Truhendaten
uint16_t *p_item = (uint16_t *)(storage_ptr + (slot - 41) * 3);
uint8_t *p_count = storage_ptr + (slot - 41) * 3 + 2;

Er holt den Pointer aus dem Craft-Buffer zurück und greift per Offset auf Slots zu. Truhendaten liegen zu 3 Bytes pro Slot (2 für ID, 1 für Menge), aneinandergeklebt in der Blocktabelle.

Der Hunger: 5 Zeilen Genie

// main.c, Zeilen 293-305

// Spieler schicken Bewegungspakete ~20/Sek wenn sie
// sich bewegen, viel weniger wenn sie stillstehen. Man korreliert das
// mit Aktivität, um Hunger gratis zu simulieren.
if (player->saturation == 0) {
  if (player->hunger > 0) player->hunger--;
  player->saturation = 200;
  sc_setHealth(client_fd, player->health, player->hunger, player->saturation);
} else if (player->flags & 0x08) {  // Sprinten
  player->saturation -= 1;
}
}

Buchstäblich das. 5 Zeilen. Jedes Bewegungspaket dekrementiert Sättigung. Wenn Sättigung null erreicht, sinkt Hunger und man resettet Sättigung. Sprint (Flag 0x08) verdoppelt Drain.

Null Timer, null allokierter Speicher, null dediziertes Compute. Ein Zähler, der auf eh existierenden Paketen dekrementiert.

Der Fallschaden

Das simpelste Schadenssystem des Projekts:

// Wenn Spieler Boden verlässt, speichert man sein Y
// Wenn er Boden wieder berührt, subtrahiert man
Schaden = letztes_y_am_Boden - aktuelles_y;

Eine Subtraktion.

Blöcke minen und platzieren

Wenn du auf einen Block klickst, landet das 0x28-Paket (Player Action) im Switch. Der Handler muss bestimmen, welcher Block an der Position ist, ihn entfernen und das Item ins Inventar legen:

// main.c, Fall 0x28 (vereinfacht)

void handlePlayerAction (int client_fd, uint8_t action, int x, uint8_t y, int z) {
  switch (action) {
    case START_DESTROY_BLOCK: {
      // Blocktyp an geklickter Position bestimmen
      uint8_t block = getBlockAt(x, y, z);

      if (block == B_chest) {
        openChest(client_fd, x, y, z);
        break;
      }

      // Zu block_changes hinzufügen
      addBlockChange(x, z, y, 0);  // 0 = Luft

      // Item an Spieler geben (trust the client)
      addItemToPlayer(client_fd, block_to_item(block), 1);

      // Update an Client schicken
      sc_blockChange(client_fd, x, y, z, 0);
      sc_ackBlockChange(client_fd, x, y, z, 0);
      break;
    }
    case PLACE_BLOCK: {
      // Blocktyp aus Spielerhand lesen
      uint16_t item = getHeldItem(client_fd);
      uint8_t block = item_to_block(item);
      addBlockChange(x, z, y, block);
      removeItemFromPlayer(client_fd, item, 1);
      sc_blockChange(client_fd, x, y, z, block);
      break;
    }
  }
}

getBlockAt kombiniert Terraingenerierung UND Spieleränderungen:

uint8_t getBlockAt (int x, uint8_t y, int z) {
  // Zuerst Spieleränderungen prüfen
  uint8_t change = getBlockChange(x, y, z);
  if (change != 0xFF) return change;

  // Sonst aus generiertem Terrain lesen
  return getTerrainBlock(x, y, z);
}

Priorität auf Änderungen, Fallback auf Terrain. Null Debatte, null Cache, null Overhead. Das getTerrainBlock darunter ist getHeightAt + Stone/Dirt/Grass/Coal-Schichten.

Der Instant-Ofen

Das Lustigste: Der Ofen existiert nicht als Entity. Wenn du Cobblestone in den "Koch"-Slot und Coal in "Fuel" legst, erscheint das Ergebnis sofort, ohne Timer oder Chunk Ticking: Es ist nur ein Inventarslot, der sich leert, wenn du die richtigen Items legst.

Die ESP32-Schleife: ein MC-Server in 4 KB Stack

// main.c, Zeilen 732-779

#ifdef ESP_PLATFORM

void bareiron_main (void *pvParameters) {
  main();
  vTaskDelete(NULL);
}

static void wifi_event_handler (...) {
  if (/* verbunden */) {
    xTaskCreate(bareiron_main, "bareiron", 4096, NULL, 5, NULL);
  }
}

void app_main () {
  esp_timer_early_init();
  wifi_init();
  // Rest handhabt Event Handler
}
#endif

Der ganze Server läuft in einem FreeRTOS-Task mit 4096 Bytes Stack. Das ist alles. Der Main-Thread initialisiert nur WiFi und wartet auf Verbindung. Einmal verbunden, spawnt er bareiron_main, das das Standard-main() aufruft.

Aller ESP32-spezifische Code ist von #ifdef ESP_PLATFORM geschützt. Auf PC kompiliert das alles zu Standard-POSIX-Code.

Was geopfert wurde

Damit das alles passt, gibt es Vanilla-Features, die nicht existieren:

• Null Netzwerkkompression, zlib zu teuer. Der Server generiert Chunks schnell, aber sie zu schicken ist Bottleneck.
• Null Random Ticks, Bäume wachsen mit Bone Meal oder nicht. Mobs spawnen an Chunk-Grenzen.
• Null Item-Entity, geminte Blöcke gehen direkt ins Inventar. Animation ist rein visuell.
• Keine Inventarprüfung, trust the client. 64 Diamanten? OK. Ein Chunk in 1 Sek gemint? OK. Unter vertrauenswürdigen Leuten nutzen.
• Null Serverlicht, Fackeln werden nach allem Rest geschickt, der Client berechnet.
• Null progressive Fluide, instantaner Endzustand.

Das Endergebnis

Ryzen 5 3600: ~0.5 ms pro Chunk. 1$-ESP32-C3: ~200 ms pro Chunk. Spielbar.

3+ Spieler: Es ruckelt. Vergleichbar mit 2b2t zu Stoßzeiten, laut Autor.

Die Philosophie

p2r3: "Ich mag einfach die Idee, dass dieser winzige 1-Balles-Chip, der 0.5 Watt verbraucht, etwas so Fortgeschrittenes wie Minecraft laufen lassen kann. Science isn't about 'why', it's about 'why not'."

Jede Zeile ist ein Tradeoff:

• Perlin Noise → Interpolation: Weniger hübsch, 200x schneller, null Speicher
• Craft-Matrizen → hardcoded Matching: Hässlicher Code, null Byte
• zlib → nichts: Miese Verbindung = tot, aber spielbar
• Validierung → Trust: Null Sicherheit, null Compute

Jedes fehlende Feature erlaubt einem anderen, in Hardware-Limits zu existieren.

Die 3 Punkte zum Mitnehmen :

1. Interpolation + RNG, 4 geseedete Punkte, unendliches Terrain, null Speicherung, Query ohne Chunk-Regenerierung, 200 ms Generierung. Der Genie-Move, der alles andere erst möglich macht.
2. Jedes Feature hat Kosten, fehlende Kompression, Random Ticks und Validierung sind eingestandene Wahl: Das erlaubt, in 520 KB zu passen.
3. Eklige Hacks sind die cleversten, Truhen in Blocktabelle via memcpy, Hunger via Bewegungspakete, Instant-Ofen. Die saubere Lösung wäre zu teuer gewesen.

Wenn dich das Projekt interessiert, alles liegt auf GitHub unter GPLv3. Saumäßig dreckiges C, und ich hatte selten so viel Spaß beim Lesen von Sourcecode.