From 730cd3bdf32637a9204cbeffc836addd561aa758 Mon Sep 17 00:00:00 2001 From: Malte Langkabel Date: Thu, 2 Jul 2026 21:40:38 +0200 Subject: [PATCH] refinement --- docs/progression_design.md | 60 +++++++++++++++++++++++++++++++++----- 1 file changed, 52 insertions(+), 8 deletions(-) diff --git a/docs/progression_design.md b/docs/progression_design.md index 4674bfa..e528996 100644 --- a/docs/progression_design.md +++ b/docs/progression_design.md @@ -46,11 +46,16 @@ adapts later (see Refactorability). ### Structure -- **One new base input chain per phase.** Factory complexity ramps - alongside ship size; no phase adds more than one new bottom-level chain. +- **Each phase transition adds exactly one new base input chain.** A base + input is a bottom-level resource entering the factory from outside — a + mined ore or the scrap-only input. The early game starts with two ores + as the baseline; the transition to mid adds one (the third ore), the + transition to late adds one (the scrap-only input). No transition ever + introduces more than one unfamiliar bottom-level chain, so the factory + grows in one direction at a time. - **Intermediates are generic shared parts.** Keep the item count low — - modules and hulls of a tier draw from a shared pool of that tier's - intermediates rather than each having bespoke inputs. + modules and hulls of a tier draw from a shared pool of that tier's and + lower tiers' intermediates rather than each having bespoke inputs. - **Thematic naming over thematic items.** Inputs should be plausible for what the recipe produces (crystals for lasers, heat sinks for bigger lasers). Achieve this through naming and chain membership, not by adding @@ -77,6 +82,12 @@ adapts later (see Refactorability). nice ratios for a chain whose base path is strange. - **Not every strange chain gets a shortcut.** Some strangeness is permanent; the absence of a fix is a valid design choice. +- **Shortcuts drop only for known chains.** A shortcut recipe enters the + drop pool only when both its input items and its output item are + already unlocked (in addition to the station level check). The player + is never offered a shortcut for a chain they have not built yet. The + output-item half of this check already exists in + REQ-DEF-SCHEMATIC-DROP; the input half is new (see Action items). - **Shortcuts are pure rewards, never balance factors.** An item's threat value is the *maximum* across its producing recipes (REQ-THREAT-ITEM), so unlocking a cheaper recipe does not lower the item's threat accounting — @@ -88,8 +99,15 @@ adapts later (see Refactorability). ### Refactorability - **Rule (the property):** unlocking the next tier or size of a thing must - be an *extension* of the existing production line — adding assemblers and - belts to what is already built — never a teardown and rebuild. + be a *local edit* of the existing production line — adding assemblers + and belts, or replacing a machine or two in place — never a rebuild of + the line. +- **What this buys the player:** foresight pays off in space, not blocks. + An experienced player leaves a little slack in the middle of a line, + knowing the next size or tier upgrade means tearing out one assembler + and a few belts there and inserting the new step — plus maybe swapping + a recipe or two elsewhere — while the rest of the line keeps running + untouched. - **Default technique:** the bigger version introduces one new intermediate that is produced from a subset of the smaller version's inputs (possibly plus one additional low-tier material), and otherwise reuses the smaller @@ -149,6 +167,13 @@ supporting different fleet doctrines feel structurally different to build. mid-tier hulls/modules/recipes at low station levels, capital content at higher levels. A schematic must not become available before the chains its materials need can be unlocked alongside it. +- **Schematics can require other schematics.** Beyond the station-level + gate, a schematic (ship, module, or assembler recipe) may list + prerequisite schematics that must already be unlocked before it enters + the drop pool — e.g. the medium laser requires the small laser; a + future Mk2 requires its base version. Station level gates the earliest + *when*; prerequisites gate the *order*, keeping drop offers coherent + with what the player already owns. - **No duplicate drops.** Ship and module schematics leave the drop pool once owned, exactly as assembler recipe schematics already do. There are no schematic level-ups; player power grows through unlock breadth and @@ -184,8 +209,16 @@ supporting different fleet doctrines feel structurally different to build. `1 / scrap_per_threat`. The min-`scrap_drop` schematic derivation (REQ-THREAT-SCRAP) and its potential circularity disappear. - **Rule:** the late-game input's income rate meaningfully gates capital - production. The tuning target is expressed as "capital ships per boss - cycle for a player who fights at parity", not as an absolute rate. + production — unlocking a capital hull must not mean spamming it; the + input trickles in slowly enough that every capital ship is a noticeable + investment. The tuning target is relative, not absolute: assume a + reference player who destroys and salvages roughly the threat the game + spawns ("fighting at parity"), and tune `scrap_per_threat`, the + reprocessing weights, and capital material costs so that this player + affords roughly N capital ships per boss cycle. An absolute income rate + would be meaningless (income depends entirely on how much the player + fights) and would not self-scale; per boss cycle, the target tracks the + threat rate as it steps up. ## Building block economy @@ -272,3 +305,14 @@ configs: current `world.toml` values still produce the intended difficulty curve (the config reportedly already runs with a flat ship level, so this is likely a review, not a retune). +7. **Gate shortcut-recipe drops on their inputs.** Extend the assembler + recipe schematic pool eligibility in REQ-DEF-SCHEMATIC-DROP: in + addition to the existing station-level and output-item checks, all of + the recipe's input item types must be implicitly unlocked as well. +8. **Schematic prerequisites.** Add an optional prerequisite list to + ship, module, and assembler recipe schematic entries (e.g. + `unlock_requires = ["laser_cannon_s"]`): a schematic enters the drop + pool only when every listed schematic is already unlocked, in addition + to the station-level check. Update REQ-DEF-SCHEMATIC-DROP and + REQ-LOCK-EXPLICIT. This is also the mechanism the future Mk2 design + builds on (`*_mk2` requires the base schematic).