System Requirements Document for misty-hey

1. Introduction

misty-hey is a playable voxel sandbox game built as a 1-1 clone of Minecraft. The product intent, taken directly from the authoritative requirement thread, is threefold and non-negotiable:

1. Deliver a playable voxel sandbox game — a world the player enters, moves through, and manipulates.
2. Make it look exactly like Minecraft — the blocky pixel terrain, the 16×16 hand-drawn texture atlas, the first-person camera, the survival HUD, the hotbar, the inventory and crafting grid.
3. Include all of Minecraft's mechanics — the full survival and sandbox loop: mining, placing, crafting, health, hunger, experience, day/night, mobs, water and lava, and the rest of the game's systems.

The audience is gaming-native players who already know Minecraft's textures, HUD, hotbar, and inventory, and who expect fidelity rather than a reinterpretation. The emotional register is playful, tactile, toy-like, and nostalgic: this is not an enterprise tool, it is a world you enter and manipulate.

2. System Overview

misty-hey is delivered as a browser-playable voxel game with a custom first-party UI. The current delivery consists of two application-owned surfaces:

• Landing — the anonymous public entry surface. It presents the game and its Minecraft-like gameplay, and it is the point from which play begins.
• Game — the cohesive gameplay workspace where the player enters the voxel world, mines and places blocks, crafts, and uses survival mechanics.

The single active human actor is the Player. There are no other accepted human personas. The game world itself, its terrain generation, mobs, physics, and simulation are system processes that support the player's interaction but are not human actors.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. Both accepted surfaces are owned by the application and are reachable without an account. The source establishes no account, login, profile, or identity requirement, and none is indispensable: the accepted journeys are a single-player sandbox experience where the player's world state lives in the game session and the local world, not behind a private account boundary. Access to both Landing and Game is therefore anonymous and open, exactly as the page contract states.

Current boundary. The current product is the playable game itself: the voxel world, its visual fidelity to Minecraft, and its mechanics. Everything the player does — entering the world, mining, placing, crafting, surviving — happens inside the two accepted surfaces.

Future boundary. No future-horizon requirements were stated in the authoritative thread. Anything not named in the accepted requirements (multiplayer servers, account systems, marketplaces, mod distribution, or other adjacent platform capabilities) is out of scope for the current generation and is not implemented.

2c. Page Content and Component Coverage

Landing

• Information and state. The first screen is a full-bleed 3D voxel diorama: a small floating island with a grass top, dirt sides, a single oak tree, a water pool, and a pig standing on the edge. The camera slowly orbits the island at a 15-degree downward angle. The title MISTY HEY is rendered in Silkscreen, 64px on mobile to 128px on desktop, bottom-left, in white with a 2px dark drop-shadow, sitting over the sky. A version tag v1.0 — seed 42069 sits bottom-centre in VT323 12px. The scene is the content; there are no feature cards, no pricing, no testimonials.
• Primary action. A PLAY button — flat green #5B8731 with a 2px inset border — sits bottom-right. Activating it begins play and transitions into the Game surface.
• Supporting actions. None beyond entering play. The orbiting diorama is itself clickable: clicking the scene dives the camera into first-person and fades in the HUD, entering the Game surface.
• Domain entities. Voxel island (grass, dirt, oak tree, water pool), pig mob, skybox gradient, blocky sun and moon, flat white voxel cloud planes.
• Component responsibilities. Full-viewport WebGL canvas hosting the live orbiting diorama; absolutely positioned title block (bottom-left); PLAY control (bottom-right); version/seed footer (bottom-centre); skybox renderer; procedural terrain and mob renderer.
• States.
  • Loading: the WebGL scene initializes; the canvas shows the sky gradient while the diorama and texture atlas load.
  • Empty: not applicable — the diorama is always present as the hero subject.
  • Success: the diorama orbits smoothly, the title and PLAY control are fully readable and inside the viewport at 375px, 768px, and 1280px, and activating PLAY enters the Game surface.

• Error: if WebGL is unavailable or the scene fails to initialize, the title, version tag, and PLAY control remain readable and the player is still offered a path into the Game surface.
• Recovery: the scene re-initializes on reload; the entry path to play is never blocked by a failed hero render.

Game

• Information and state. The full-viewport 3D voxel world in first-person, with the Minecraft HUD absolutely positioned over it: a 9-slot hotbar bottom-centre with 2px inset borders, 10 red hearts (#FF5555) above it, 10 hunger drumsticks (#FFAA00), a hot pink (#FF55FF) XP bar that fills as the player mines, a pixel-perfect crosshair (a 2px white plus sign with a 1px black outline) dead-centre at all times, a minimap top-right, and a chat box bottom-left in VT323 14px with a dark translucent background. The inventory screen is a full-screen modal with a 9×3 grid of 40×40px slots, each with a 2px inset border, and a 3×3 crafting grid to the right that snaps items into place with a click.
• Primary actions. Move and look in first-person; break blocks; place blocks; select hotbar slots; open the inventory; craft items in the crafting grid; consume food; fight or avoid mobs; survive.
• Supporting actions. Read chat and system messages (e.g. MistyHey joined the game in white, player messages in yellow); read health, hunger, and XP state; read the minimap; manage inventory contents.
• Domain entities. Voxel terrain (grass #5B8731, dirt #8B5A2B, stone #7A7A7A, water and sky #79A6FF), the 16×16 texture atlas, blocks and items, the player's inventory and hotbar, the crafting grid and its recipes, health, hunger, experience and level, mobs (including the pig), day/night cycle, water and lava, block-break particles, and the chat log.
• Component responsibilities. WebGL world renderer with first-person camera; chunk/terrain generation and meshing; block interaction (raycast target, break, place); physics and collision; mob simulation and idle animation; HUD layer (hotbar, health, hunger, XP, crosshair, minimap, chat); inventory modal with 9×3 slot grid and 3×3 crafting grid; item and block icon rendering from the atlas; particle system for block-break spray in 8 directions.
• States.

• Loading: the world generates and chunks mesh; the HUD appears as the world becomes playable.
• Empty: an empty inventory and empty hotbar slots render as flat bordered slots with no item icon; an empty chat shows only the join message.
• Success: the player moves, breaks and places blocks with snap and particle feedback, crafts in the grid, and sees health, hunger, and XP update in the HUD.
• Error: if the world fails to generate or the renderer stalls, the player is returned to a recoverable state rather than a frozen view.
• Recovery: the player can reload and re-enter the world; world state persists for the session so play continues from where it left off.

3. Functional Requirements

FR-1 — Playable voxel sandbox game (explicit) As a Player, I should enter and play a voxel sandbox game, so that I can explore and manipulate a block world.

• Trigger/input: the player activates PLAY on Landing, or clicks the orbiting diorama.
• Observable result: the camera dives into first-person and the HUD fades in over a live voxel world.
• Access state: anonymous; no account required.
• Failure/recovery: if the world fails to initialize, the player can reload and re-enter.
• Continuation: the player is in the Game surface and can move, mine, and place.

FR-2 — Visual fidelity to Minecraft (explicit) As a Player, I should see a world that looks exactly like Minecraft, so that the experience matches the game I already know.

• Trigger/input: entering the Game surface and viewing the world and HUD.
• Observable result: blocky pixel terrain rendered from a 16×16 texture atlas on cube faces; a skybox gradient from #79A6FF to #B3D9FF with a blocky sun and moon; flat white voxel cloud planes; a first-person camera; and a HUD matching Minecraft's layout and styling.
• Access state: anonymous.
• Failure/recovery: if the texture atlas fails to load, the world still renders and the player can continue.
• Continuation: the player continues playing in the faithful visual presentation.

FR-3 — All of Minecraft's mechanics (explicit) As a Player, I should use the full set of Minecraft's mechanics, so that the clone is a true 1-1 experience.

• Trigger/input: the player's actions in the world — mining, placing, crafting, eating, fighting, and surviving.
• Observable result: the corresponding mechanic responds exactly as in Minecraft: blocks break and drop, blocks place and snap, recipes resolve in the crafting grid, health and hunger deplete and restore, XP fills the hot pink bar, and mobs behave.
• Access state: anonymous.
• Failure/recovery: an invalid action (e.g. an unresolvable recipe) leaves state unchanged and the player can try another action.
• Continuation: the player keeps playing with the full mechanic set available.

FR-4 — First-person block-break and block-place loop (explicit) As a Player, I should break and place blocks in first person, so that I can shape the world.

• Trigger/input: aiming the crosshair at a block and using the break or place control.
• Observable result: the targeted block breaks with particles spraying in 8 directions, or the held block places with a snap; the hotbar and inventory update.
• Access state: anonymous.
• Failure/recovery: aiming at nothing or at an out-of-range target produces no change.
• Continuation: the player continues mining and building.

FR-5 — Hotbar and inventory management (explicit) As a Player, I should manage items in a 9-slot hotbar and a 9×3 inventory grid, so that I can carry and select what I use.

• Trigger/input: selecting a hotbar slot, or opening the inventory modal and moving items between slots.
• Observable result: the selected hotbar slot is highlighted; items move between the 9×3 grid and the hotbar; each slot renders as a 40×40px flat slot with a 2px inset border.
• Access state: anonymous.
• Failure/recovery: dropping an item outside a valid slot returns it to its origin.
• Continuation: the player closes the inventory and continues with the updated loadout.

FR-6 — Crafting grid (explicit) As a Player, I should craft items in a 3×3 crafting grid, so that I can turn materials into tools, blocks, and other items.

• Trigger/input: placing items into the 3×3 crafting grid to the right of the inventory.
• Observable result: items snap into place with a click and the matching recipe output appears.
• Access state: anonymous.
• Failure/recovery: a non-matching arrangement produces no output and the ingredients remain in the grid.
• Continuation: the player takes the crafted output and continues.

FR-7 — Survival HUD: health, hunger, and experience (explicit) As a Player, I should see and be affected by health, hunger, and experience, so that survival has stakes and progress is visible.

• Trigger/input: taking damage, eating food, and mining blocks.
• Observable result: 10 red hearts (#FF5555) and 10 hunger drumsticks (#FFAA00) above the hotbar reflect current state, and the hot pink (#FF55FF) XP bar fills as the player mines.
• Access state: anonymous.
• Failure/recovery: at zero health the player's survival state resolves as in Minecraft and play can continue from a recoverable state.
• Continuation: the player manages health and hunger and keeps progressing.

FR-8 — Chat and system messages (explicit) As a Player, I should see chat and system messages, so that I know what is happening in the world.

• Trigger/input: joining the game or a system event.
• Observable result: the chat box bottom-left in VT323 14px with a dark translucent background shows system messages such as MistyHey joined the game in white and player messages in yellow.
• Access state: anonymous.
• Failure/recovery: if no messages exist, the chat box shows only the join message.
• Continuation: the player keeps playing while messages accumulate.

FR-9 — Minimap and world orientation (explicit) As a Player, I should see a minimap, so that I can orient myself in the world.

• Trigger/input: entering the Game surface.
• Observable result: a minimap renders top-right over the world.
• Access state: anonymous.
• Failure/recovery: if the minimap fails to render, the world and HUD remain usable.
• Continuation: the player navigates using the minimap.

FR-10 — Mobs and world simulation (explicit) As a Player, I should encounter mobs and a living world, so that the sandbox behaves like Minecraft.

• Trigger/input: exploring the world over time.
• Observable result: mobs such as the pig appear and animate with idle motion; day/night, water flow, and lava bubbles behave as in Minecraft.
• Access state: anonymous.
• Failure/recovery: if a mob fails to spawn, the world remains playable.
• Continuation: the player continues exploring and interacting.

4. User Personas

Player

Product context. The Player is the single active human actor in misty-hey. They are gaming-native and already know Minecraft's textures, HUD, hotbar, and inventory. They arrive at the Landing surface, see a live orbiting voxel diorama, and expect that clicking into it will put them in a world that behaves and looks like the game they know.

Primary goal. To enter a voxel world and play a 1-1 Minecraft experience — one that looks exactly like Minecraft and includes all of its mechanics.

Distinct accepted responsibilities.

• Entering the world from the Landing surface and beginning first-person play.
• Exploring and manipulating the world by breaking and placing blocks.
• Managing a 9-slot hotbar and a 9×3 inventory grid.
• Crafting items in the 3×3 crafting grid.
• Managing health, hunger, and experience through survival play.
• Reading chat and system messages and orienting with the minimap.
• Encountering and interacting with mobs and the simulated world.

Relevant inputs and decisions. Which block to target and whether to break or place it; which hotbar slot to select; which items to move in the inventory; which recipe to arrange in the crafting grid; when to eat and when to fight or avoid a mob.

Interactions with other accepted participants. The Player is the only accepted human participant. Their counterparties are system processes — terrain generation, mob simulation, physics, and the world's day/night and fluid systems — which respond to the Player's actions and produce the observable results the Player sees.

Observable success. The Player moves through a world that looks exactly like Minecraft, breaks and places blocks with particle and snap feedback, crafts in the grid, sees health, hunger, and XP update in the HUD, and can keep playing without the experience breaking.

5. Core User Flows

Flow 1 — Entering the world and beginning play

1. The Player opens misty-hey and lands on the Landing surface. No account or sign-in is required.
2. The Player sees a full-bleed 3D voxel diorama: a small floating island with a grass top, dirt sides, a single oak tree, a water pool, and a pig standing on the edge, with the camera slowly orbiting at a 15-degree downward angle.
3. The Player reads the title MISTY HEY in Silkscreen, bottom-left, and the version tag v1.0 — seed 42069 bottom-centre.
4. The Player activates the PLAY button bottom-right, or clicks the orbiting diorama itself.
5. The camera dives into first-person and the HUD fades in over the live voxel world, placing the Player in the Game surface.
6. Failure/recovery: if the WebGL scene fails to initialize, the title, version tag, and PLAY control remain readable and the Player is still offered a path into the Game surface; the Player can reload to re-initialize.
7. Continuation: the Player is in the world and can move, mine, and place.

Flow 2 — Mining and placing blocks

1. The Player is in the Game surface in first-person, with the crosshair dead-centre.
2. The Player aims the crosshair at a block in the world.
3. The Player uses the break control. The block breaks and particles spray in 8 directions; the hotbar and inventory update.
4. The Player selects a hotbar slot and uses the place control. The held block places with a snap.
5. Failure/recovery: aiming at nothing or at an out-of-range target produces no change, and the Player can re-aim.
6. Continuation: the Player keeps shaping the world, with the XP bar filling as they mine.

Flow 3 — Managing the hotbar and inventory

1. The Player is in the Game surface with the HUD visible.
2. The Player selects a hotbar slot; the selected slot is highlighted.
3. The Player opens the inventory modal — a full-screen overlay with a 9×3 grid of 40×40px slots, each with a 2px inset border.
4. The Player moves items between the 9×3 grid and the hotbar.
5. Failure/recovery: dropping an item outside a valid slot returns it to its origin.
6. Continuation: the Player closes the inventory and continues with the updated loadout.

Flow 4 — Crafting items

1. The Player opens the inventory modal in the Game surface.
2. The Player places items into the 3×3 crafting grid to the right of the inventory.
3. Items snap into place with a click and the matching recipe output appears.
4. The Player takes the crafted output.
5. Failure/recovery: a non-matching arrangement produces no output and the ingredients remain in the grid, so the Player can rearrange them.
6. Continuation: the Player uses the crafted item and continues playing.

Flow 5 — Surviving: health, hunger, and experience

1. The Player is in the Game surface with 10 red hearts and 10 hunger drumsticks above the hotbar.
2. The Player takes damage or expends hunger through play; the hearts and drumsticks reflect the change.
3. The Player eats food to restore hunger, and mines blocks so the hot pink XP bar fills.
4. Failure/recovery: at zero health the Player's survival state resolves as in Minecraft, and play can continue from a recoverable state.
5. Continuation: the Player manages health and hunger and keeps progressing.

Flow 6 — Reading chat and orienting with the minimap

1. The Player is in the Game surface.
2. The chat box bottom-left, in VT323 14px with a dark translucent background, shows the system message MistyHey joined the game in white; player messages appear in yellow.
3. The minimap renders top-right over the world.
4. Failure/recovery: if the minimap fails to render, the world and HUD remain usable; if no messages exist, the chat box shows only the join message.
5. Continuation: the Player navigates using the minimap and keeps playing while messages accumulate.

Flow 7 — Encountering mobs and the living world

1. The Player explores the Game world over time.
2. Mobs such as the pig appear and animate with idle motion; day/night, water flow, and lava bubbles behave as in Minecraft.
3. The Player interacts with or avoids the mobs.
4. Failure/recovery: if a mob fails to spawn, the world remains playable.
5. Continuation: the Player continues exploring and interacting with the world.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Bruno Simon, whose language is literally "playable worlds": low-poly 3D scenes you explore, toy-like physics, joyful discovery, and a 3D scene as the page itself. The headline idea is that the world IS the hero — the first screen is a live, orbiting 3D voxel island rendered in WebGL, not a screenshot, not a video, an actual playable scene you can click into.

Color tokens (dark mode).

The background is the dark void of the game viewport; UI surfaces are dark grey panels with 1px light borders. Sky blue #79A6FF is reserved for the skybox and water; grass green #5B8731 and dirt brown #8B5A2B are the dominant world colours; stone grey #7A7A7A anchors UI chrome. Health red and hunger orange are used only in the HUD.

Typography. Headings use Silkscreen — all-caps pixel display, 2px blocky rendering, tight letter-spacing — for the game title and HUD labels. Body copy uses VT323, monospace terminal-style at generous size for readability. The scale is a 1.25 modular scale: 64/48/32/24/16/12. HUD labels sit at 12px, menu headings at 32px, and the landing hero title at 64px mobile to 128px desktop.

Shape language. Sharp 90-degree corners everywhere — no border-radius, no soft shadows. Blocks are literal cubes. Buttons are flat rectangles with 2px inset borders (top/left light, bottom/right dark) to mimic Minecraft's own GUI. Panels are dark grey with a 2px lighter border. The hotbar is a row of 40×40px squares, each a flat slot with a 2px border. No rounded corners anywhere except the circular crosshair and the compass.

Layout. A full-viewport 3D canvas is the page. The HUD is absolutely positioned: hotbar bottom-centre, health/hunger above it, crosshair dead-centre, minimap top-right, chat bottom-left. The landing page is a single full-bleed scene with the title block bottom-left, a PLAY button bottom-right, and a version/seed footer bottom-centre. The inventory screen is a modal grid overlay, 9×3 slots, with the crafting grid to the right. No cards, no grid of features — the world is the content.

Imagery. Low-poly voxel terrain generated procedurally — no photography, no illustrations. Every surface is a 16×16 pixel texture atlas rendered on cube faces. The skybox is a gradient from #79A6FF to #B3D9FF with a blocky sun and moon. Clouds are flat white voxel planes. The only "imagery" is the world itself, plus pixel-art mob sprites and item icons drawn from the atlas.

Readable text and controls. Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion follow the creative direction and may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control. With prefers-reduced-motion, a usable static arrangement is provided.

7. Signature Design Concept

The world is the hero. The public entry is not a marketing page — it is a live, orbiting 3D voxel island rendered in WebGL. A small floating island with a grass top, dirt sides, a single oak tree, a water pool, and a pig standing on the edge sits against a skybox gradient from #79A6FF to #B3D9FF, with a blocky sun and moon and flat white voxel cloud planes drifting past. The camera slowly orbits the island at a 15-degree downward angle, so the first thing the Player sees is the game's own visual grammar in motion.

The title MISTY HEY is rendered in Silkscreen, 64px on mobile to 128px on desktop, bottom-left, in white with a 2px dark drop-shadow, sitting over the sky. A PLAY button — flat green #5B8731 with a 2px inset border — sits bottom-right. A version tag v1.0 — seed 42069 sits bottom-centre in VT323 12px. There are no gradient blobs, no centred headline, no blue CTA. The island is clickable: clicking it dives the camera into first-person and fades in the HUD, carrying the Player straight into the Game surface. The concept recomposes only accepted content, states, and controls — it introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: webgl

Landing Hero Motion Brief. The focal subject is the live orbiting voxel island — grass top, dirt sides, a single oak tree, a water pool, and a pig on the edge — rendered in real-time WebGL against the skybox gradient. The input→transformation→outcome thesis: the camera's slow orbit presents the world as a playable object; on click, the camera dives into first-person and the HUD fades in, transforming the orbiting diorama into the world the Player now stands in. The motion vocabulary is physics-driven and playful — block break particles, block place snap, camera head-bob, water flow, lava bubbles, mob idle animations — all frame-based and snappy, never eased with cubic-bezier curves. The composed first frame shows the island centred at a 15-degree downward angle, the title bottom-left, the PLAY button bottom-right, and the version tag bottom-centre, with the sky gradient and voxel clouds behind. The reduced-motion state presents the same island as a still composed frame with the title, PLAY control, and version tag fully readable and inside the viewport, and the entry path into the Game surface intact.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED. The direction's hero dimensionality is webgl, so the hero is a crafted real-time object: a compact voxel diorama — a small floating island with a grass top, dirt sides, a single oak tree, a water pool, and a pig standing on the edge — built from the 16×16 texture atlas on cube faces, lit against a #79A6FF to #B3D9FF skybox with a blocky sun and moon and flat white voxel cloud planes. The scene shows the product's defining state: a Minecraft-like world, live and manipulable, orbiting slowly until the Player clicks into it.

9. Non-Functional Requirements

NFR-1 — Visual fidelity is a hard constraint (explicit) The visual appearance must match Minecraft exactly. This governs the texture atlas, block rendering, skybox, HUD layout and styling, and the overall look of the world. Rationale: the authoritative thread states the clone must look exactly like Minecraft.

NFR-2 — Mechanical completeness is a hard constraint (explicit) Mechanics must cover all of Minecraft's mechanics (1-1 clone). Rationale: the authoritative thread states the clone must include all of Minecraft's mechanics.

NFR-3 — Real-time rendering performance (required_inference) The world and HUD must render in real time at a playable frame rate, since the accepted behaviour is a first-person game with continuous motion, block interaction, and mob animation. Rationale: a playable voxel game is not usable without real-time rendering.

NFR-4 — Readable text and controls at every viewport (explicit) Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, and no other element covers any part of them. Rationale: stated in the creative direction's readability rule.

NFR-5 — Reduced-motion support (explicit) With prefers-reduced-motion, a usable static arrangement is provided so that the hero and any moving content remain usable. Rationale: stated in the creative direction's readability rule.

NFR-6 — Anonymous access (explicit) Both accepted surfaces are reachable without an account. Rationale: the page contract assigns access_requirement: none to both Landing and Game, and no account requirement appears in the authoritative thread.

10. Tech Stack

• Frontend: React with a WebGL renderer for the voxel world and HUD. The creative direction calls for a real-time WebGL hero and a browser-playable game, so the client is a React application rendering the world through WebGL.
• Backend: Python/FastAPI for the application service that supports the game surfaces.
• Storage: appropriate storage for the game's world and session state.
• Deployment: Docker and docker-compose for the runnable services.

No source-specified technology choices conflict with these; the stack is the practical set needed to deliver the accepted behaviour.

11. Assumptions and Constraints

Assumptions.

• The game is a single-player sandbox experience; no multiplayer, account, or server-authoritative identity is required by the accepted requirements.
• The Player's world state persists for the session so play can continue from where it left off.
• The 16×16 texture atlas, skybox gradient, HUD layout, and inventory/crafting grid described in the creative direction are the concrete expression of the "looks exactly like Minecraft" constraint.

Constraints.

• Visual appearance must match Minecraft exactly (explicit).
• Mechanics must cover all of Minecraft's mechanics (1-1 clone) (explicit).
• No rounded corners, no border-radius, no soft shadows — Minecraft's GUI is sharp and flat (explicit).
• No blue-indigo primary buttons or white backgrounds — the world is dark and the UI is grey (explicit).
• No gradient blobs, no glassmorphism, no hover-lift cards — the world is the only visual (explicit).
• No Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui — use Silkscreen and VT323 (explicit).
• No centred headline + subtext + blue button hero — the hero is a 3D scene, not a marketing page (explicit).
• No photography, no stock people, no flat illustration — only procedural voxel terrain and pixel textures (explicit).
• No smooth cubic-bezier easing on UI — motion is frame-based and snappy like a game (explicit).
• No feature grid, no pricing table, no testimonials — this is a game, not a SaaS landing page (explicit).
• The generic indigo/blue-on-white SaaS template is forbidden for this project (explicit).

12. Glossary

• Voxel — a cube in the game world; the basic unit of terrain and building.
• Texture atlas — the 16×16 pixel texture sheet applied to cube faces to give blocks their Minecraft-like appearance.
• Hotbar — the 9-slot row at the bottom-centre of the HUD from which the Player selects the held item or block.
• HUD — the heads-up display overlaid on the world: hotbar, health, hunger, XP bar, crosshair, minimap, and chat.
• Crosshair — the 2px white plus sign with a 1px black outline at the dead centre of the screen, used to target blocks.
• Crafting grid — the 3×3 grid to the right of the inventory where items are arranged to produce recipes.
• XP bar — the hot pink (#FF55FF) experience bar that fills as the Player mines.
• Mob — a simulated creature in the world, such as the pig on the landing diorama.
• Skybox — the gradient background from #79A6FF to #B3D9FF with a blocky sun and moon.
• Diorama — the small floating voxel island shown on the Landing surface as the hero subject.