UnrealPrototyping/Docs/Ideas.md

Ideas

The two earlier projects, Adventurer Guild and Project Malleable, each designed a whole game around a core loop. This project keeps neither loop. It keeps the ideas, reshaped as features a world could hold rather than as the thing the game is about, and it keeps them here rather than in the specs so that none of them can be smuggled into a step as if it were already decided.

Each entry says what the idea is, which mechanism is worth keeping, what it would need, and what it must not break. "Adopted" means the idea already lives in a spec. Nothing here is scheduled.

From Adventurer Guild

Contracts and the board

Take a parchment off a wall, go and do it, come back and have it stamped. The mechanism worth keeping is the stamp: a ritual at the end of a job where the value is counted out in front of everyone, which is a better stopping point than a results screen because it gives a group a shared moment. Contracts as data (a target, a count, a reward, a standing requirement) and progress reported through one funnel from combat kills and item deliveries. Needs: a place to put the board, a reason to want the reward. Must not: replace playing with fetching; a contract is a reason to go somewhere, not the game.

The cart

A physical, pushable container that carries the haul out. Tips, spills a fraction, gets righted. Pushed from the handles by taking them (an interaction), which routes movement input into the cart. The mechanism worth keeping is hauling as a physical problem: what you bring back is what fits and what you managed not to lose. Needs: somewhere to haul from and to; the physics of a pushed body on a server. Must not: be the only way to carry things; hands and (later) containers come first.

Grief verbs and the recoverability contract

Shove, take from the cart, heal-launch, tip the cart. Adopted as a rule in Combat.md: any verb that lets one player inconvenience another must have a recovery that takes less time than the verb did, and none may down, kill or permanently deprive. Every such verb emits grief_action. The verbs themselves arrive with the systems they act on.

Down, revive, bleed-out, wipe

Adopted whole in Combat.md.

Seeded generation

A dungeon generated from a seed on every peer, byte-identical, so the server replicates eight bytes instead of megabytes. The determinism rules (own random stream, integer grid, ordered collections, no physics, no time), a critical path the cart can traverse, side branches that split the party, a shortcut door that only opens from the deep side, rooms as one-cell tiles in folders, typed spawn anchors with always/chance/budget rules, weighted pools, and an append-only pass that guarantees a contract's target exists. The mechanism worth keeping is all of it; it is the most worked-through part of the earlier project. Needs: a reason to have instanced places. Must not: assume one instance per server or that generation runs on the client only; both hold in the earlier design and both survive the move.

Party-size scaling

Sublinear enemy budget (1.0, 1.75, 2.4, 3.0) and role relaxation below three players. Adopted as a reserved rule in Combat.md, applied to a count for now.

Reputation, tiers, zones, upgrades

Standing that gates content, tiers that pay more, an upgrade bench where gold buys modifiers that combat pulls by name (GetModifier("cart.capacity")), and the cross-class gear rule. The pull direction is the mechanism: combat asks for its numbers, progression never pushes into combat. The signature guardrail is adopted as the bSignature flag. Needs: a currency, a reason to spend. Must not: become per-body state; it lives on the player.

The hall as hub and lobby

You launch into a place, not a menu. The lobby is a board by the door, readiness is a plinth you stand on, class is a locker with racks, and everyone is physically together before the run. The mechanism is the lobby is a room. Needs: a second map and session travel. Must not: assume a listen server; the room is on the same server the world is.

Steam lobbies and the friends-list join

Every launch hosts a lobby of one; opening it to friends is a physical act; a friend's "join game" carries them in. Needs: a session layer in front of the server. Must not: put a session type inside gameplay code.

Content authoring tools

Weighted pools, typed anchors, a tile template with red doorway volumes and a footprint validator, a project content catalogue feeding dropdowns, and one browser window over every content asset. The engine's data validation and asset manager do half of this natively. Needs: enough content to hunt through. Must not: arrive before the third tileset.

The design system

A palette by role, one label component, one theme, meaning never on hue alone. Adopted in UI.md; the parchment-and-ink look itself is not.

From Project Malleable

Orders as tickets on a rail

A customer hands over a parchment; it hangs on a rail from the desk to the workshop; taking it off is the claim; clipping it to a station shows what that station is working; handing it back with the item is the delivery. The spec on the ticket is explicit (family, required tags, minimum quality) and matched by one pure function that also explains why an item does not match. Five customer tiers as data, archetypes with patience and reactions. The mechanism is demand as a physical object you can pick up, hand over and drop. Needs: a shop, an economy, customers. Must not: be the only source of demand once players are the adventurers.

The economy

Gold only. A payout split 20/40/40 between base, quality and speed against a tier price, clamped so the ceiling belongs to the order and profit is margin. A shared wallet with per-player attribution. A front shop with bid and ask prices, NPC valuation computed independently so player prices cannot mint money, and haggling as a turn-based exchange with a truthful likelihood meter. Needs: everything above it. Must not: introduce a lying surface; every gauge in this project tells the truth and a haggling meter that dramatised would poison the others.

Storage as a place

No shop-wide inventory, no stack counters, no station pulling from a container across the room. Containers with slots, designated floor areas typed by what they hold, reservations per object so two players racing for the last ingot find out at claim time, nothing destroyed by a full container, and a satchel bought later that adds pocket slots (2, 3, 4, 6, 8, 10). The mechanism is hauling is the game, and the substance object model already assumes it. Needs: more things than hands can hold. Must not: add an abstract bank; the object model's cost is only affordable because storage caps the count.

Crafting domains as professions

Five domains mapped one to one to five crafting classes (Forge Worker, Woodworker, Enchanter, Shopkeep, Quartermaster) with speed and quality bonuses that never lock anything. Three domains are adopted as the station gate in Crafting.md. The open question worth a real session: this project has combat kits; are crafting professions a second axis on the same player, a choice against a kit, or folded into kits? Needs: that decision. Must not: gate a station on a class; the rule is bonuses, never locks.

Stations you place, upgrade and pack

Movable stations on a grid, per-station upgrades with a mesh per tier so level reads across the room, fittings as visible sub-upgrades in named sockets, and stations repackaged into a carryable crate rather than sold, so nothing is lost and no gold comes back. Needs: a place that is yours. Must not: put station state on the actor's Blueprint; it is a replicated record.

World events as a modifier service

A standalone service any system asks for its own modifier (GetModifier(PriceBias, tag)), events as assets with scopes and channels, seeded per world, pushable from outside. The mechanism is consumers ask, they never test for an event. Needs: a second system that wants tuning from outside. Must not: be consulted from inside an activity tick.

Travel and the town

The cart as the travel system: sit in it, pick a destination, cut to the scene. A town with a purchase surface and a small bounded warehouse, staged so that a local town cannot smuggle in shared population or a marketplace before the service that hosts them exists. Needs: a second place. Must not: make the warehouse a bank.

Persistence and portable characters

Worlds keep the relationship, characters belong to the player and travel between worlds; ironman days with no rewinds and a mid-day autosave; records as idempotent snapshots with schema versions and recomputed derived fields; a provider interface with a local implementation forever. Adopted as the identity and persistence seams in Networking.md; the day, the world record and the character record are not built.

The service posture

Dedicated servers, a validation layer behind the simulation, three responsiveness tiers, ask-then-show, no rollback of visible world state, lag compensation only where timing is scored, and an incident doctrine (detect, contain with a modifier push, trace by object id, remediate surgically, restore last). Adopted as posture in Networking.md and Telemetry.md. The layers themselves are not built and nothing in gameplay code would change when they are.

Adventure contracts, turned inside out

Malleable sent NPC parties out with your gear to bring rare substances back. Here the players are the party. The loop that closes when the three feels exist: craft a weapon, fight with it, bring back what only fighting finds, craft something better. Rare substances as drops and finds with provenance already in the data model (Provenance.Found, SourceObjectIds). This is the most likely next step after fifteen and it is deliberately not written as one.

Discovery at scale, alloys, deciphering

Generated glyphs discovered like skill unlocks (with the constraint that the composition path never changes and any seed is global), a kiln that alloys two raw types (with the constraint that nobody hard-codes one-to-one processing), and customer requests as rough descriptions to interpret rather than specs to read. Each is its own session. Must not: happen by accident in a step about something else.