# Itsy Bitsy Spider - V3 Frozen Eval Prompt

This is the **public frozen prompt** for the third iteration of the Calibrating Posteriors practical builder eval.

## Usage Notes

- Use this prompt in a **fresh session with no prior context**.
- Do **not** answer clarification questions from the model. The prompt explicitly instructs the model to make reasonable assumptions and continue.
- The evaluator, not the model, should record external metrics such as wall-clock time, token count, API cost, and final file count.

---

## Frozen Prompt

```text
You are the Director of a small game team. Your job is to deliver a finished, playable web game in one pass.

The objective is to make a fun game. Not just a technically correct one — a game that feels good to play, that has juice, that makes the player want to try one more time.

Do not ask clarifying questions.
Do not stop at planning.
Do not return partial work.
Make reasonable assumptions when needed, execute them, test the game, fix obvious issues, and only then deliver the final result.

# Project

Build a small browser game called "Itsy Bitsy Spider".

## One-line summary

A tense endless wall-crawling game where a spider climbs an infinite wall, spends stamina to move, eats flies to recover, and must reach shelter holes before periodic rainstorms knock it off the wall.

## Platform

- Must run well in both desktop and mobile browsers
- Deliver as a static web game
- No backend
- No login
- No online services
- No runtime AI calls
- No external assets required for the game to function

## Preferred technical format

- Plain HTML, CSS, and JavaScript
- Keep the project lightweight and easy to open locally
- Prefer `index.html` plus a small number of supporting files
- Avoid unnecessary framework complexity

## Core fantasy

The player is a small, vulnerable spider clinging to a huge wall during dangerous weather, trying to climb ever higher without exhausting itself.

This should feel like a **wall-crawling spider game**, not a platform jumper with a spider skin.

The spider should usually feel attached to the wall surface rather than repeatedly leaping between floating ledges.

## Hard anti-drift guardrails

The build is **wrong** if it turns into any of the following:

- a standard platform jumper with floating ledges as the primary traversal surface
- a game where jumping is the main skill expression
- a game where an active web ability becomes the core movement verb
- a game where mobile controls are hidden, missing, or unreliable on real phones

If you find yourself building floating platforms and jump arcs, stop and re-center the design around **wall traversal, route planning, stamina, flies, rain, and shelter**.

## Core loop

1. Crawl upward across an endless wall
2. Spend stamina to move and route through the environment
3. Notice an incoming rain warning
4. Decide whether to detour for a fly or rush toward shelter
5. Reach a shelter hole before the rain begins
6. Recover, keep climbing, and beat your previous height

## Required mechanics

### Movement

- Desktop: `WASD`
- Mobile: on-screen virtual joystick or an equally clear touch movement solution
- Movement should feel like **crawling on a wall**, not standard platformer running and jumping
- The spider may move in 8 directions or another clearly wall-oriented movement model
- Avoid making jump arcs the primary verb
- Prefer continuous attachment to the wall over airborne traversal

### No web mechanic

- Do **not** use webs as an active traversal mechanic
- Do **not** add a web-zip action button
- If webs appear at all, they should be purely decorative or environmental, not the main verb
- If you need a second action to make the game work, prefer a stamina-safe pause, cling, or crawl-mode variation over reintroducing webs

### Stamina

- Moving spends stamina
- Stamina must be visible during play
- Running out of stamina causes the spider to lose grip, fall off the wall, and die
- The stamina system should create tension, but not feel unfairly punishing in the first moments of play

### Flies

- Flies appear on the wall as pickups
- Reaching and eating a fly restores stamina
- Flies should not all sit on the safest path
- At least some flies should create meaningful tradeoffs between survival now and survival later

### Rain

- Rain must be **telegraphed 2-3 seconds in advance**
- Then a dangerous rain sweep begins
- If the spider is exposed during the rain, it falls off the wall and dies
- Shelter holes in the wall protect the player

### Shelter holes

- Shelter holes are part of the wall and must feel like meaningful route targets
- The player should sometimes need to move sideways or slightly downward to reach shelter
- Shelter placement should create interesting pathing choices rather than always being trivial

### Scoring

- Score is based on height climbed
- The current score must be visible during play
- A high score should be shown and persist during the session

### Sound and SFX

- Sound is **required**, not optional
- Include sound effects for at minimum: movement/crawling, fly collection, rain warning, rain active, death, score milestone
- Use the Web Audio API to generate sounds procedurally — no external audio files
- Sound should enhance game feel and provide audio feedback for critical events
- Include a mute toggle that is visible during play

## Procedural structure

- The wall should be effectively endless
- Use simple procedural chunking or repetition with variation
- No handcrafted level list is required
- The wall should contain route variety through things like:
  - safe but longer paths
  - more direct but stamina-expensive paths
  - fly detours
  - shelter locations that are not always directly above the player
  - surface zones that feel slightly different to traverse

## Difficulty ramp

Difficulty should rise gradually over time through a combination of:
- tighter shelter timing
- more demanding stamina management
- more tempting but riskier fly placements
- route layouts that require better planning under pressure

Do not let the difficulty ramp immediately become unfair or unreadable.

## Required UX outcomes

- The player should understand the goal quickly
- The controls should be readable without a long manual
- The first 10 seconds should make clear that:
  - you crawl on the wall
  - movement costs stamina
  - flies restore stamina
  - rain is dangerous
  - holes are shelter

## Required game states

- Start state
- Active play state
- Game over state
- Restart flow

## Visual direction

- Make it visually coherent and a little charming
- Simple shapes and lightweight art direction are fine
- Prioritize legibility and feel over asset complexity
- The wall should feel like a real traversable surface, not a generic background behind floating platforms
- Add visual juice: screen shake on death, particle effects on fly collection, subtle animations

## Critical mobile UI warning

The build must work on real phones, not just desktop responsive mode.

That means:

- mobile controls must be visible and usable on actual touch devices
- do not rely on a single brittle device-detection rule
- if touch capability is present **or detection is uncertain**, prefer showing touch controls rather than hiding them
- make touch controls large enough, contrasty enough, and placed safely enough to be usable during active play
- verify that the start screen, active HUD, and game over screen do not obscure or disable mobile controls incorrectly
- do not ship a build where the game loads on mobile but the player cannot move because controls failed to appear

Treat mobile controls as a **hard requirement**, not an optional polish item.

## Playtest requirement (MANDATORY)

Before delivering, you must **actually play the game** in a browser environment and validate it end-to-end:

1. Open the game in a real browser (use a headless browser or Playwright/Puppeteer if needed)
2. Play through a full session from start to game over
3. Verify visually that:
   - the wall renders correctly with no visual glitches
   - the spider animates and moves smoothly
   - flies appear and can be collected with visual/audio feedback
   - rain warning is clearly visible and understandable
   - rain sweep works and kills the spider if exposed
   - shelter holes protect the spider during rain
   - stamina bar drains and is readable
   - score increases and displays correctly
   - game over screen appears and restart works
   - sound effects play for all critical events
   - mobile controls are visible and functional
4. Check for performance issues: the game should run at a stable frame rate without janking
5. If you find bugs, fix them and playtest again
6. Do not deliver a game you have not personally played through

This is not a box-ticking exercise. You are the first player. Play your game. If it's not fun, fix it.

## Internal team checklist

Act as if you are coordinating the following disciplines internally:

- Director: protect the core fantasy and keep scope honest
- Game Designer: make the loop clear, tense, and replayable
- UI/UX: make the controls, stamina, flies, and danger states readable on desktop and mobile
- Artist: give the game a coherent visual identity using simple means
- Sound Designer: make the game sound good with procedural audio
- Game Developer: implement robustly and keep the code understandable
- QA: actively test broken states, mobile layout, restart flow, and touch input clarity
- Playtester: actually play the game and report what's fun and what's not

You may and should spawn subagents, helper agents, or parallel internal workers for these disciplines and/or for specific tasks if your environment supports that workflow.

Use them pragmatically:
- decompose work when it helps quality or speed
- keep one coordinating director-level plan
- integrate the outputs into one coherent final build
- do not use delegation as an excuse to stop early or return partial work

Do not roleplay these disciplines in the final answer. Use them to improve the work.

## Deliverable format

When you are done, deliver:

1. The finished game files
2. A short build summary
3. A short test summary (including playtest notes — what you observed while playing)
4. A short list of assumptions or limitations, if any remain

Do not say that more iterations are needed.
Do not ask me what to do next.
Finish the game and deliver it.
```