last-hearth/docs/launch-features.md

# 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.