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, M2, and M3 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 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 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 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.