loot-and-logic documentation
Choose a version
Version Other / archived
Loot & Logic prototype research #
Loot & Logic reached its current direction through small experiments that answered one risk at a time. This page records the technical and playtest evidence that produced the continue decision and the current engine reassessment. It describes history and evidence, not builds that are distributed today.
Technical spike #
The first spike asked whether a lightweight browser implementation could support the intended world structure without prematurely adopting a desktop shell, Rust/WASM, a rendering framework, or networking library.
The spike demonstrated:
- deterministic chunk generation from a seed, coordinates, and generator version;
- a limited active area around the player;
- separation between generated overworld terrain and authored rooms;
- returning from a room to the exact entrance used;
- serializable commands applied to authoritative state; and
- versioned save data with generated terrain separated from player changes.
An early performance problem initially made the browser approach appear too slow. Profiling found repeated full chunk generation inside per-tile drawing. Generating each visible chunk once reduced the measured Node-side preparation cost by roughly 107×. The conclusion was to remain browser-first until measured requirements justified another platform — which the later desktop-harness review reopened.
Integrated MVP #
The MVP connected the isolated experiments into one playable session:
base → generated overworld → first room → return to base
→ produce a tool → second room → return and complete
Automated tests verified phase ordering, world transitions, exact entrance returns, resource transfer, production, tool use, input mapping, and session completion. They established that the systems connected correctly; they could not show whether the game was understandable or enjoyable.
The MVP used placeholder, code-generated visuals. Menus, remappable keyboard controls, objective guidance, persistent inventory display, and a walkable base existed to support testing rather than represent final UI or art.
Round 1 playtest #
The first observed child session on 14 August 2026 produced a continue decision. Initially, the prototype read as one basic Minecraft-like tile game. After the base, overworld, and room roles were explained, the combined concept became clear and received positive feedback.
That result supported another iteration while identifying the immediate risk: the game did not yet communicate its structure independently.
Architecture foundations #
Before a production client was chosen, the project built the durable systems a restarted engine would not throw away:
- an authoritative host with versioned command, snapshot, and delta protocol;
- checksummed world saves with migrations, backup recovery, and exact room returns;
- spatial, placeable automation with conserved resource flow and an authoritative production clock;
- data-authored stealth rooms with guard perception, failure, and tool-driven choices; and
- durable multiplayer-session foundations: persisted credentials, replication, heartbeat disconnects, and owned expeditions.
Each was validated through automated and packaged journeys. A full JavaScript suite of 106 tests covers the MVP/prototype, architecture, desktop-harness, and production code.
Engine reassessment #
The web desktop harnesses did not preserve MVP parity: the Tauri client had no
generated Wilds stage, and both Tauri and Electron reduced exploration to a
corridor. The engine decision was reopened, and a native Godot client proved
the thin base → Wilds → Ore Vault → exact return → base journey plus durable
local resume on 2 September 2026. See client and engine
for the boundary and the roadmap for what the proof must still
pass.
Deliberately unresolved #
Final art direction, content volume, production engine commitment, the 3D Wilds decision, cooperative rules, long-session retention, accessibility coverage, and packaging budgets remain open. Those decisions are being driven by a packaged, keyboard-playable build rather than inferred from the browser MVP.