(fable52.games)
This feels like it defeats the purpose of the site.
The other touch controls work, like the aim, reload, fire and touch-dragging on the right side to look around.
Would love to archive and feature it on Fable52.games with full credit and a link back to your site/post. If you have the single-file `.html` build handy, feel free to drop it via https://fable52.games/submit (takes 10 seconds, no signup needed) and I'll approve it right away!
It seems like the full screen button and mobile support is a bit lacking. Can you fix that?
Even if that were appealing, why wouldn't I just produce my own low effort gameslop, at least then I know it would actually correlate with my own tastes and preferences.
1. Because they still don't know how, even with claude. 2. Because they don't want to waste precious tokens if they can get the results for free.
Hope that helped.
that was fast :)
I'm upgrading the Workers plan and moving the raw `.html` sandbox assets directly onto a cached R2 public edge route right now so the Worker doesn't have to proxy every 1.4MB payload. Should be back up smoothly in 2 minutes—thanks for flagging!
Over the past few days, my feed has been flooded with impressive 3D and 2D games built autonomously by Claude Fable 5.2 from a single prompt—like Felix Rieseberg’s 8-hour build "Saltline" (a 1.4MB 3D container-port FPS) and Kevin Ngo’s "What the Water Keeps".
What fascinated me structurally about these builds is the constraint: everything ships inside a single, self-contained .html file with zero external assets. The 3D geometry is generated procedurally via WebGL/Three.js, textures are drawn onto offscreen 2D canvases at runtime, and rain/gunfire audio is synthesized live using the Web Audio API.
However, actually trying to play and study them was frustrating: 1. Raw GitHub links require downloading the .html locally or routing through third-party previewers. 2. Shared Artifact links often hit rate limits, require logins, or stall on heavy WebGL initialization. 3. Reading a 1.4MB single-file source alongside the original prompt and running game wasn't straightforward.
So I built https://fable52.games as a fast, zero-setup browser arcade and source inspector for these single-file builds.
How it works under the hood: - Strict Sandboxing: Running untrusted community-submitted HTML/JS in a browser is an obvious XSS hazard. Every game is served from an isolated endpoint with strict headers (`Content-Security-Policy: sandbox allow-scripts allow-pointer-lock;`) inside a sandboxed iframe without `allow-same-origin`. Game scripts can lock the mouse for 3D FPS controls and compile WebGL shaders, but have zero access to the parent site's DOM, cookies, or storage. - Side-by-Side Inspection: For each build, you can toggle directly between the live WebGL canvas, the exact one-shot/recreation prompt used to generate it, and the raw single-file HTML source (or download the .html to tinker locally). - Stack: Built on Cloudflare Workers (Next.js / OpenNext), D1 (SQLite) for metadata and build stats (autonomous build time, file size, token/cost estimates), and R2 for serving the raw .html files with zero egress fees.
A quick note if you're on mobile: most of the 3D FPS builds (like Saltline and SUBLEVEL 07) rely on the Pointer Lock API and `WASD` + Mouse controls, so they are best experienced on a desktop browser.
It's completely free, requires no login, and has an open submission page if you've been experimenting with single-file HTML games yourself (under 10MB) and want an instant sandbox link to share.
I’d love to hear your thoughts—both on the site itself and on where you think this "procedural single-file HTML" pattern is headed!