08 · CONTINUE?: a playable arcade cabinet that doubles as a shop website
CONTINUE? is a made-up arcade, repair bench and game shop in the invented town of Coinbrook, CT. The whole page is dressed as a CRT, and the hero is a real, working shooter called Glitch Raiders, drawn through a WebGL tube shader. What makes people stop is that the thing at the top of the page is a game, it plays itself in attract mode, and it has a high score table that remembers you.
Inspiration
The builder borrowed ideas from several tools on the list and then added a lot.
- Cult UI: the idea of a shader-heavy hero, plus the Pixel Heading and LightBoard looks (here, Press Start 2P headings with hard offset shadows and a chasing-bulb marquee).
- Aceternity UI: Noise Background and Pixelated Canvas became the channel-change static between sections. Encrypted Text and Text Generate became the typewriter dialogue at the repair bench. The Keyboard component became the on-screen control deck under the cabinet.
- Magic UI: Terminal became the boot screen, and Confetti became the coin rain when you enter the Konami code.
Added on top: a complete game with attract mode and a demo AI, a synthesized three-channel soundtrack, and page sections built as game screens (character select, RPG shop, item shop, save files).
Visual direction
- Palette: a fixed 16-colour array on CRT black
#07070d. Navy#14142band#2a2a52carry panels. Phosphor white#f2efdc, red#ff3d4d, yellow#ffd84a, green#5ee06a, cyan#3fd4ff, purple#9a5cffand blue#3f6bffdo most of the work. - Fonts: Press Start 2P for display, VT323 at 22px for body (20px on phones).
- Motion: everything steps. Blinks use
steps(1), the toast slides in five steps, tiles bob in two. The one smooth exception is the power-off collapse, which uses a cubic-bezier on purpose. - Layout: the cabinet sits in the middle of a three-column hero, with high scores and open/closed status on the sides. Borders are chunky notched boxes made from four offset shadows.
- Signature moments: the POST-style boot text with a RAM counter; the cabinet with marquee, bezel and a clickable D-pad and A/B buttons; "CH 02" style OSD plus static burst when you scroll to a new section; the Degauss button that wobbles and hue-shifts the whole page; the power button that collapses the screen to a line and then a dot; a live neon OPEN/CLOSED sign driven by the visitor's clock; pixel hearts for the days of the week.
References
- Cult UI, https://www.cult-ui.com: shader-heavy hero, Pixel Heading, LightBoard styling.
- Aceternity UI, https://ui.aceternity.com: Noise Background and Pixelated Canvas (static), Encrypted Text and Text Generate (typewriter), Keyboard (control deck).
- Magic UI, https://magicui.design: Terminal (boot screen), Confetti (coin rain).
CSS Peeper, Refero, 21st.dev and the gradient tools do not visibly show up here.
Why these choices
A retro arcade site should feel like a tube, so the full shader is spent only on the game. The rest of the page gets a light CSS scanline layer with a lower z-index than the screen, so the cabinet is not double-scanlined and body text stays readable.
All art is drawn in code from pixel grids and rect lists, so no image can 404 and everything scales at whole-number multiples. The one outside dependency is Google Fonts, which falls back to monospace.
The hardware details (cap kits, 72-pin connectors, light guns needing tubes, 4-way sticks) are there because the audience for a retro shop will notice a wrong detail.
Trade-offs: the sound is off until clicked, which avoids autoplay problems. The game pauses when scrolled away, hidden or blurred, and it only captures keys during play, so the page still scrolls. There is a no-WebGL fallback that draws the raw canvas with CSS scanlines, and a reduced-motion path that kills blinks, static and shake. Touch gets a tap-to-start rule and an on-screen deck.
Who this kind of site is for
It wins for arcades, barcades, retro game shops, repair shops, game-night events, indie game launches and conventions, anywhere the audience already loves the aesthetic. It is the wrong call for a law firm, a clinic or anything where the visitor wants a fast, calm answer. Dense body copy in a pixel world also tires people on long pages.
How to make it
Stack and key techniques
- One HTML file, about 1,380 lines, no build step, vanilla JS in one IIFE.
- Glitch Raiders, about 320 lines: fixed 60 Hz update on a 320x240 canvas, formation shooter with three enemy types, Bezier entry paths, dive attacks, a boss every fourth stage, four power-ups (double, rapid, shield, 1UP), attract-mode AI that dodges and aims, a top-five table with initials entry saved to localStorage.
- CRT shader, about 80 lines of raw WebGL2: curvature, sharp-bilinear sampling, two-ring bloom, chromatic aberration, scanlines that adapt to display density, aperture grille, vignette, flicker, a rolling bar, glass reflections, degauss wobble and static.
- Chiptune engine, about 70 lines of Web Audio: square, triangle and noise channels, 18 sound effects, a looping 32-step tune.
- Font atlas: Press Start 2P rasterised at 4x and thresholded so in-game text is hard-edged.
- Page widgets, about 400 lines: boot screen, cabinet select, RPG menu with a running ticket, item shop, expandable save files, animated pixel map, Konami code, power-off animation.
The prompt
Build a single-file website (index.html, no build step, no images, no frameworks) for CONTINUE?, a fictional arcade, repair bench and game shop in the made-up town of Coinbrook, CT. Everything lives inside a CRT. The hero must be a playable cabinet.
Visual direction: a fixed 16-colour palette on CRT black #07070d (navy #14142b, phosphor white #f2efdc, red #ff3d4d, yellow #ffd84a, green #5ee06a, cyan #3fd4ff, purple #9a5cff). Press Start 2P for display, VT323 at 22px for body (Google Fonts, monospace fallback). Stepped animations only: blinks, bobs, static bursts, no smooth easing except the power-off collapse. Chunky notched pixel borders made from offset box-shadows. All art drawn in code from pixel-grid strings and rect lists.
Hero: a three-column layout with the cabinet centred (marquee with chasing bulbs, bezel, screen, control deck with clickable D-pad, START and A/B buttons) and high scores and live open/closed status at the sides. The game, Glitch Raiders, is a formation shooter on a 320x240 canvas at fixed 60 Hz: three enemy types, curved entry paths, diving attackers, a boss every fourth stage, four power-ups, an attract-mode AI that plays when idle, a top-five score table with initials entry saved in localStorage. Render it through a raw WebGL2 CRT shader (curvature, scanlines, aperture grille, bloom, chromatic aberration, vignette, flicker, rolling bar, glass reflection, degauss wobble, static). Fall back to the plain canvas if WebGL fails. Add a chiptune engine (square, triangle, noise, about 18 effects and a looping tune), off until the user clicks Sound.
Page: a boot/POST screen in a terminal style; a character-select grid of eight cabinets with stat bars; an RPG-style repair menu with a typewriter dialogue box and a running ticket total; an item shop; "Load Game" save files for hours, location (animated pixel map) and events, with a neon OPEN/CLOSED sign from the visitor's clock; channel-change static and an on-screen "CH 03" overlay between sections; Degauss and Power buttons; a Konami code that gives 30 lives and rains pixel coins.
Content: use accurate hardware details (cap kits, 72-pin connectors, light guns needing tubes, 4-way sticks). State clearly that the business is fictional.
Rules: keys must only be captured during play, so the page scrolls normally otherwise. Auto-pause when the cabinet scrolls out of view, the tab hides or focus leaves. Support touch, reduced motion and phone widths.
Verify: serve the file, take screenshots at several scroll stops on desktop and phone, check the console for errors, play a game with keys and with touch, test game over and initials, then fix and repeat.
Build notes
- A visibility observer reading a stale entry froze the game loop on a busy machine. The fix uses the newest entry in the batch (line 1037).
- Click, not pointerdown, starts the game, so a finger scrolling past does not launch it.
- Scanline mode switches by display density (
hiin the shader). On a 1x display it falls back to alternating output rows, a flatter look. - Pausing releases held keys, and leaving mid-initials auto-saves the score, so nothing sticks.
- Untested by the builder: the audio was never listened to, frame rate on a real GPU is unmeasured, and the boss and later stages were not played to a kill.
Stepping down: what you would likely lose
This is an informed estimate, not a measurement. No public benchmark compares these exact models on one-shot frontend work, so the claims below rest on the spec tiers and extrapolation.
| Feature | Opus 5.5 (likely outcome) | Sonnet 5.5 (likely outcome) |
|---|---|---|
| Glitch Raiders game logic (formations, dives, boss, power-ups) | Likely does fine, with small balance problems | Likely attempts it with bugs, such as dive enemies that never return or bullets that miss the boss hit box |
| Attract-mode AI | Likely does fine | Likely simplifies it into a mover that dodges poorly or never fires |
| CRT shader, multi-effect | Likely attempts it with small errors, such as scanlines that moire at some sizes | Likely simplifies it to scanlines plus vignette, losing bloom, rolling bar and degauss |
| Density-adaptive scanlines and sharp-bilinear sampling | Likely simplifies it away | Likely simplifies it away |
| Chiptune engine and tune | Likely does fine, though untuned by ear | Likely does fine for effects, with a thinner or mis-timed tune |
| Hard-edged font atlas for in-game text | Likely does fine | Likely uses plain canvas text and gets blurry edges |
| Page widgets (boot, RPG menu, saves, live sign) | Likely does fine | Likely does fine, with fewer secondary touches like the map animation |
| Input edge cases (key capture, auto-pause, touch) | Likely attempts it with a bug, such as keys staying stuck after tab blur | Likely attempts it with bugs, such as scroll being blocked or a game launching on a scroll tap |
Rough overall estimate, as a judgment call: Opus 5.5 likely keeps roughly 80 to 90 percent of the visual and playable impact in one pass, and Sonnet 5.5 likely keeps roughly 60 to 75 percent. The Fable to Opus gap looks small here, since most of this is careful but ordinary code. The Sonnet gap would show up late in the file, in drift and dropped detail.
What would close the gap: a browser screenshot-and-playtest loop, plus splitting the work so the game, the shader and the page are built as separate steps and then merged.