Build an original 3D browser game of your own design, plus a landing page for it, from scratch, in this empty directory.

You choose the game: its genre, its rules, its goal, its name, its look and its colour palette. It must be a real game with something to do (a goal, a score, a challenge or a way to win or lose), and it must be 3D: a three.js scene with a perspective camera that the player moves through or around.

It must NOT be a voxel or block-building game: no worlds made of cubes that the player breaks and places, nothing in the style of Minecraft or its clones. Pick something else.

It must be original. Do not use the name, branding, characters, textures, sounds, fonts, logos or any assets of any existing game. Generate every model, 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, its genre, how to play and how to win or lose, what works, what doesn't, and how to run it (`python3 -m http.server` in this directory, then open http://localhost:8000/).

## Features and acceptance criteria

Some features are scored by automated browser tests; the IDs and attributes in `code` below are part of the spec and the tests look for them exactly. The rest is scored from screenshots and play-testing: how fun, clear and polished the game is.

### C1. 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 in a `<canvas id="hero-preview">`, rendered with three.js. 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 different views of your game 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 game, not a blank or single-colour frame.
- A feature list: a `<ul id="features">` with at least 4 `<li>` items.
- How to play, in an element with `id="controls"`: the goal and 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.

### C2. A 3D game that plays
- `game.html` renders a three.js scene with a perspective camera and moving 3D content.
- The player controls something with the keyboard and mouse (desktop) and with on-screen controls or gestures (touch). Every on-screen control has the attribute `data-touch` set to a short name of what it does.
- There is a goal: a score, a timer, lives, levels, or a win or lose state, shown on screen.
- A start screen or a short how-to-play overlay, and a way to restart after winning or losing.

### C3. Feel and polish
- Feedback for the player's actions: sound or visual effects, animation, camera motion.
- A clear visual style of your own: lighting, colours, shapes that fit together.
- The game runs smoothly: no frozen frames, nothing that stops working after a minute of play.

### C4. Debug interface (required, used by the tests)
The game must expose a read-only debug object, `window.__game`, as soon as the game 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 scene is built and rendered
  name: "Your Game",    // the game's name
  state: "playing",     // one of "start", "playing", "won", "lost", "paused"
  score: 0,             // a number; use your game's main measure of progress
  player: { x, y, z },  // the position of what the player controls, in world units
  frames: 0,            // frames rendered since load
};
```

`game.html` reads these URL parameters (and `index.html` ignores them):
- `seed=N`: a seed for anything random (default: your choice, but fixed).
- `debug=1`: start playing at once, without a start screen or a click, and keep the keyboard working without pointer lock.

With `debug=1` and `seed` set, the start view must be the same on every load.

## How you are scored
- The automated tests check C1, the C2 and C4 items they can see (renders, input changes `player` or `score`, `state` reaches "playing"), and that no page logs a console error.
- The landing page and the game are screenshotted at desktop and phone widths and played for a short time for a separate design and fun score.
- Speed and tool usage are recorded, but a working, fun game is what counts. Test your work as you go.

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