Lots of content

docs/launch-features.md

@@ -0,0 +1,266 @@
+# Season VI launch feature checklist — The Last Hearth
+
+Updated: 2026-11-02. Carried forward from the engine-checkout checklist,
+doc/season-vi-launch-features.md, with standalone-repository links. Status:
+**proposed launch scope, not accepted features**. M0 technical gates and M1/M2/M3
+implementations with automated preflight are complete; M4 technical implementation
+and automated verification are complete. Human M1 repeat/performance, M2
+first-night, M3 two-player, and M4 week-long acceptance remain open. No launch checkbox is
+approved. See [M1](m1-verification.md), [M2](m2-verification.md), and [M3](m3-verification.md) evidence.
+
+The working contract is exact Luanti **5.18.0**, game **0.5.0-m4**, save schema
+**1**, native-first Windows/Linux intended development, macOS portable runner
+unverified; browser launch readiness is not promised. User-directed M2/M3
+implementation does not waive earlier human acceptance gates. The
+[provisional hardware/network targets](m0-decisions.md#provisional-performance-acceptance-targets--not-measurements)
+are not measurements or certified minimum specifications. The user/operator
+must approve community location before shared climate staging; M0 synthetic 45°N,
+0°E is not production selection.
+
+Initial M1 slices exist for F01 (controller/course), F02 (tool/interact feedback),
+F09 (opt-in practice/sparring), F14 (context/route onboarding), and F15 (generated
+assets/audio). Their launch checkboxes stay open until the full criteria below,
+including human and real-client evaluation, are evidenced.
+
+## The launch promise
+
+**An enjoyable first evening, a home worth improving, and a reason to return.**
+
+Players should gather, prepare, build, and survive through decisions rather than
+repetitive clicking or opaque recipes. Real-world days and seasons shape those
+decisions. Cooperative settlement life provides the initial long-term purpose;
+scripted adventures are not required.
+
+The [prototype](../README.md) establishes plumbing and a small
+interaction loop, not a finished survival game. Existing unit and engine tests
+do not establish that it is fun, secure for public hosting, or performant at scale.
+See the [implementation roadmap](roadmap.md) for ordering and gates.
+
+## Priority and completion rules
+
+- **Required:** blocks the public Season VI launch.
+- **Conditional:** decide at the stated milestone; do not silently grow the scope.
+- **Later:** explicitly outside the launch requirement.
+
+Every required feature needs automated tests where appropriate, a documented
+save-data contract, player-facing feedback, and a multiplayer playtest. A checkbox
+stays open until its acceptance criteria are demonstrated, not merely coded.
+All entries remain unchecked, including replacements for existing prototype behavior.
+
+## Required gameplay features
+
+### F01 — Responsive movement and camera
+- [ ] Predictable walking, sprinting, jumping, stepping, slopes and swimming;
+  smooth speed transitions rather than stamina-threshold oscillation.
+- [ ] Surface-aware footfalls, landing feedback, readable exertion, and settings
+  for camera motion/FOV. Avoid forced head bob or camera shake.
+- [ ] A test course covering narrow doors, stairs, water edges, rough ground,
+  low ceilings, falling, and ordinary network latency.
+**Acceptance:** no reproducible collision traps on the course; movement remains
+pleasant without upgrades, at supported frame rates and the chosen latency envelope.
+
+### F02 — Satisfying tools and physical interactions
+- [ ] Recognizable held tools and first-person use feedback; distinct cutting,
+  chopping, digging, harvesting, placing and repair actions.
+- [ ] Sensible reach, durability, material requirements, yields and pickup behavior.
+- [ ] Context prompts and clear reasons when an action is impossible.
+**Acceptance:** gathering and building feel substantially different from punching
+untextured cubes; players understand tool choice without reading source code.
+
+### F03 — Discoverable crafting and process progression
+- [ ] Searchable recipe/process guide with ingredient sources, workstation needs,
+  quantities, alternatives and locked/unavailable explanations.
+- [ ] A small complete progression: improvised tools → timber shelter/workbench →
+  fired pottery and storage → one useful early metalworking tier.
+- [ ] Functional workstations, timed processing and repair/replacement routes.
+  Processing permits other activities instead of holding a button for minutes.
+**Acceptance:** the first tool, meal, shelter and later production upgrade can
+all be achieved without administrator help or a wiki; no circular recipe locks.
+
+### F04 — Construction that creates useful homes
+- [ ] A coherent palette: foundations, timber frames, walls, floors, roofs,
+  stairs, doors, windows and a simple chimney/vent.
+- [ ] Placement preview, rotation, support feedback, recoverable mistakes and repair.
+- [ ] Bounded support rules applied consistently to structural pieces, including
+  removal of supports. Choose refusal or controlled local failure, not arbitrary
+  survival of floating roofs or unbounded collapse cascades.
+**Acceptance:** a small home is attractive, usable and realistically supported;
+  dirt, planks or decorative nodes cannot accidentally bypass the stated rules.
+
+### F05 — Reliable shelter, heat and weather protection
+- [ ] Replace four-ray enclosure with a bounded room/roof model that recognizes
+  doors, openings, material protection and ventilation.
+- [ ] Explain heat, wetness, wind/rain exposure and drying through useful feedback.
+- [ ] Predictable hearth heating and smoke risk; no damage through solid barriers
+  or unexplained penalties for a properly vented room.
+**Acceptance:** exposed camp, roof-only lean-to and enclosed vented cabin have
+  different, understandable outcomes; performance remains bounded in a large house.
+
+### F06 — Fire, lighting and cooking
+- [ ] Fire-starting tools, tinder, fuel types, ignition feedback and clear burn time.
+- [ ] Timed cooking/boiling with safe input/output handling and a visible process.
+- [ ] Craftable torches or lamps so real-world nighttime is viable immediately.
+- [ ] A deliberate initial fire policy: no uncontrolled spread across claims;
+  remove and refuel operations cannot duplicate resources.
+**Acceptance:** lighting a first fire is satisfying, darkness is navigable, and
+  leaving/rejoining cannot refresh fuel or duplicate cooked output.
+
+### F07 — Food, water and a sustainable resource loop
+- [ ] Renewable forage, freshwater collection, and a few crops with seasonal behavior.
+- [ ] At least two viable food strategies, including one that does not require combat.
+- [ ] Useful cooking and preservation; simple pantry/storage benefits.
+- [ ] Resource renewal rules for plants, timber and arrival-area depletion.
+**Acceptance:** an established village remains viable without endlessly migrating
+  for berries; late joiners are not stranded by earlier harvesting.
+
+### F08 — Needs, clothing, recovery and fair consequences
+- [ ] Tune hunger/thirst/warmth/stamina as interacting systems, not simultaneous chores.
+- [ ] A small functional clothing set with wetness, warmth and wear; rest/bedrolls
+  support recovery without skipping the shared world clock.
+- [ ] Basic treatment and clear injury feedback; remove prototype death-as-free-refill.
+- [ ] Pick a recoverable death policy, safe home respawn and fallback arrival,
+  with item protection/recovery and no unavoidable repeated deaths.
+**Acceptance:** preparation changes survival outcomes; mistakes hurt without
+  routinely ending a player's participation. Initial launch does not require permadeath.
+
+### F09 — Real combat and a small living world
+- [ ] Replace the stationary target as the main demonstration with a moving opponent.
+- [ ] Readable anticipation, contact and recovery; weapon reach, aim, defense,
+  stamina and positioning matter. Add audiovisual hit/miss feedback.
+- [ ] A small wildlife set: a passive/foraging animal and one dangerous encounter,
+  with navigation, avoidance, bounded population and clear disengagement behavior.
+- [ ] Server-side validation of attacks/resources, including reach, obstruction,
+  timing and plausible movement; test prediction/correction under latency.
+**Acceptance:** one encounter is exciting repeatedly and has counterplay other
+  than repeated clicking or permanent stun lock. PvP remains off for initial launch.
+
+### F10 — An interesting, fair starting world
+- [ ] Distinct local terrain, vegetation and material distributions that reward
+  ordinary exploration without needing authored dungeons.
+- [ ] Test arrival-area resources across many seeds, not only the fixed demo seed.
+- [ ] Safe asynchronous arrival and revalidation of saved spawn/home locations.
+- [ ] Remove the prototype's blanket teleport below Y=-100; distinguish actual
+  out-of-world recovery from legitimate underground travel.
+**Acceptance:** valid starts provide a feasible path to water, tools, food and
+  shelter; emergence failures and modified spawn terrain do not trap players.
+
+## Required calendar and persistence features
+
+### F11 — Trustworthy real-world calendar and climate
+- [ ] Player-selected approximate location for local worlds; explicit shared
+  community location for a dedicated server, with no silent production fallback.
+- [ ] One real hour per world hour, correct hemisphere/day length and a documented
+  sky approximation or tested custom rendering improvement.
+- [ ] Configured civil timezone display with UTC available; DST changes labels,
+  not elapsed time. Clearly distinguish solar time, clock time and season labels.
+- [ ] Continuous seasonal temperature/weather with altitude effects and readable
+  forecasts/signs; avoid abrupt rerolled six-hour fronts.
+- [ ] Test seasonal extremes, leap days, clock corrections and restarts using
+  isolated staging fixtures unavailable to ordinary production players.
+**Acceptance:** a same-date restart preserves conditions, nighttime play is fun,
+  and players can survive the actual launch season rather than a hidden spring fixture.
+
+### F12 — Explicit offline and unloaded-area simulation
+- [ ] Publish per-system rules: absent players' needs pause; food/crops/fuel use
+  bounded, consistent elapsed-time accounting independent of loaded mapblocks.
+- [ ] Preserve age through splitting, merging, transfers and logout; conservation
+  tests cover crafting, storage and process completion.
+- [ ] Preservation/storage makes occasional attendance viable before severe decay
+  is enabled. No surprise irreversible backlog simulation after long downtime.
+- [ ] Versioned save schemas, validated inputs, backups before migration, and
+  restart-safe process completion without duplicated output.
+**Acceptance:** identical elapsed time produces equivalent outcomes in loaded and
+  unloaded areas; a week away does not kill a character or silently reset progress.
+
+## Required community and presentation features
+
+### F13 — Shared homes, storage and cooperative permissions
+- [ ] Protected containers and workstations; explicit shared access and claim roles.
+- [ ] Visible claim boundaries and understandable build/access denial.
+- [ ] Protection across harvesting, fluid changes, construction failure, fire,
+  containers and combat—not just placement and digging callbacks.
+**Acceptance:** two players can run a household together while an unauthorized
+  player cannot take its contents or indirectly destroy it.
+
+### F14 — Onboarding and usable survival interface
+- [ ] Short optional hands-on introduction, contextual help and craft discovery.
+- [ ] Useful item icons, inventory sorting/transfers, stack feedback and hotbar flows.
+- [ ] Needs explain causes/remedies, not only bars; scalable UI, readable contrast,
+  remappable controls and non-color-only warnings.
+- [ ] Late-winter arrival and reconnect flows; pause needs during protected initial
+  setup where appropriate, without an exploitable permanent survival shield.
+**Acceptance:** unfamiliar testers complete a first meal/tool/shelter route without
+  coaching. Suggested first-session budget: 30–60 minutes, adjusted after observation.
+
+### F15 — Cohesive visual and sound identity
+- [ ] Original or properly licensed terrain, tools, plants, character model and
+  movement/use animations; consistent scale and recognizable silhouettes.
+- [ ] Positional material sounds, fire, water, weather, wildlife and combat feedback.
+- [ ] Restrained original music with independent volume/accessibility controls.
+**Acceptance:** a short gameplay clip looks and sounds like one authored game;
+  critical actions are not silent and feedback is not audio-only.
+
+### F16 — A simple eom.dev entrance and social connection
+- [ ] A clear Play page: premise, screenshots, supported clients, join instructions,
+  rules, privacy notice and troubleshooting; no misleading universal-browser claim.
+- [ ] Account-linking path to platform identity, with control proven on both sides,
+  no username/email-only merges, and recovery/unlink policy.
+- [ ] Optional Matrix bridge with public-chat disclosure, moderation/rate limits,
+  loop prevention and graceful failure; Discourse season thread and feedback links.
+**Acceptance:** a new visitor knows how to join; external service failure cannot
+  stall gameplay or grant game privileges. No paid survival advantages.
+
+## Required release engineering
+
+### F17 — Reproducible client/game releases
+- [ ] Stable game packaging outside the engine source lifecycle; pinned engine,
+  game, dependencies, assets, license manifest and versioned client contract.
+- [ ] Repeatable install/update flow on supported systems and clean-machine testing.
+- [ ] Decide native-first versus browser-at-launch early. If browser is advertised,
+  test actual hardware/input/JSPI constraints, security headers and proxy isolation.
+**Acceptance:** a clean machine can install and join the exact tested release;
+  incompatible clients get clear errors instead of corrupt gameplay.
+
+### F18 — Safe dedicated-server operation
+- [ ] Staging and production isolation, persistent storage, graceful saves,
+  health/readiness checks, resource limits and protected configuration/secrets.
+- [ ] Consistent backups and demonstrated full restoration of map, players, claims,
+  inventories and process state; an actual rollback procedure.
+- [ ] Moderation/reporting tools, access/rate limits, dependency review and
+  production defaults that disable test/debug powers.
+- [ ] Operational dashboards/logging without credentials or precise player-location
+  leakage; published maintenance and incident expectations.
+**Acceptance:** host a closed community beta safely and recover it from a deliberately
+  simulated failure before production launch. Existing server role is not assumed ready.
+
+### F19 — Performance, exploit and retention validation
+- [ ] Functional, conservation, migration and restart tests; real clients in
+  multiplayer, not only fake-engine unit harnesses.
+- [ ] Measure frame times, server step latency, corrections, memory, media transfer,
+  entity counts and unloaded catch-up cost against declared hardware/player targets.
+- [ ] Test reach/cadence abuse, inventory duplication, claim bypass, clock changes,
+  disconnect/reconnect, full storage, and prolonged process interruptions.
+- [ ] First-night, next-session and week-away playtests; record where people stop
+  enjoying themselves. Use opt-in feedback and minimal aggregate metrics.
+**Acceptance:** no unresolved critical loss/duplication/security defect; returning
+  testers choose a self-directed next goal rather than only following instructions.
+
+## Conditional features: decide, do not accumulate
+
+| Feature | Decision point | Default if not justified |
+| --- | --- | --- |
+| Custom movement/combat engine fork | First feel prototype (M1) | Use stock engine only if it meets the feel target; otherwise fund a bounded fork spike, not a silent quality cut. |
+| Exact latitude-aware sky orbit | Clock validation (M2) | A disclosed, validated approximation is acceptable; keep real calendar/day length. |
+| Browser client at public launch | Platform contract (M0), proof in M1 | Native-first, with an honest supported-client list. Browser becomes required if promoted as launch-ready. |
+| Dynamic local collapse | Building prototype (M3) | Refuse unsafe support removal with clear feedback; no global physics simulation. |
+| Detailed nutrition, illness and tool-specific injuries | Survival playtests (M3/M4) | A small understandable needs/treatment model. |
+
+## Explicitly after launch
+
+Vehicles/moving cities, elaborate metallurgy beyond the first useful tier,
+authored ruins/dungeons, supernatural threats, AI residents, unrestricted PvP,
+faction economies, world-restoration machinery, complex breeding/ecosystems,
+shared currencies with other services, and automatic scheduled world wipes.
+
+No feature count makes the season ready by itself. The test is whether the
+survival/building loop is enjoyable, understandable and reliable with real people.