Christian Loffel / Bedrock Portfolio
Case Study · In-Game Build System

Structure
Builder

A full construction orchestration system for large airport builds — with 15-deep heterogeneous undo, owner-locked permissions, material economies, anti-exploit refund logic, and a custom Python tool to preview structures before placing them.

Script API Dynamic Properties Custom Blocks Structure API Ticking Areas Python Tooling Transaction Pattern Undo Stack
structure_builder.profile
Undo Depth 15per owner
Undo Operations Heterogeneousall ops
Material Modes 4Low / Normal / Realistic / Off
Architecture 10managers
Complexity
Custom Tooling
Python script converts .mcstructuregeo.json for in-game preview entities. Built because no tool existed.
00 — The Problem

What Bedrock Can't Do

Bedrock has no build history, no undo, no material system, no owner permissions, no async transaction safety. All of it had to be built from scratch.

No undo / build history of any kind
15-deep heterogeneous undo stack with terrain backup per operation
Every operation (rotate, place, fill, foundation) backs up the affected terrain first. Undo restores from that backup. All operation types are tracked in the same stack — not just block placement.
No structure preview before placement
Preview entity system + custom Python .mcstructure → geo.json converter
A tagged preview entity shows the structure footprint with particle markers. The Python tool converts .mcstructure files into geometry JSON so the entity can display the actual shape in-game — no tool existed for this, so one was written.
No material requirements or ownership system
materialsManager + owner-locked Place/Undo blocks with 4 modes
Four material modes: Low / Normal / Realistic / Off (Creative). Inventory checked and consumed on confirm. Only the owner of a Place block can interact — no foreign access. Anti-exploit refund logic tracks what was consumed, not what exists at undo time.
No transactional world operations — partial failures corrupt builds
Backup-first pipeline with rollback at every failure stage
Terrain is backed up before any structure loads. If material check, foundation, structure load, or fill-above-air fails at any stage, the backup restores the world to its prior state. No silent corruptions.
No concurrent operation safety
Global operationLock + per-placement processing flag
A global builder lock and per-placement processing flag prevent two players or two actions from touching the same placement simultaneously. UI shows "builder busy" feedback.
No persistent state across sessions
Full placement records in World Dynamic Properties with migration
Every placement record serialized to aria_pp:sb:pl:<id> World Dynamic Property. Start-up hydration validates, migrates, and reindexes all records — stale or broken entries are cleaned automatically.
01 — In Action

Visuals

Screenshots and recordings needed — placeholders show what each should capture.

🎬 GIF / Video — Wide Shot Full workflow: Place block → UI → Preview entity appears → Confirm → Structure loads with animation → Undo block visible
Full Placement Workflow
Place block → Placement Menu → Confirm pipeline → Structure placed · Best as a ~15s screen recording
📸 Screenshot Placement UI open — showing Variant, Preview, Rotation, Foundation, Materials, Confirm buttons
Placement Menu
ActionForm UI · context-dependent options · material cost shown
🎬 GIF / Video Preview entity spawns with particle bounds markers — player rotates structure, preview updates live
Live Preview Entity
Tagged preview entity · particle bounds · TTL cleanup · Python geo.json model
🎬 GIF / Video Player undoes 3-4 operations in sequence — terrain restores each time, undo block disappears on last
Undo Stack in Action
15-deep · heterogeneous ops · terrain backup restore · material refund
📸 Screenshot Foundation layer visible under structure — weighted block palette showing variation
Foundation System
Weighted block palette · terrain adaptation · additional material cost
📸 Screenshot Parent structure with child slots active — small + large hangar options visible on sides
Parent / Child Slot System
Base → runway → terminal chain · side exclusivity · gap auto-sync
📸 Screenshot — Python Tool Python script output: .mcstructure file → geo.json side by side, or terminal output visible
Python: .mcstructure → geo.json
Custom tooling · written because no converter existed · enables in-game preview
🎬 GIF / Video Fill Above Air: structure placed, then sky above cleaned automatically — before/after
Fill Above Air
Post-placement cleanup · air blocks above structure removed · tracked in undo
02 — Architecture

Confirm Pipeline

Every placement goes through this transactional sequence. Each stage can trigger a rollback to the stage before it.

01
Lock + Validate
Global lock · owner check · state check · source block check
02
Material Check
Inventory scan · mode (Low/Normal/Realistic/Off)
fail → unlock, notify
03
Terrain Backup
Save bounds to .mcstructure before any world change
fail → unlock
04
Consume Materials
Remove items from inventory (if mode requires)
fail → restore backup
05
Foundation + Fill
Weighted palette foundation · Fill Above Air cleanup
fail → restore backup + refund
06
Structure Load
Place .mcstructure (multipart: gap ticks between parts)
fail → restore backup + refund
07
Verify + Persist
Undo block exists · status=placed · Dynamic Property write
Undo Stack — 15 slots per owner (heterogeneous operations)
Active backup — oldest is invalidated when limit reached (slot 15). Operations: Base · Runway · Foundation · Fill · Rotation · Hangar · Terminal  ·  ✗ Invalidated when limit exceeded
03 — Robustness

Edge Cases & Solutions

Bedrock's async, tick-driven architecture surfaces problems that don't exist in synchronous engines. Each one required an explicit fix.

🔒
Concurrent Actions
Two players confirming at the same time, or double-clicking — both could corrupt the same placement. Global operationLock + per-placement processing flag. Only one action runs at a time. UI shows "builder busy".
operationLock.js
💥
Partial Failure / Corruption
Bedrock has no atomic world operations. Structure load can fail mid-way. Terrain backup is written before any change. Every stage after that carries a rollback path. No partial builds survive a failure.
Backup-first strategy
Grace-Window for Source Loss
A Place block could be destroyed by an explosion or another player before the confirm. Source loss is detected by tick-loop — but 40-tick grace window prevents false-positives from chunk lag before cleanup fires.
40-tick grace
📚
Undo Limit (15) — Oldest Invalidated
Each owner can hold 15 active backups. When the 16th arrives, the oldest backup is explicitly invalidated — its backup data deleted, undo marked unavailable — to prevent unbounded Dynamic Property growth.
undoManager.js
🧱
Multipart Structures
Terminal and large hangars can't load as one command — Bedrock's structure API has size limits. These are split into multipart variants (*_q1..q4) with gap ticks between each part load to allow chunk settle.
*_q1..q4 variants
🏗️
Chunk Safety
Structure operations on unloaded chunks silently fail in Bedrock. Temporary Ticking Areas are created around the place and undo bounds for every operation — removed after the operation settles.
Ticking Areas
🔄
Gap Middle-Piece Sync
When two matching small children are placed on a side, a middle-piece gap structure is auto-generated between them. On undo or change, the gap is checked and reconciled — removed if the pair no longer matches.
Gap reconciliation
🛡️
Anti-Exploit Refund
Refunds track what was consumed at confirm time, stored in the placement record — not what exists in the world at undo time. Players can't swap materials between build and undo to duplicate items.
materialsManager.js
Side Exclusivity (small vs large)
A runway side can hold either small children or a large child — never both. Side-locking switches conflicting Place blocks to Air. Re-enabling optionally respawns them if RESPAWN_PLACE_BLOCKS_WHEN_UNLOCKED is true.
Side-lock system
Next Case Study
Spawn Egg Serialization →
← Back to Portfolio