Build an original voxel sandbox game for the web, from scratch, in this empty directory.

It is a block-building game: the player walks around a procedurally generated world of cubes, breaks blocks and places new ones. Invent its name, its look and its colour palette. It must be original. Do not use the name, branding, textures, sounds, fonts, logos or any assets of any existing game (for example, never write "Minecraft" or "Mojang" anywhere). Generate every texture, colour and sound in code, or leave sound out.

## Hard constraints

1. Plain static files only: HTML, CSS and JavaScript (ES modules). No build step, no npm, no bundler, no server code. Opening the files from a static web server must be enough.
2. Use three.js only from this pinned URL, through an import map:
   ```html
   <script type="importmap">
   { "imports": {
       "three": "https://cdn.jsdelivr.net/npm/three@0.170.0/build/three.module.js",
       "three/addons/": "https://cdn.jsdelivr.net/npm/three@0.170.0/examples/jsm/"
   } }
   </script>
   ```
   No other network request is allowed: no other CDN, no web fonts, no images or sounds from the internet. Everything else lives in this directory or is generated in code.
3. Required files:
   - `index.html`: the landing page;
   - `game.html`: the game itself.
   Put any other files you need (JavaScript modules, CSS) in this directory or its subdirectories.
4. Neither page may log an error to the browser console during normal use.
5. Create every WebGL renderer with `preserveDrawingBuffer: true` so that its canvas can be read back with `toDataURL`.
6. When you are done, write `NOTES.md`: the game's name, what works, what doesn't, and how to run it (`python3 -m http.server` in this directory, then open http://localhost:8000/).
7. Keep files small and modular. No file may be longer than about 300 lines. Split the game into separate ES modules, for example: world and terrain generation, player and movement, block interaction, UI and hotbar, effects, save and load, and small utilities. Write or change one module per tool call; never write the whole game in one file or one call. index.html and game.html stay short and import the modules.
8. Check what the pages really look like. After every change to a page or a module, run `look` in this directory. It opens index.html and game.html in a headless browser and reports, in plain text, console errors, blocked requests, a blank canvas, a page wider than a phone, and whether the ground looks see-through from above (missing block faces). It also saves screenshots to /tmp/look/; open them if you can read images. Fix every problem it reports before you move on.

## Working habits

These keep the work moving when your answers are cut short or a command hangs.
- Write at most about 150 lines in one tool call. Build a longer file (a test script too) in parts: create it with the first part, then add the rest in later calls.
- Start a web server in the background on a free port, for example `python3 -m http.server 8123 > /tmp/server.log 2>&1 &`, and note its PID. Stop it with `kill <PID>`. Never use `pkill` or `killall`: a name pattern can match and kill your own session. If a command does not return within about a minute, stop it and run it in the background.
- Take the gallery pictures only after the scene has drawn at least one frame and its textures have loaded. Then run `look` and check that no picture is a flat colour.
- Work in this order: the game playable first, then the landing page, then polish. Commit with git after each step that works.
- Before you stop, go through the feature list below once more, item by item, and check each one with `look` and `window.__game`.

## Features and acceptance criteria

Each feature is scored by automated browser tests. The IDs and attributes in `code` below are part of the spec: the tests look for them exactly.

### F1. Landing page (`index.html`)
A polished, modern, marketing-style page for your game. It must look good on a desktop and on a phone.
- A hero section with the game's title in an `<h1>` and a one-line tagline.
- A live animated preview of the game world in a `<canvas id="hero-preview">`: render a small piece of your own voxel world with three.js and slowly orbit the camera around it. Consecutive frames must differ.
- A screenshot gallery in an element with `id="gallery"`. You cannot take screenshots, so the page makes them itself: at load, render at least 3 fixed camera views of your world (for example a wide landscape, a close-up of a build, a night view) to an offscreen renderer and put each one into an `<img>` inside `#gallery` with `src` set from `canvas.toDataURL("image/png")`. Each image must show the world, not a blank or single-colour frame.
- A feature list: a `<ul id="features">` with at least 4 `<li>` items.
- Controls help in an element with `id="controls"`, listing the keyboard, mouse and touch controls.
- A prominent "Play Now" button: an `<a id="play-now" href="game.html">` (styled as a button). Clicking it opens the game.
- Responsive: at 390 px wide, the page has no horizontal scrolling and the Play Now button is visible without zooming.

### F2. Procedural terrain
- The world is generated from a numeric seed with noise (hills, not a flat plane), and is at least 48 x 48 blocks across and 24 blocks tall.
- At least 4 block types, each with its own procedural colour or texture, for example grass, dirt, stone, sand, wood, leaves or water. Optional: trees or other generated features.
- The same seed always produces the same world.

### F3. First-person movement
- First-person camera. WASD moves, Space jumps, the mouse looks around.
- The arrow keys also turn the camera: Left/Right turn (yaw), Up/Down tilt (pitch). This must work without pointer lock.
- Gravity, and collision with blocks: the player cannot walk or fall through solid blocks and stands on the ground. Jumping lifts the player about one block, enough to step up onto a block one higher.
- Clicking the game canvas requests pointer lock. If pointer lock is not available or is refused, the keyboard and mouse buttons must still work.

### F4. Breaking and placing blocks
- A crosshair in the centre of the screen. The targeted block (the first solid block along the view ray, within 6 blocks) is highlighted.
- Left mouse button breaks the targeted block (it becomes air).
- Right mouse button places the selected hotbar block in the empty cell next to the targeted face. Never place a block inside the player.

### F5. Hotbar
- A visible hotbar of at least 4 block types, in an element with `id="hotbar"`. Each slot has the attribute `data-slot` set to its 0-based index. The selected slot (and only that one) has `aria-selected="true"`.
- Keys 1 to 9 select a slot; the mouse wheel cycles through slots.

### F6. Day/night cycle with lighting
- The sun moves, and the sky colour and scene light change through dawn, day, dusk and night. Night is clearly darker than noon.
- The default day length is 10 minutes of real time.

### F7. Particles and ambient effects
- Breaking a block bursts particles in that block's colour, which fall and fade within about a second.
- At least one simple ambient effect, such as drifting clouds, stars at night, fog, or floating dust.

### F8. Save and load
- The world (every block change) and the player position are saved to `localStorage`, at the latest 1 second after a change and when the page unloads.
- Reloading `game.html` restores the saved world and position. Provide a way to start a new world (for example a button or a key) that clears the save.

### F9. Controls on desktop and touch
- Desktop: pointer lock, WASD, Space, mouse look, arrow-key look, left/right click, 1-9 and the wheel, Escape to release the mouse.
- Touch: on a touch device, show on-screen controls. Each on-screen control has the attribute `data-touch` set to one of `move` (a joystick or direction pad), `jump`, `break` and `place`. Dragging on the rest of the screen looks around. Holding or dragging the `move` control forwards (upwards) moves the player forwards.

### F10. Debug interface (required, used by the tests)
The game must expose a read-only debug object, `window.__game`, as soon as the world is ready. It reports state; the tests never write to it, and it must not change the game. Keep these properties current every frame:

```js
window.__game = {
  version: 1,
  ready: true,                       // true once the world is generated and rendered
  seed: 1234,                        // the world seed in use
  blockTypes: ["air", "grass", ...], // index = block id; id 0 is air
  getBlock(x, y, z),                 // block id at integer world cell (x, y, z), 0 for air or outside the world
  player: { x, y, z },               // the player's feet position in world units (1 block = 1 unit, y is up)
  yaw: 0, pitch: 0,                  // camera angles in radians
  onGround: true,                    // whether the player stands on a block
  target: { x, y, z } | null,        // the cell of the block under the crosshair, or null
  hotbar: [1, 2, 3, 4],              // block id in each hotbar slot
  hotbarIndex: 0,                    // selected slot, 0-based
  timeOfDay: 0.5,                    // 0 = midnight, 0.25 = sunrise, 0.5 = noon, 0.75 = sunset; wraps at 1
  particles: 0,                      // number of live particles
  frames: 0,                         // frames rendered since load
};
```

The game also reads these URL parameters in `game.html` (and `index.html` ignores them):
- `seed=N`: the world seed (default: your choice, but fixed).
- `time=T`: the time of day at load, 0 to 1 (default 0.3).
- `daylength=S`: seconds for a full day (default 600).
- `debug=1`: start playing at once, without a start screen or a click, and keep the keyboard and mouse working without pointer lock.

With `debug=1`, `seed` and `time` set, and no save, the world and the start view must be the same on every load. A saved world is loaded on top of the generated one, also in debug mode.

## How you are scored
- Each feature above has automated tests (pass, partial or fail) run in headless Chromium against your files served over HTTP.
- The landing page and the game are also screenshotted at desktop and phone widths for a separate design score.
- Speed and tool usage are recorded, but a working game is what counts. Test your work as you go.

Work until every feature works, then write `NOTES.md` and stop.