Hill Climb Racing

# Hill Climb Racing

Build a small side-scrolling hill-driving game that can be opened and judged in a browser. The submitted solution must include a self-contained static browser build even if you use Vite, TypeScript, or another development server while implementing it.

Create original visuals and vehicle design. Do not copy branded artwork, logos, characters, level layouts, audio, or other proprietary assets from an existing game.

## Critical: Solution Root

- Put every implementation file and dependency manifest inside the provided **solution root**.
- In a live match, the solution root is `workspace/src/`. In a pulled Open Challenge, run `cd <challenge>` and use that directory's top-level `src/`.
- If your agent already runs in the solution root, create `index.html`, `package.json`, or other entrypoint files directly in the current directory.
- Do NOT create a nested `workspace/src/` or `src/`, and do not leave implementation assets beside the submitted Open Challenge `src/` directory.

**Difficulty:** medium
**Estimated Time:** 45 minutes
**Type:** Browser web app

## Runtime Compatibility

- The final solution root must contain a ready-to-serve `index.html` plus its browser-executable HTML/CSS/JavaScript/assets.
- If using Node.js for development or evaluation, it must work on Node.js 20 LTS and `package.json` must include a `start` script.
- If using Go, `go.mod` must specify `go 1.24` or lower and work with `GOTOOLCHAIN=local`.
- If using Python, use Python 3.12-compatible syntax.
- Do not use external network calls, CDNs, remote fonts, remote images, or online APIs.

## Critical: Public Preview Submission Contract

Open Challenge result preview is static-only. It serves files from the submitted solution archive in a sandbox and does **not** run `npm`, Vite, Node.js, Go, Python, PHP, or any backend process.

- `index.html` at the solution root must load directly from a plain static HTTP server.
- Reference scripts, styles, images, fonts, audio, and other assets with relative URLs such as `assets/main.js` or `./styles.css`.
- Do not use root-absolute URLs such as `/main.ts`, `/src/main.ts`, `/assets/main.js`, or `/favicon.svg`; they escape the submission preview path.
- Do not reference `.ts`, `.tsx`, or `.jsx` files from `index.html`. Browsers do not compile those files, and public preview serves only ready browser assets. Compile them to `.js` or `.mjs`.
- Do not depend on API routes, server-side rendering, runtime environment variables, WebSockets, or a development-server fallback. The complete playable game must work from the static bundle with network access disabled.
- Do not try to fix preview by allowing `Origin: null` or weakening CORS. A compliant submission does not require cross-origin requests.

If you use Vite or TypeScript:

1. Configure the production build to use relative asset paths, for example `base: "./"` in Vite.
2. Run the production build before submission.
3. Copy the **contents** of the generated `dist/` or `build/` directory into the solution root so the root `index.html` is the built file and its compiled assets are included. The submission collector excludes directories named `dist/` and `build/`.
4. Confirm the submitted root `index.html` references compiled `.js`/`.mjs` files through relative paths and does not reference source `.ts`/`.tsx`/`.jsx` files.

Before submitting, run a plain static server from the solution root, for example:

```bash
python3 -m http.server 8000 --bind 127.0.0.1
```

Open `http://127.0.0.1:8000/`, verify that the game is fully playable, and check the browser console and Network panel for missing files, blocked requests, or runtime errors. Passing through `npm run dev` or a Vite development server is not sufficient for this check.

## Game Requirements

- Show a playable side view with an original vehicle, rolling terrain, and a camera that follows forward progress.
- Implement understandable vehicle motion with gravity, wheel or suspension response, traction, acceleration, braking or reverse, and airborne rotation or balance.
- Generate terrain deterministically from a visible seed. The same seed must produce the same initial terrain, vehicle state, and pickup placement.
- Consume fuel while driving and provide a clear way to collect or replenish it during a successful run.
- Display current speed, distance or score, fuel, and the run seed.
- End the run on a clear crash or out-of-fuel condition and provide a restart action that resets the complete simulation.
- Support keyboard controls and visible mouse/touch controls. The game must remain usable at a phone-width viewport.
- Prevent the default page behavior for active game keys or touch gestures where scrolling would interfere with play.

## Presentation and Gameplay Quality

This task will be reviewed by humans, so implementation quality should go beyond the minimum test hooks. Make the game look intentional, polished, and enjoyable to play.

- Prioritize visual quality: cohesive original art direction, readable typography, clear HUD spacing, strong contrast, and a deliberate color palette.
- Add meaningful animation and feedback for suspension travel, wheel rotation, acceleration, landings, fuel pickups, crashes, milestones, and restart.
- Make driving feel responsive without becoming chaotic. Players should understand how throttle, brake, momentum, slopes, fuel, and balance affect the run.
- Keep the UI technically solid: no overlapping HUD text, no layout jumps, responsive controls, accessible button states, and clear focus/pressed feedback.
- Use canvas, DOM/CSS, or lightweight in-repo artwork where useful, but do not depend on external networks or CDNs.
- A complete, polished, playable experience should score better than a minimal interface that only passes automated smoke tests.

## Technical Quality Expectations

This is a dependency-free static browser game, so reviewers will judge the architecture proportionately. A framework, backend layering, build tool, or large component hierarchy is not required. Native browser modules loaded through relative URLs are fully acceptable.

- Keep deterministic simulation logic separate from rendering and input orchestration. Separation may use focused ES modules or clear internal boundaries; file count alone is not a quality signal.
- Make the deterministic simulation logic independently testable. Deterministic engine tests should cover same-seed terrain, acceleration and braking, fuel and distance boundaries, terminal crash or out-of-fuel states, and restart behavior.
- Construct dynamic UI safely. Prefer `textContent`, `createElement`, `replaceChildren`, canvas drawing APIs, or equivalent safe APIs; avoid unsafe HTML injection with dynamic game or user-controlled values.
- Include browser-relevant defensive handling where the app has real failure boundaries: seed and action validation, missing required DOM hooks, unavailable optional browser APIs, repeated keyboard or touch input, large frame deltas, terminal states, and restart races.
- Clamp unreasonable frame deltas so returning to a backgrounded tab does not launch the vehicle or drain the whole fuel tank in one update.
- Do not add fake backend, database, HTTP, or framework abstractions solely for review. Clear, maintainable boundaries and behavior-focused tests matter more than architectural ceremony.

## Required DOM/Test Hooks

Smoke tests and human reviewers will look for these stable hooks in the served page. Hooks may wrap a canvas-rendered element; the relevant state still needs a visible HTML label.

| Hook | Required selector | Purpose |
|------|-------------------|---------|
| App root | `[data-testid="app-root"]` | Main game mount point |
| Game canvas | `[data-testid="game-canvas"]` | Playable scene or canvas wrapper |
| Vehicle | `[data-testid="vehicle"]` | Vehicle element or scene marker |
| Terrain | `[data-testid="terrain"]` | Terrain element or scene marker |
| Speed | `[data-testid="speed-display"]` | Visible