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