Getaway City

Q8FMADE BY qwen3.8-flash-next

A GTA-style crime spree through a procedural night city, drawn as real 3D: jack any car that is slow enough to reach, take a job from the amber marker, then run the green one before the clock bites. Every crime raises heat — patrol cars swarm, foot cops chase you down the pavement, and a roadblock of vans parks itself across your escape until you break through. The garage is the only way to wash the stars off. Lose all your lives and the city keeps the change.

▸ CARTRIDGE SLOT · GETAWAY CITY
↗

* THE GAME RUNS IN A SANDBOXED FRAME — IT CAN’T SEE THIS SITE OR YOUR OTHER TABS. BEST SCORES STAY IN THIS BROWSER.

Cartridge promptTHE EXACT PROMPT THAT BUILT THIS GAME
Build a tiny browser game called "Getaway City".

Game spec
---------
A GTA-style open-city crime game rendered from scratch as true 3D on one 2D canvas: an 11x11 grid of procedurally built blocks with named districts, kerb props, a day/night sky and a projected third-person chase camera, all software-rasterised with no libraries. The player starts on foot and F jacks any nearby car that is slow enough to reach, so the whole city is the vehicle roster — sedans, coupes, hot rods, vans, patrol cars. Jobs spawn as an amber marker (courier run, front delivery, or a hot getaway at 1.55x pay): drive into it, then deliver to the green marker inside a distance-scaled time limit for pay plus an on-time tip, with a fresh job a few seconds after each one. Crime raises a heat meter into wanted stars up to the difficulty cap; patrol car count, speed and marksmanship scale with the stars, foot cops spawn on the pavement from two stars, heat only decays once no cop has line of sight, and from a per-level star threshold a roadblock parks two or three armed vans across your route until you break through. A garage trip resets stars, repairs the car, and tops up health, nitro and ammo for a cut of your cash. On-foot play matters too: walk into traffic to jack it, run people over, fire the pistol (J) from foot or as a drive-by, and use handbrake drifts (Space) and nitro (Shift) to shake a tail. C cycles three cameras while driving (hood, chase, cinema). Death costs a life — 4 easy, 3 medium, 2 hard — wasted respawns you at the garage, and running out of lives ends the run with a cash/jobs/top-speed/cars-jacked summary. Controls: WASD or arrows drive and walk, F jack or exit, Space handbrake, Shift nitro, J fire, C camera, M radio, R respawn, mouse drag to look, plus on-screen touch pad. HUD: cash, wanted stars, vehicle name, speed, armour bars, nitro meter, objective strip with a delivery timer, zone tag and a live minimap of jobs, cops and the player. Score is cash, reported to the shell on every change. Difficulty sets lives, star cap, cop count/speed/accuracy, traffic and pedestrian density, cop damage, pay multiplier, heat gain and decay, and the roadblock star threshold. Neon-night look: violet sky with a warm amber skyline glow, beveled HUD plates, headlight cones, tire marks, embers, screen shake, and synthesised engine, jack, crash and radio cues.

Hard constraints — the game will be embedded in a sandboxed iframe on a static gallery site, and a headless browser will screenshot it:

1. Output exactly ONE self-contained HTML file. All CSS and JS inline. Zero external requests: no CDNs, no external fonts, images, or sounds, no fetch/XHR/WebSocket. Any sound must be synthesized with WebAudio.
2. The iframe sandbox is "allow-scripts allow-pointer-lock" (plus an autoplay permission). So: no localStorage, cookies, or indexedDB (opaque origin — access throws); no popups, window.open, or navigation; no access to the parent page; alert()/prompt()/confirm() are silently blocked.
3. The playfield must be visible within 800 ms of load — that is when the screenshot is taken. No dead white screen. If there is a start screen, make it visually rich.
4. Controls: keyboard AND mouse must both work, plus on-screen touch buttons for phones. Call preventDefault() on game keys (arrows, space) so the page never scrolls.
5. The view is 16:9 and must scale to fill the viewport with no overflow or scrollbars.
6. Show a visible score. If the genre has a losing state, show a game-over screen with a restart (button and a key). Idle/clicker games skip game over but still need clear numeric feedback.
7. If you track a score, report it to the arcade shell so the player's best is remembered between visits: on every score change, call parent.postMessage({ source: "ai-arcade", type: "score", score: <number> }, "*"). It is safe to call it no matter what the parent does with it.
8. Keep it tiny: aim for under 400 lines, 60 fps, no frameworks. That 400-line target does not apply to 3D games — true 3D (a camera and perspective-projected world) or pseudo-3D (projected road/track, depth-sorted sprites) — which need their own software renderer and typically land at 800–1400 lines. The rest of this constraint still binds every game: 60 fps, no frameworks, no external assets, and no padding to reach a length.
9. Difficulty: the arcade shell passes the player's chosen difficulty as a URL query parameter. Read it with new URLSearchParams(location.search).get("difficulty") — the value is "easy", "medium", or "hard" (missing or unknown means "medium"). Make the three levels meaningfully different — speed, lives, enemy pressure, reaction time, whatever fits the genre; clicker/idle games with no losing state use starting resources and upgrade cost curves instead. Show the active level in the HUD. Without the parameter the game must be fully playable at its default (medium) tuning.

Return only the complete HTML file, no commentary.