From Fence to Refuge: Building Kali’s House System

The first version of Kali’s building system was a fence. Press build, point at the ground, and place a ghosted segment. It was small enough to make in one pass—and specific enough to reveal the real problem: a building system is not a catalogue of meshes. It is the player’s relationship with space.

The aim was never to let players scatter parts everywhere. The aim was to make rebuilding a place feel deliberate, readable, and alive.

Start with one honest interaction

That first fence established the contract for everything that followed. The preview raycasts against the terrain, checks its slope and overlap, and can snap to a nearby endpoint. A placed fence becomes a useful thing for the next fence to understand. The player is not just placing an object; they are extending a small, growing network of relationships.

• The ghost answers a practical question before the click: can this go here?

• The placed piece contributes to future snapping instead of becoming inert scenery.

• The build toolbar renders its own scene thumbnails, so a new buildable can carry its own preview rather than requiring a separate icon pipeline.

That last point sounds technical, but it matters to the experience. If the data that makes a piece placeable can also make it understandable in the toolbar, adding a new part stops feeling like wiring up three unrelated systems.

Build mode still has to be part of the game

The next important decision was less visible. Build mode could not become a separate, frozen interface that turns the player into a cursor. Movement remains available, but combat and evasive actions are routed through one gameplay-input seam and are unavailable while building. That keeps the existing player state machine intact instead of filling every combat state with a special case.

The timing is split on purpose, too. The physics system samples the world for valid placement; the visual preview resolves with the camera. It is a small architectural separation with a very player-facing outcome: a cursor-following blueprint can stay responsive without asking the physics engine to do work at the wrong time.

A grid that gives the player room to breathe

A house brought a different kind of difficulty. A grid helps floors join cleanly, walls meet at corners, stairs find an edge, and roofs understand a room. But a rigid grid can make a builder feel like they are negotiating with a spreadsheet. The current house kit has Full and Half variants for floors, walls, rails, stairs, and other structural parts.

The rule that changed the feel

Early auto-fit behavior was technically clever and emotionally wrong: a Full piece could silently become Half just because the cursor crossed a convenient alignment. The preview would shuffle in half-steps and a drag stroke could change its mind underneath the player. The rule is now simple: a manually preferred size wins whenever a valid alignment exists. The system considers a smaller sibling only when every legal placement for the preferred piece has failed, and an “AUTO NOW” cue makes that temporary substitution visible.

That rule carries through the awkward cases: exposed edges, odd one-metre extensions left by half floors, cardinal wall facing, stair direction, and paint-like drag strokes. It is the kind of detail players may never name, but they will feel immediately when a house stops fighting their intention.

Plan the house before it exists

The system now distinguishes a staged blueprint from a constructed structure. Floors, boundaries, and roofs can be considered together as one construction transaction, so the game can validate the whole intent before the house commits. This makes larger actions possible without pretending that the player is placing each board in isolation.

This is the live editor preview used to tune the blueprint look. It stages the same authored house pieces and drives the same hologram code used by build mode.

A roof should be a decision, not a surprise

One of the biggest revisions came from roofs. An earlier prototype generated a roof automatically as soon as a room became enclosed. That was useful for proving the topology, but it made one of a house’s clearest visual choices feel like an accidental side effect. The current prototype makes roofs player-placed, room-level blueprints. It recognizes rectangular enclosed regions, can combine compatible partitioned rooms, and offers Hip and Gable profiles.

Built roofs are intentionally stable. Extending a finished house produces a new roof beside the old one rather than quietly swallowing and rebuilding what the player already committed. It is a small expression of a broader principle: player-made history should not disappear because the helper system found a more elegant shape.

Construction needs a body

Kali’s fiction calls Habi the trained act of gathering ambient spiritual strands and weaving them into an effect. That language gave construction a better answer than a menu confirmation. In build mode, the character reaches toward the target through a Hibla thread—the discrete strand being drawn and shaped. When a transaction is constructed, a single Habi weave plays across the whole result: floors settle first, then walls, roofs, and other vertical pieces cohere upward.

The effect is presentation, not a delayed simulation. The structural result, collision, support logic, and safety checks resolve deterministically; the weave makes that result legible. Keeping those responsibilities separate lets the construction feel ceremonial without making the system unreliable.

The blueprint is part of the system, too

The newest work is the blueprint hologram itself. A flat tint could say “valid” or “invalid,” but it could not explain a house: a floor, wall, rail, stair, support, and roof all need to remain distinguishable over sand, grass, water, and one another. The hologram therefore uses separate family tones, translucent fills, near-opaque lattice lines exactly where parts snap, surface creases, and the authored roof detail carried into the ghost.

Just as important, it is tuneable in one place. A shared BlueprintStyle resource feeds both the runtime and an @tool editor preview, so a visual adjustment is seen against the real house kit rather than copied into a separate mockup that can drift. This pass is still in progress, which is precisely why that shared preview matters.

Where the prototype stands

• Current: terrain-aware previews, snapping, a compact house toolbar, staged construction, walls and openings, rails, stairs, player-placed Hip/Gable roofs, construction weaving, and the shared hologram-preview workflow.

• Still prototype work: placement is free and session-only. Costs, inventory, saving, settlement progression, and the wider community loop are not yet the finished game.

What the fence taught us

The most useful lesson has been to treat every convenience as a promise. Auto-fit should explain itself. A roof helper should preserve authorship. A preview should tell the truth about the final shape. And a construction effect should make the world change feel meaningful without being allowed to decide the world’s rules.

There is still a long way to go before this becomes Kali’s full settlement-building loop. But the foundation is no longer “place an object.” It is a way for the player to begin turning an empty place into a home worth protecting.