312 games
Fifteen tools, two decisions. Pick an engine that matches the game you want to make, then pick whichever assistant keeps you shipping. Most makers here credit two or three, which is why the counts below add up to more than the number of games.
Start from the game. A 2D game with physics wants Phaser. A 3D scene wants Three.js. One mechanic and a hard load-time budget wants nothing at all. Vanilla canvas beats every framework on a small game.
Exports are not free. Godot and Unity both reach the browser, and both arrive with a payload. If somebody has to wait thirty seconds after clicking a link, most of them will not.
The assistant is the smaller choice. It changes how fast you work, not what the game can be. Pick the one that fits where you already write code and stop optimising it.
Used to write, review and debug code. Every credit here is self-reported by the maker at submission. It is a note about the process, not a quality signal, and the games are ranked by the same votes as everything else.
Agentic coding in the terminal.
Games built with Claude Code, the terminal agent that edits files, runs the dev server and fixes its own bugs. Popular for larger projects that outgrew a chat window.
AI-native code editor.
Games made in Cursor. Fast iteration on existing codebases, which is why you see a lot of polished follow-ups here rather than first prototypes.
OpenAI's assistant.
Games written with ChatGPT's help, often single-file HTML games that started as a prompt and grew from there.
Anthropic's assistant, used to write and debug game code.
Games where Claude did the heavy lifting on code. Makers describe the mechanic, iterate in conversation, and ship the result here.
Inline completion in your editor.
Games built with Copilot riding shotgun. Usually hand-architected with AI filling in the tedious parts.
Generate UI from prompts.
Games whose interface came out of v0: menus, HUDs and shells generated fast so the maker could spend time on the actual mechanic.
What actually draws the pixels. This is the decision that shapes load time, bundle size and how much of the game you write yourself, so it is worth more thought than the assistant question.
WebGL 3D for the browser.
3D browser games built on Three.js. Everything here renders with WebGL and runs without a plugin or download.
2D HTML5 game framework.
2D games built on Phaser, the workhorse framework for HTML5 games, with physics, sprites and input handled for you.
No engine, just the 2D context.
Games written directly against the Canvas API with no engine at all. Tiny bundles, fast loads, total control.
Component-driven game UI.
Games built as React apps, common for card games, idle games and anything more UI than simulation.
Open-source engine, exports to web.
Godot games exported to HTML5. Full engine features, playable straight from a browser tab.
Fast 2D WebGL renderer.
Games rendered with PixiJS, chosen when the priority is throwing a lot of sprites on screen at 60fps.
Exports to WebGL.
Unity projects exported to WebGL and published for the browser.
Compiled, minimal runtime.
Svelte games. The small runtime makes it a favourite for jam entries where load time matters.
Live counts across every published game.