The exact prompts behind the suite.

A small 3D world you can walk around. The point is the world, not the controls. The aim is to see whether a model can build a real 3D scene with believable atmosphere, a functional crafting loop, and smooth performance — not a stack of cubes with a sun lamp.

# 01. Low-Poly World Explorer

A small 3D world you can walk around. The point is the world, not the controls. The aim is to see whether a model can build a real 3D scene with believable atmosphere, a functional crafting loop, and smooth performance — not a stack of cubes with a sun lamp.

## What to make

A first-person 3D scene rendered into a `<canvas>` filling the viewport. The world is a stylized island at golden hour: low-poly terrain (triangulated heightmap with flat shading), clustered low-poly trees, a small body of water on one side, a stone path winding between landmarks, and a sky that fades from warm orange near the horizon to deep violet at the zenith.

The player walks with WASD, looks around by dragging the mouse. Camera stays at eye level (1.7m). Friction is light; the walk feels weighty but not sluggish.

A small compass and minimap in the corner show facing and player position. A toggle switches between walking and slow free-fly (constrained to island bounds).

### The crafting loop

Walk up to a tree and press E to harvest it. Materials appear in an on-screen inventory. Walk to the workbench (near the stone path) and press C to open the craft menu. Place a crafted object on the ground where you stand.

The specific recipes and what you can build are not specified. The model decides what the workbench produces. A minimum of three craftable items must exist. The crafting system must be self-consistent with the island's palette and style — crafted objects should not look out of place.

## Always-visible HUD

Top-right corner:
- **FPS** — current frame rate, updates every second
- **Compass** — N/S/E/W facing
- **Inventory** — current material count

Bottom-left:
- **Controls hint** — fades out after 5 seconds ("WASD move · drag look · E harvest · C craft · F toggle fly")

## Hard requirements

- Single `index.html`. No build step.
- WebGL via Three.js, Babylon.js, regl, or raw WebGL2. Any CDN libraries must be listed in `manifest.json.externalAssets`.
- Smooth at 30fps on a 2020 laptop with integrated graphics at 1280x800.
- No external textures fetched at runtime. Build procedural textures, draw to canvas, or ship assets in the folder.
- Collision with terrain — the player walks on the surface, not through it.
- No login. No menus. The page opens and you are in the world.
- Three or more craftable items with at least one recipe.
- `prefers-reduced-motion`: disable camera bob, reduce particle density.

## Visual rules

- Real lighting: directional light from the low sun, ambient from the sky, fog that thickens with distance and matches the sky color at the horizon.
- Low poly means low poly. Each tree reads as a tree from 10 meters away. Geometry does the work — no high-resolution textures.
- The water surface ripples gently. The sun's specular highlight moves with the ripples.
- Trees cast shadows.
- The minimap uses a single accent color — not default green.
- Crafted objects are built from the same low-poly vocabulary as the world. They must look like they belong.

A real-time top-down office simulator. Characters — each an AI-generated inline SVG — walk between departments, sit at desks, and perform role-specific tasks. The viewer watches a little world breathe, or presses a button to trigger a specific event. The aim is to see whether a model can build a self-consistent simulation with shared resources, dependency chains, and expressive SVG art simultaneously.

# 02. The 9-to-5 — Office Life Simulator

A real-time top-down office simulator. Characters — each an AI-generated inline SVG — walk between departments, sit at desks, and perform role-specific tasks. The viewer watches a little world breathe, or presses a button to trigger a specific event. The aim is to see whether a model can build a self-consistent simulation with shared resources, dependency chains, and expressive SVG art simultaneously.

## What to make

A single-page, real-time office simulation rendered in SVG. The camera is fixed top-down (2D). The office is a floor plan with named zones. Characters move between zones, perform tasks, and interact with shared resources. A clock in the corner shows simulated time. An FPS counter and task-completion counter are always visible. Buttons in a bottom bar let the viewer trigger events.

The 8-hour workday (9 AM – 5 PM) is compressed to **15 seconds of real time** (1 real second ≈ 32 simulated minutes).

### The office floor plan

```
┌──────────────────────────────────────────────────────────────┐
│  RECEPTION         │        OPEN PLAN (Engineering)           │
│  (intern desks)   │   desks, whiteboards, monitors         │
├──────────┬─────────┴──────────────────────┬─────────────────┤
│ MEETING  │     KITCHEN / BREAK ROOM       │   EXECUTIVE     │
│ ROOM 1   │  coffee machine, fridge, table │   CORNER        │
│          │                                  │  (CEO desk)    │
├──────────┴─────────────────────────────────┴─────────────────┤
│ HR DESK    │    SALES FLOOR (3 desks)   │   STORAGE        │
│            │    phones, deal boards       │   printer,       │
│            │                              │   supplies       │
└──────────────────────────────────────────────────────────────┘
```

### The five characters

Each character is a hand-crafted inline SVG (no external files). Flat/minimalist style, warm palette, immediately recognizable silhouettes.

| Character | Starting zone | Accent | Tasks |
|---|---|---|---|
| **Alex** (Engineer) | Open Plan | Blue | Code review → standup meeting → lunch → debug incident |
| **Sam** (Sales) | Sales Floor | Green | Cold call → demo prep → presentation → close deal |
| **Jordan** (HR) | HR Desk | Amber | Review resumes → interview prep → conduct interview → file paperwork |
| **Riley** (Ops) | Storage | Orange | Restock supplies → fix printer → prep meeting room → coffee delivery |
| **Casey** (Intern) | Reception | Yellow | Greet arrivals → fetch coffee → shadow meeting → reorganize storage |

### The task system

Each character has a **queue of tasks**. Tasks have:

- **Duration** — simulated minutes at the workstation
- **Location** — which zone the character must be in
- **Prerequisites** — conditions that must be met first
- **Animation state** — what the SVG character does while working

**Alex (Engineer):**
1. Arrive at desk (walk from entrance, 8 simulated minutes)
2. Code review (typing animation, 30min) — prerequisite: coffee
3. Standup meeting (walk to Meeting Room 1, 15min) — prerequisite: another team member is present
4. Lunch (walk to kitchen, eating, 60min)
5. Debug incident (urgent red glow, 20min) — fires once per day at a random time

**Sam (Sales):**
1. Cold calls (phone animation at desk, 20min)
2. Demo prep (slides animation, 15min)
3. Presentation (walk to Meeting Room, 25min) — prerequisite: projector turned on
4. Close deal (celebration or disappointment animation, 10min)
5. Update CRM (typing, 10min)

**Jordan (HR):**
1. Review resumes (reading at desk, 25min)
2. Interview prep (organizing, 15min)
3. Conduct interview (walk to Meeting Room, 20min) — prerequisite: room is available
4. File paperwork (typing, 12min)

**Riley (Ops):**
1. Restock supplies (walking, 15min)
2. Fix printer (tool animation at printer, 12min) — queue system
3. Prep meeting room (setup animation, 10min) — prerequisite before any meeting
4. Coffee delivery (carry animation, 8min)

**Casey (Intern):**
1. Greet arrivals (wave at reception, 15min)
2. Fetch coffee (carry, 10min) — delivers to Jordan before interviews
3. Shadow meeting (observe in Meeting Room, 15min) — prerequisite: meeting is happening
4. Reorganize storage (sorting, 12min)

### Shared resources

| Resource | Zone | Capacity | Behavior |
|---|---|---|---|
| Coffee machine | Kitchen | 1 at a time | Queue forms. Brewing takes 5 simulated minutes. Coffee lasts 1 task. |
| Projector | Meeting Room 1 | 1 | Riley turns it on before Sam can present. Toggle animation. |
| Printer | Storage | 1 | Jobs queue. Printing takes 8 simulated minutes. Flashes when done. |
| Kitchen table | Kitchen | 3 seated | Characters wait, leave when done. |
| Meeting chairs | Meeting Room 1 | 6 | Riley sets up before meetings. |

### The simulation clock

- **9:00 AM** — All characters walk in from entrance to starting zones.
- **9:30 AM** — Task queues begin filling.
- **12:00 PM** — Lunch wave. Characters stagger naturally; not everyone leaves at once.
- **1:00 PM** — Post-lunch return. Walk speed visibly slower.
- **3:00 PM** — Afternoon slump. Occasional yawn animation.
- **4:30 PM** — Wind-down. Desks clear.
- **5:00 PM** — Day end. Characters walk out. Stats panel: "Day complete — N tasks finished."

Loops back to 9 AM after 8 seconds. Runs indefinitely.

## Viewer controls

A bar at the bottom of the screen has two buttons. Pressing either triggers an event immediately regardless of the clock.

**Emergency Meeting** — All characters immediately drop what they are doing and rush to the Executive Corner (CEO's office). They gather in a cluster, a brief "discussion" animation plays (2 seconds), then they return to their desks and resume their task queues. This tests how gracefully the model handles interrupt handling and task queue resumption.

**Lunch Break** — Triggers the lunch sequence immediately. All characters currently not in a meeting walk to the kitchen, queue for the coffee machine and table, eat (eating animation), and then return to their desks. Characters mid-presentation or mid-interview finish their current task before joining. This tests capacity management and staggered timing on the shared kitchen resource.

## Always-visible HUD

Top-right corner of the screen:
- **FPS** — current frame rate, updates every second
- **Tasks done** — count of completed tasks across all characters
- **Sim time** — current simulated time (e.g. "10:42 AM")

## Hard requirements

- Runs from a single `index.html`. No build step. No external image files — all characters and furniture are inline SVG inside the HTML.
- Smooth at 60fps with 5 characters and all zone interactions.
- No network calls at runtime.
- Keyboard: Space pauses/resumes. R resets to 9 AM.
- The SVG art must be self-consistent across all 5 characters — same proportions, same palette, same animation vocabulary.
- `manifest.json` lists any CDN URLs used (none expected).
- Honor `prefers-reduced-motion`: replace walking animations with instant teleports. Disable looping ambient animations.

## Visual rules

- **Top-down.** Characters approximately 20px tall. Clear silhouettes.
- **Palette:** Warm neutrals — cream walls, light wood desks, dark charcoal furniture. Each character has one accent color.
- **Zone distinction:** Each zone has a subtly different floor tone and furniture arrangement.
- **Animation vocabulary:** walk (bob + translate), sit (static at desk), type (small vertical oscillation), talk (scale pulse), wait (subtle sway), celebrate (scale up briefly), urgent (red glow pulse). Exactly one animation state per character at a time.
- **State indicators:** A small speech-bubble floats above a character when blocked waiting for a prerequisite.
- **No gradients on floors.** Shadows are simple offset rectangles.

A living city you can watch. That's it. That's the whole thing.

# 03. Vice City — Open World City Generator

A living city you can watch. That's it. That's the whole thing.

## What to make

A procedurally generated 3D city rendered in isometric or top-down perspective, filling the browser window. Buildings rise from a grid. Streets run between them. A sky hangs overhead. The city populates itself and runs.

A sidebar on the right holds the controls. A stats panel in the corner shows live metrics.

### The city

The city is generated procedurally on load and on demand. Each generation is unique — different building heights, different block layouts, different street grids. The algorithm decides:

- Building count and density
- Street width and grid pattern
- Landmark placement (a plaza, a tower, a park)
- Zoning (residential, commercial, industrial, mixed)

The city must feel like a city. Not a spreadsheet. Not a diagram. A place with presence.

### Sidebar controls

**Regenerate City** — Clears the current city and generates a new one from scratch. Buildings spring up with a brief stagger animation (50ms between each row, for visual effect).

**Toggle Day/Night** — Transitions the sky, lighting, and window glows. Day is bright with long shadows. Night is dark with lit windows, street lights, and a visible moon or city glow on the horizon.

**Earthquake Mode** — Shakes the entire view. Buildings sway. Camera oscillates. After 3 seconds the shaking stops and the city settles. The UI shows an "EARTHQUAKE" badge briefly.

**Toggle Traffic** — Adds moving vehicles on the streets. Cars follow the road grid, stop at intersections, and vary in speed and color. Toggle again to remove traffic.

### Stats panel

Top-left, always visible:
- **Buildings** — count of structures rendered
- **Population** — estimated (buildings × average units per building)
- **Render time** — how long the last regeneration took in milliseconds

## Always-visible HUD

Top-right: FPS counter, updates every second.

Bottom-right: Controls legend ("REGENERATE · DAY/NIGHT · EARTHQUAKE · TRAFFIC · scroll to zoom · drag to pan").

## Hard requirements

- Single `index.html`. No build step.
- No external textures fetched at runtime. All geometry and materials are procedural or drawn to canvas.
- Must regenerate in under 3 seconds on a 2020 laptop.
- Traffic, if enabled, runs at 30fps minimum.
- `prefers-reduced-motion`: no camera shake, no stagger animation, no vehicle movement.

## Visual rules

- Isometric or top-down 3D. Camera can zoom and pan, but angle is fixed.
- Buildings are simple extruded blocks — varied heights, varied window patterns, varied roof shapes. They read as buildings from above.
- Streets are flat planes between buildings.
- Day: warm sun, long directional shadows.
- Night: dark sky, ambient city glow, individual lit windows on buildings.
- Cars are simple top-down shapes that move along streets.
- No photorealism. This is a stylized city, not a GTA clone.
- The palette shifts with day/night: warm gold by day, deep blue and amber by night.

Make a 3D game from a poem. That is the entire brief.

# 04. Jabberwock — A 3D Game in Verse

Make a 3D game from a poem. That is the entire brief.

## The poem

```
’Twas brillig, and the slithy toves
      Did gyre and gimble in the wabe:
All mimsy were the borogoves,
      And the mome raths outgrabe.

"Beware the Jabberwock, my son!
      The jaws that bite, the claws that catch!
Beware the Jubjub bird, and shun
      The frumious Bandersnatch!"

He took his vorpal sword in hand;
      Long time the manxome foe he sought—
So rested he by the Tumtum tree
      And stood awhile in thought.

And, as in uffish thought he stood,
      The Jabberwock, with eyes of flame,
Came whiffling through the tulgey wood,
      And burbled as it came!

One, two! One, two! And through and through
      The vorpal blade went snicker-snack!
He left it dead, and with its head
      He went galumphing back.

"And hast thou slain the Jabberwock?
      Come to my arms, my beamish boy!
O frabjous day! Callooh! Callay!"
      He chortled in his joy.

’Twas brillig, and the slithy toves
      Did gyre and gimble in the wabe:
All mimsy were the borogoves,
      And the mome raths outgrabe.
```

## What to make

A playable 3D game that tells this story. The model decides everything else: the camera angle, the gameplay loop, how to interpret the creatures, what the world looks like, how movement works, what the combat feels like, how to end the game.

The poem is not guidance. It is source material. The model must make it real.

### The model's creative decisions

Every word in the poem is a decision point. The model must commit:

- **Brillig** — what time of day is this? What does the light feel like?
- **Slithy toves** — what do they look like? What do they do? Do they move? Are they enemies? Ambient life?
- **Gyre and gimble** — what do these verbs look like? Are they animations? Are they physics? Are they visual effects?
- **The wabe** — what is this place? A field? A clearing? The ground itself?
- **Mimsy, borogoves, raths, outgrabe** — creatures or atmosphere or both?
- **Jabberwock** — the central encounter. The model must decide what it looks like, how it attacks, how it moves, how it dies.
- **Jubjub bird and Bandersnatch** — minor threats or absent entirely? The model decides.
- **Vorpal sword** — what does it look like? What does the strike feel like? The sound?
- **Tumtum tree** — a landmark. The model decides its shape and placement.
- **Uffish thought** — the pause before the battle. A moment. The model decides how to show it.
- **Eyes of flame, whiffling, tulgey wood, burbled** — all of these must exist in the game in some form.
- **Snicker-snack** — the kill. The model decides the animation, the feedback, the punctuation.
- **Galumphing back** — the victory lap. The model decides what this looks and feels like.
- **Frabjous day, Callooh, Callay** — the ending. The model decides how the game concludes.

Every decision the model makes is visible. A weak model makes no decisions and builds a generic fantasy scene. A strong model commits to a vision.

### What the game must have

- The player character must be controllable. WASD or arrow keys minimum.
- The Jabberwock must be present and must be defeatable.
- The vorpal sword must be part of the combat.
- The world must have at least three distinct visual zones: the wabe (the starting area), the tulgey wood (where the Jabberwock appears), and a victory moment (the ending).
- The poem text must appear at least three times in the game — at the start, before the Jabberwock encounter, and at the end.

## HUD

Top-right: FPS counter, updates every second.

## Hard requirements

- Single `index.html`. No build step.
- WebGL via Three.js, Babylon.js, regl, or raw WebGL2. Any CDN libraries listed in `manifest.json.externalAssets`.
- Smooth at 30fps on a 2020 laptop.
- The poem text must be legible — do not render it as unreadable ambient texture.
- No external textures fetched at runtime.
- `prefers-reduced-motion`: reduce or remove particle effects and camera shake. Movement should remain functional.

## Visual rules

- No default fonts. Pick a typeface that matches the world the model has built.
- The palette is the model's choice, but it must be consistent across the entire game — lighting, UI, creatures, and world all share the same visual language.
- Sound is optional. If included, it must not be a requirement to play.
- The Jabberwock must read as a threat from 20 meters away. Not a cube with eyes.
- The vorpal sword strike must feel like an event, not a collision.

A petri dish teems with life. You watch. You control. You let it run.

# 05. Petri Dish — Emergent Life Simulation

A petri dish teems with life. You watch. You control. You let it run.

## What to make

A real-time 2D simulation rendered to a `<canvas>`. A circular petri dish fills the center of the screen. Inside, colored agents move, hunt, eat, and reproduce. A population chart updates live in the corner. Controls sit in a sidebar.

### The simulation

The dish contains two species of agent:

**Prey** — small, fast, numerous. They drift randomly, seeking food (particles that spawn at edges). When well-fed, they reproduce: a new prey agent spawns nearby. Prey are eaten on contact with a predator.

**Predators** — larger, slower, fewer. They hunt prey. When a predator eats a prey, it gains energy. When a predator has enough energy, it reproduces. If a predator runs out of energy, it dies.

The simulation is governed by rules. The behavior that emerges from those rules is what you watch. Prey flock. Predators stalk. Populations boom and crash. Equilibrium finds itself or doesn't. Every run is unique.

### The control panel

Sidebar on the right:

**Add Prey** — Spawns 10 prey agents at a random position inside the dish. The button shows the current prey count.

**Add Predator** — Spawns 3 predator agents at a random position. The button shows the current predator count.

**Pause / Resume** — Freezes the simulation. All agents stop. The chart pauses. Press again to continue.

**Speed Slider** — Controls simulation speed. Range: 0.25x to 4x. Default: 1x.

**Reset** — Clears the dish and starts fresh with 30 prey and 5 predators.

### The population chart

A live line chart in the top-right corner of the canvas. Two lines:

- **Green line** — prey population over time (left y-axis)
- **Red line** — predator population over time (right y-axis)

The chart shows the last 60 seconds of simulation time. It updates every frame. The lines must not flicker or jump — smooth interpolation between data points.

The chart background is dark, the lines are bright. The chart reads clearly at a glance.

### The dish

The petri dish is a circle with a subtle border — not a sharp rectangle. Agents that reach the edge bounce back in. The dish interior has a faint texture (drawn once to an offscreen canvas) so it reads as a surface, not a void.

## Always-visible HUD

Top-right corner: FPS counter, updates every second.

Bottom-left: Agent count ("Prey: N · Predators: N").

## Hard requirements

- Single `index.html`. No build step.
- Simulation must run at 60fps with 200 agents on screen.
- No external libraries. Canvas 2D API only.
- Agents must not escape the dish.
- The chart must show 60 seconds of history minimum.
- `prefers-reduced-motion`: simulation runs at 0.5x speed, chart draws less frequently (every 500ms).

## Visual rules

- Prey: small circles, green. Predators: larger circles, red or amber.
- Agents have a subtle trail or fade, not hard-edged.
- The dish border is crisp but not bold — the focus is the life inside.
- The chart lines are the only high-saturation elements on the page. Everything else is subdued.
- No text inside the dish. Labels live in the sidebar only.
- Food particles: tiny, dim white dots. Visible but not distracting.

Generate a single, self-contained HTML file that renders Helm's Deep (the Hornburg) from The Lord of the Rings: The Two Towers as a fully explorable 3D environment in first-person mode. Use Three.js via CDN importmap. No external assets, no build tools, no APIs. All CSS, JS, and markup must be inline. It should look beautiful and feel like Helm's Deep in the movies.

# Helm's Deep

Generate a single, self-contained HTML file that renders Helm's Deep (the Hornburg) from The Lord of the Rings: The Two Towers as a fully explorable 3D environment in first-person mode. Use Three.js via CDN importmap. No external assets, no build tools, no APIs. All CSS, JS, and markup must be inline. It should look beautiful and feel like Helm's Deep in the movies.

## Geographic Layout (movie-accurate)

The model must include the key defensive structures in correct spatial relation:

- The Hornburg: central stronghold with towering stone walls, wooden hoardings, and the great hall.
- The Deeping Wall: long, curved defensive wall extending across the natural chasm, with crenellations and a parapet walk.
- The Causeway: sloping approach leading up to the main gate, flanked by stone walls.
- The Ramp: the internal incline leading up into the main courtyard.
- The Deeping Culvert/Stream: the drainage channel at the base of the wall where the Deeping Stream exits.
- The Courtyard: open interior space with wooden scaffolding, supply crates, and an armory feel.
- The Glittering Caves entrance: visible at the rear of the courtyard.
- The Natural Bowl: encircling mountainous rock walls that create the natural fortress position.

## First-Person Controls

- Implement Pointer Lock (WASD to move, mouse to look).
- Space to jump (optional), Shift to run.
- Collision detection against walls so the player cannot walk through stone.
- Gravity and ground collision so the player stays on terrain and walkways.

## Visual & Atmospheric Style

- Gloomy, overcast twilight (the eve-of-battle mood).
- Warm torch and brazier lighting along walls and the causeway.
- Cool blue ambient fog in the lower valley.
- Rain particle system (light streaks, not heavy).
- Wet stone and mud ground textures (procedural canvas noise).
- Dark slate and gray Rohan granite for the Hornburg.
- Weathered wood and iron for gates and hoardings.

## Optional Scene Details

- Scattered siege ladders leaning against the Deeping Wall.
- Broken debris and spent arrows in the courtyard suggesting post-battle cleanup.
- Distant campfires in the valley below (billboard sprites).

## Output

One fully functional HTML file. Copy-paste ready. No external dependencies except Three.js via CDN importmap.

Build a visually exciting 3D broom-flight simulator set around Hogwarts. The page opens and immediately begins an automated cinematic flight around the castle grounds. The camera follows a single wizard student riding a broom, weaving through dramatic paths without hitting walls, towers, trees, cliffs, or stadium structures.

# Hogwarts Broom Flight Simulator

Build a visually exciting 3D broom-flight simulator set around Hogwarts. The page opens and immediately begins an automated cinematic flight around the castle grounds. The camera follows a single wizard student riding a broom, weaving through dramatic paths without hitting walls, towers, trees, cliffs, or stadium structures.

The point is spectacle, atmosphere, and motion: show the castle, the stadium, the lake, the bridges, the towers, and the scary forest in a way that feels alive and thrilling.

## What to Make

A full-screen 3D scene rendered into a <canvas>. The player character is a young wizard on a broom, seen from a third-person chase camera. The broom automatically follows a series of cinematic flight paths around the world.

The simulation must feel like a magical aerial tour, not a static model viewer.

The flight path should include:

1. **Castle Arrival**
   - Start high above misty hills.
   - Dive toward the Hogwarts-style castle.
   - Circle the tallest towers.
   - Fly past windows, bridges, courtyards, rooftops, and spires.
   - Avoid clipping through geometry.

2. **Castle Close Pass**
   - Glide low over the main courtyard.
   - Pass between towers and over stone walkways.
   - Show warm glowing windows and large castle silhouettes.
   - Use banking turns and camera sway for speed.

3. **Stadium Run**
   - Fly out toward a large Quidditch-style stadium.
   - The stadium must be huge, readable, and exciting.
   - Include tall spectator towers, colored banners, circular hoops, and an open pitch.
   - The broom should race through or around the hoops, then spiral upward above the stadium.

4. **Lake and Bridge**
   - Sweep across a dark reflective lake.
   - Fly under or beside a stone bridge.
   - Show castle reflections or shimmering water highlights.

5. **Scary Forest**
   - Enter the edge of a dark forbidden forest.
   - The trees should be tall, dense, twisted, and atmospheric.
   - Use fog, moonlight shafts, moving shadows, and glowing eyes or magical sparks in the distance.
   - The flight path should skim through clear gaps between trees without collisions.

6. **Final Hero Shot**
   - Pull back into a wide orbit showing the castle, stadium, lake, and forest together.
   - End by looping smoothly back into the opening flight path.

## Controls

The scene runs automatically, but include simple optional controls:

- **Space**: pause or resume the auto-flight
- **Arrow Left / Arrow Right**: switch to previous or next cinematic route
- **M**: toggle cinematic camera mode
- **F**: toggle faster flight

Do not require controls to enjoy the page. It should look impressive immediately on load.

## Always-Visible HUD

Top-right corner:

- **FPS**
- **Current route name**
- **Speed**
- **Camera mode**

Bottom-left:

- Small controls hint:
  "Auto-flight · Space pause · arrows change route · M camera · F speed"

The hint fades after 6 seconds.

## World Requirements

The world must include:

- A large multi-tower castle with recognizable silhouette
- A dramatic stadium with hoops, banners, towers, and an open pitch
- A dark forest with dense trees and fog
- A lake or water surface
- Stone bridges or elevated paths
- Rolling terrain around the grounds
- Sky, fog, lighting, and atmosphere

## Flight Requirements

The broom path must be interesting and safe:

- No flying through walls, towers, roofs, trees, hoops, or terrain
- Use smooth curved paths, not straight-line teleporting
- Include climbs, dives, banks, spirals, close passes, and wide reveals
- Camera should lag slightly behind the broom for cinematic motion
- Broom should tilt into turns and pitch during climbs/dives
- Path should loop seamlessly

## Visual Rules

- Full-screen 3D, no landing page
- The castle must be the visual centerpiece
- The stadium must feel large and exciting, not like a flat field
- The forest must feel genuinely dark and intimidating
- Use real lighting: moonlight, warm window lights, fog, and shadows
- Use procedural or locally shipped assets only
- No external textures fetched at runtime
- Avoid default-looking cubes. Shape the castle with towers, roofs, arches, bridges, windows, and layered stone forms
- Make the broom rider readable from a distance: cloak, body, broom silhouette, scarf or trailing fabric

## Hard Requirements

- Single index.html
- No build step
- WebGL via Three.js, Babylon.js, regl, or raw WebGL2
- Any CDN libraries must be listed in manifest.json.externalAssets
- Smooth at 30fps on a 2020 laptop at 1280x800
- Keyboard accessible
- lang="en" on <html>
- Honor prefers-reduced-motion:
  - Slow camera banking
  - Disable intense shake
  - Reduce particles and fog animation
  - Keep auto-flight functional

Make a beautiful simulation of the universe and solar system. It should be sped up with adjustable time, realistic motion, orbits, and stars. Use Three.js. Make the HUD well styled and conform to modern design principles.

# Universe Simulator

Make a beautiful simulation of the universe and solar system. It should be sped up with adjustable time, realistic motion, orbits, and stars. Use Three.js. Make the HUD well styled and conform to modern design principles.

Generate a single, self-contained HTML file that renders a Yingzao Fashi (Building Standards) assembly/disassembly animation of a Chinese ancient timber building based on a user-uploaded photo.

# Yingzao Fashi Assembly

Generate a single, self-contained HTML file that renders a Yingzao Fashi (Building Standards) assembly/disassembly animation of a Chinese ancient timber building based on a user-uploaded photo.

Input: The user will upload one photo of a Chinese ancient building (for example, Yingxian Wooden Pagoda, Main Hall of Foguang Temple, or similar). Use the image to infer the building type, scale, and predominant structural features.

Plan first, then execute. Do not write the final HTML until the plan is reviewed and the build order is validated.

## Required features

### 1. Building identification and component mapping

- Identify the building type from the photo (pagoda, hall, pavilion, etc.).
- Map and label the major structural components in the traditional order: columns (柱), beams (梁), fang/tie-beams (枋), purlins (檩), rafters (椽), and dougong bracket sets (斗拱).
- Each component must have a floating label (HTML/CSS overlay or Three.js sprite) showing its Chinese name, pinyin, and a one-sentence function description.

### 2. Three.js assembly animation

- Build a simplified but architecturally credible 3D model using Three.js (single HTML file, embedded JS/CSS, no external dependencies except Three.js from a CDN).
- Animate the assembly in the actual traditional construction sequence:
  1. Erect columns and establish the bay grid.
  2. Place fang/tie-beams to lock the frame.
  3. Install main beams and purlins.
  4. Assemble and place dougong bracket sets.
  5. Lay rafters and apply roof planes.
- Include a play/pause/step UI to control the assembly animation.

### 3. Age erosion slider

- Add a slider (0 = new, 100 = ancient) that drives visible aging on wood materials.
- Effects should include wood darkening, roughness increase, paint pigment fading and peeling (use texture/color mixing, not external image assets), and subtle geometry warping/twisting to suggest centuries of settlement.
- The slider must work in real time and be visually obvious.

### 4. Structural X-ray / transparent mode

- Add a toggle that hides or makes translucent roof tiles, wall panels, and decorative cladding to reveal the internal timber frame.
- In X-ray mode, highlight mortise-and-tenon joint locations with visible points or simplified joint geometry so the joinery logic is readable.

## Output constraints

- Exactly one HTML file.
- No build step or bundler required; open the file in a browser and it runs.
- Responsive canvas sizing. Handle window resize.
- Include brief in-app instructions so a first-time user knows how to use the controls.

## Loop / validation rule

Do not stop until:

- The HTML file loads in a browser without errors and without requiring a local server (`file://` protocol is acceptable).
- The assembly animation plays through all five construction stages in the correct traditional order and each stage is clearly distinguishable.
- All component labels appear and are readable.
- The age erosion slider produces a visible, smooth transition from new to weathered timber.
- The X-ray toggle reveals the internal frame and joint indicators.
- You have personally reviewed the generated HTML source to ensure there are no placeholder comments, missing functions, or TODOs.

If any requirement is broken, incomplete, or visually unclear, fix it and re-test. Continue until the file is fully playable and inspectable.

Before declaring complete, run these checks:

1. Open the file in a browser. Confirm the canvas appears.
2. Click Play on the assembly animation. Confirm columns appear first, then beams, then dougong, then roof.
3. Move the age slider from 0 to 100. Confirm the wood gets visibly darker and paint fades.
4. Toggle X-ray mode. Confirm roof/walls go translucent and joints are marked.
5. Hover over a column and a dougong. Confirm labels appear with correct names.

If any check fails, identify the specific missing code or broken function, patch it, save the file, reload the browser, and re-run all five checks.