Building System

Authoritative project content

Free-form (Rust-like) construction — [CONFIRMED]. Players place modular structural pieces that snap together to form custom bases. Bases are persistent on the server and raidable by other players.

Build modes

1. Structure mode: place structural pieces (foundation, wall, floor, ceiling, doorway, stairs, ramp, window). Pieces snap to sockets on adjacent pieces; foundations snap to valid terrain.
2. Deployable mode: place functional objects (door, storage box, crafting station, campfire/stove, sleeping bag/bed, workbench, turret [TBD], traps). The workbench is both a crafting station and the firearm customization station (09-Weapon-Customization.md); anyone nearby can use firearm work on it.

A build component (UBuildComponent) shows a ghost/preview, validates placement (collision, snap, support, ownership rules), and sends a server request to commit.

[CONFIRMED 2026-09-13] Place, upgrade, repair, and demolish require the acting player to hold an item that grants Tool.Role.Hammer (starter item: planned Item.Weapon.WoodenMallet). Authorize does not require Hammer. Canonical role/presence rules: FEAT-INVENTORY.

Piece set (v1 — minimal)

Expand the set in later phases (high walls, gates, foundation steps, triangle pieces). Keep v1 small to control art + netcode + raiding-balance cost.

Snapping & placement rules

• Socket-based snapping (each piece exposes snap sockets); free rotation when not snapped.
• Placement validation (server-authoritative): no overlap with disallowed geometry, must be supported, must be within a build-allowed area, and the placer must have build permission for that location. Canonical no-build categories and volume shapes live in FEAT-WORLD-DESIGN; exact buffer meters are authored per volume.
• Build privilege: a Tool Cupboard / Territory Anchor concept [RECOMMENDATION] — placing an anchor claims a radius where only authorized players (squad/clan) can build/modify. This is the standard solution to grief-proofing free-form building and ties into territory progression. See ../04-Multiplayer/03-Clans-and-Squads.md.

Materials & upgrade tiers

Pieces are crafted from gathered resources and use three confirmed material tiers: Wood → Brick & Mortar → Steel. Higher tiers have more HP and resist more raid damage. Exact HP, resistance, upgrade-cost, and raid-cost values remain [TBD].

Health, damage & raiding

• Every placed piece has HP and a material tier; raid tools (explosives, melee against soft sides, cutting tools) deal type-specific damage. See ../04-Multiplayer/04-PvP-Raiding-and-Trading.md.
• [CONFIRMED] full raiding is allowed — bases can be breached and looted.
• [RECOMMENDATION] weak-side/strong-side mechanics (walls cheaper to break from the inside) for raid depth.
• Decay: unmaintained structures decay over time [RECOMMENDATION] to clean up abandoned bases on persistent servers (critical for server health).

Networking & persistence — [RISK]

This is one of the most expensive systems to do well:

• A base may contain hundreds of pieces. Naïvely each-piece-as-an-actor does not scale to ~40–60 players × many bases. Mitigations to evaluate: Instanced Static Meshes / Hierarchical ISM for visuals, lightweight per-piece state, dormancy, and net relevancy by distance. The project has ISM tooling available.
• All placed structures must be persisted and restored on server restart (positions, tiers, HP, ownership, container contents and applicable lock layers). See Network Architecture.
• Representation — [CONFIRMED]: normal walls, floors, and roofs use ISM; pieces under construction use Actors; attacked or temporarily stateful pieces use an Actor or ISM backed by a server-side record; doors, storage/chests, generators, traps, and crafting stations use Actors; cosmetic/static structures use ISM.
• Persistence — [CONFIRMED]: every persistent piece is represented by a data record in the dedicated server SQLite database. Actor promotion/demotion must preserve the same stable record identity.
• Relevancy: replicate interactive Actors by distance and dormancy; stream ISM visuals from authoritative server records. Exact promotion thresholds and update frequencies are performance-tuned.

Implementation guidance

• UBuildComponent (C++) handles mode, preview, validation request.
• Building pieces defined data-driven (mesh, sockets, tier, HP, cost) so adding pieces is content work, not code.
• Preview/ghost and input handling are reasonable to drive partly in Blueprint; placement validation and commit must be C++ server logic.