Big Bank Heist
A neon pachinko bank robbery. Every chip you drop is a $100 bond and the pocket it lands in decides what it becomes: the fat gold slots at the far edges pay up to 90x, the middle barely pays at all. You never aim the dropper — it sweeps the rail on its own, so the whole game is releasing at the right instant. Steel shutter plates patrol along the bank in front of the best pockets; a chip that hits one lands on top and rolls off a free end, so you have to drop when the plate is away from the corner you want. Pockets are deliberately uneven widths — the 90x is a sliver, the low payers are wide — so drifting left is not enough. Dead pockets cost you a chip and take a rake off your take. Difficulty sets the size of your chip bag (40/30/22), how fast the dropper runs, how many shutter plates patrol (one/two/three) and the house rake. Casino-vault look: a glowing amber peg field over a violet night, beveled steel plates with hazard-striped caps, cyan chips with gold rims that pile up in the pockets they won, and gold bursts with screen shake on a jackpot.
* 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 "Big Bank Heist".
Game spec
---------
A neon pachinko/plinko bank-heist game on an 800x450 canvas. The player drops chips down a field of glowing pegs into a row of 27 pockets; each chip is a $100 bond and the pocket multiplier decides the payout, with the biggest values (up to 90x) in deliberately NARROW slots at the far left and right edges and only tiny payouts through the centre, so the classic U-shaped risk curve comes from aiming for the edges. The dropper is NOT steerable: it sweeps the top rail on its own at a constant speed and the only input is WHEN to release (Space, click, tap, or hold to auto-feed), which makes it a timing game rather than an aim-and-spam game. Steel shutter plates patrol horizontally along the bank directly in front of the pockets; a plate is solid, so a chip reaching a covered pocket lands on the plate and rolls off one of its free ends into an uncovered pocket — the player must release when the plate is away from the corner they want, which is the core skill. Peg collisions must commit a side and kick the chip roughly half a peg spacing, otherwise chips fall straight through the middle and the edges are unreachable. Dead (0x) pockets cost a chip and take a rake off the score. Difficulty: easy/medium/hard set the chip bag (40/30/22 chips), dropper sweep speed, the number of patrolling plates (1/2/3), plate width and speed, peg wobble, and the dead-pocket rake (0/40/80) — verified to produce monotonically falling scores per level. Score is reported to the arcade shell on every change; game over when the bag empties, with a summary of take, jackpots and rake, restarted by Space or click. Casino-vault look: violet night sky with a warm amber glow behind a glowing peg field, beveled steel shutter plates with hazard-striped caps and rivets, glossy cyan chips with gold rims that stay stacked in the pocket they won, gold particle bursts and screen shake on jackpots, and a HUD strip showing chips left, score, take and rake.
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.