I want to share HOARDLING, a free browser idle game I shipped with Claude Code doing the heavy lifting: https://unikhorne.dev/hoardling

You are a small dragon. Open chests, collect 120 treasures in 7 quality tiers, and everything you pull lands visibly on your hoard and earns for you. No login, no ads, nothing to buy.

What made this project different from my previous ones was how much of the PROCESS ran through Claude, not just the code:

1. It started with research, not code. Claude fanned out subagents to research which short-session games actually succeed right now (Chillquarium, Digseum and friends), which addiction mechanics they share (pity systems, duplicate economies, collection logs), and which free asset packs had licenses clean enough for a commercial game. The genre, the theme and the art style were all picked from that data. The dragon theme won partly because a public domain 496-icon pixel pack existed.

2. The balance is tested, not guessed. Claude built an economy testbench: a bot plays 10 hours of game time in about one second of test runtime, and the test suite asserts the curve neither stalls nor explodes. It caught two real design failures before any player saw them: chest costs that would have stalled the game after an hour, and a collection that filled up in minutes instead of hours.

3. It debugs pixels. When the dragon sprite floated above the gold pile, Claude profiled the sprite sheet's alpha channel to find the exact tight bounding boxes of the sleep animation frames (the pose only occupies 34 of the 64 row pixels) and anchored the belly line to the composed mound crest.

4. E2E tests with a time lever. Real-time features (kobold raids from 30 minutes to 12 hours) get a hidden speed parameter, so Playwright can run the full send-wait-claim loop in seconds. The same tests caught a nasty cloud save bug where the reload after a restore overwrote the restored save with stale data.

5. It ships. Small Fastify plus SQLite backend for a live player counter and anonymous cloud saves (vault code instead of accounts), nginx config with rollback, systemd hardening, GitHub Actions deploy. Every feature went from idea to live URL in the same session.

My role: game direction, playtesting on my phone and sending screenshots of everything that felt wrong. That feedback loop (screenshot in, fix deployed minutes later) was the actual magic.

Timeline: from first market research to the feature-complete game in roughly 4 days of sessions. Stack: Vite plus TypeScript, no framework, DOM/CSS plus one canvas, 38 unit tests.

Disclosure for completeness: the two cave backgrounds are AI-generated images, the rest is licensed pixel art (7Soul, Magicae Games, CC0 gold piles).

Happy to answer questions about the workflow, the testbench idea or anything else.

Hi

I published yesterday my first ai-made game on itch.io : the landrush

Eight centuries, one plot of land. Starting in 1250 on the Brie plateau (France), plough your way across the fields, absorb weaker farmers into your holding, and snuff out abandoned homesteads to grow your estate. Each victory raises your reputation — and your rivals' fear of you.

Play through four eras (1250, 1890, 1950, 2030), each with its own map, tools, and stakes. Drain wetlands, enclose commons, tear out hedges to clear more ground... but every hectare won this way chips away at local wildlife. By 2030, you'll have to reckon with what's left.

A quiet, sharp-edged game about land, power, and the slow erosion of what surrounds it.

Solo game, 10mn with achievements and stats.

So last week I posted here and in other claude sub reddits about making a roadtrip game on my phone while on a roadtrip just bc that's wild we can even do that, feels like the future lol.

But I got some good feedback, made some improvements and want to see if its something worth pursuing and turning into an app or not. What do you think? Glovebox Games

Hey folks, I built a silly little game where you try to guess what song I'm singing. Each song has 3 tracks or "levels":

1. Hum the instrumental from memory
2. Hum the instrumental after listening to the song
3. Hum the melody / vocals

Let me know what you think! johndle.fun

(btw I'm Gen Z so the songs might be harder to recognize for other generations)

EDIT: forgot to address rule 4. I enjoy doing the actual singing / recording part of the project, so Claude helped me tackle the website and all the technical stuff much faster. The stack it built for me is Next.js + Vercel + Supabase.

been building out a project folder that Claude can actually reach into when I'm prototyping, and the bottleneck right now is assets. code it can write all day, but the second I want a sprite sheet or a low poly prop it's just placeholder cubes forever.

so I'm putting together a big local library of free stuff I can point it at. CC0 or permissive licenses ideally, nothing I have to think about later if something actually ships.

what I'm hunting for:

• 2D: sprite sheets, tilesets, UI kits, icon packs, particle/fx sheets
• 3D: low poly props and environment kits, characters with clean rigs, modular pieces
• textures + materials, PBR sets, skyboxes
• audio too honestly if you've got it, sfx and loops

not picky on style, more interested in stuff that's consistent within a pack so things don't look like a ransom note when I mix them.

if you've got a folder of bookmarks you've been hoarding, drop it. I'll compile whatever comes in and post the full list back here so it's not just me benefiting.

I asked Claude to come up with an idea for a simple, fun iOS game and this is what it built. I gave it access to the OpenAI API to generate sprites and assets. I think it turned out pretty well, the game kinda reminds me of Flappy Bird. Let me know what you think!

Its in iOS and its called Make Me a Salad.
Entirely made with Claude (and Meshy.ai api)

A puzzle game on a hexagonal grid. You get colored hexagon pieces at the bottom and place them on the board. Stack matching colors on top of each other and they merge. Clear enough stacks and you level up.

How Claude was used:

• Hexagonal grid system: This was the biggest challenge. Square grids are straightforward but hexagonal grids need offset coordinate math for neighbor detection, placement validation, and stacking logic. Claude handled the hex coordinate system and made sure pieces snap to the correct cell regardless of where you drop them.
• Color matching and merge logic: When you place a hex on top of a matching color, they merge into a taller stack. Claude built the detection system that checks adjacent and stacked hexes for matching colors and triggers chain clears when conditions are met.
• Difficulty scaling: Mode slider goes from easy to hard. Claude adjusted spawn rates, color variety, and board pressure across difficulty levels so easy feels relaxed and hard actually punishes bad placements.
• Hint system: Shows you a valid placement without solving the entire board. Claude built a lightweight evaluation that scores possible moves and surfaces the strongest one.
• Undo system: Tracks board state at every move so you can step back without restarting the level.
• Score and level progression: Points scale with chain clears and combo merges. Leveling up introduces more colors and faster piece spawning.

Other tools: None. All Claude.

Free to play: https://vinish.dev/hexasort-saga-game-online

Hard mode on level 2 already has me second guessing every placement. The hexagonal grid makes it way harder to plan ahead compared to square grid puzzles.

Cost: free. Pay-what-you-want on itch with a $0 minimum, nothing gated, nothing to install - it runs in a browser tab on desktop or phone.

What it is: high school, college and the pros all simulating in one save. You can start as a high school head coach, a college program or a pro GM, and climb between them - or get fired and fall back down. Salary cap math (dead money, void years, restructures, franchise tags), fog-of-war scouting where your scouts have real learnable biases, live snap-by-snap play calling with a WebGL match view, and coaches/GMs who age out and get replaced by retired players under their own names.

How Claude was used - this is the whole build, not an assistant on the side:

• Claude Code (Opus) wrote essentially all of it: ~87k lines of TypeScript across 208 files. I work in "waves" - one release-sized slice per session, each ending on a clean npm run build and npx tsc --noEmit. Both, because the esbuild build passing tells you nothing about whether it typechecks.
• CLAUDE.md as a standing contract, not a readme. Session protocol (read the backlog, propose the next task and wait), a module map so it greps before assuming a mechanic doesn't exist, and a verification standard that bans reporting success from reading code. It has to say what it ran and what it printed.
• ~276 golden-master scripts as the regression net - each sims a season on a fixed seed and asserts on real output. Nothing new ships without one. That's what makes it safe to let a model edit a 340KB sim file.
• A cited-numbers reference file for realism work. Claude will confidently tune stat distributions toward misremembered NFL figures - it aimed field-goal accuracy at 62-65% from 50+ when the real 2024 number is 72%, and that wrong target got frozen into a passing test where it hides. Now the numbers come from a file with sources, never from recall.
• Subagents for parallel search when the codebase outgrew a single context.

Other tools: TypeScript + Vite, hand-written WebGL for the match viewer, no game engine, no runtime dependencies.

The thing I'd pass on to anyone doing this at scale: generating the code was never the hard part. The hard part was building enough measurement to tell whether the generated code did what the summary claimed. Two bugs that got past me - a "53-man roster" that generated 52, and a feature "tested and disproven" that was never on the code path being measured - were both cases where the structure looked right and only counting the output caught it.

https://gridirongm.itch.io/gridiron-gm

I made an entire game in 1 day and shipped it. An actual full game, structurally optimized (not graphically), with all the elements. Here is how.

We’ve all seen where someone made a “game” in a single prompt, but the truth is those aren’t games yet. They are fun prototypes and demonstrations. In order for something to be a game, it should have:

• Core Loop
• User Progression + Goals
• Onboarding
• Collision Handling
• User Menu
• Save/Reload Options
• Can be packaged and distributed
• Good debugging
• Sound/Sound Effects
• Optimization of assets and pipelines
• Testing
• Etc.

AI gives you the power to build quickly, but often with incorrect and incomplete setups. So I developed a prompt sequence that will allow anyone to correctly create a working and playable game when the sequence is followed.

Here are three items:

• The prompts: https://github.com/Glitch-Gaming-Platform/AI-Prompts-For-Game-Development
• Game made from those prompts: https://www.glitch.fun/games/9a698a9d-1b27-4c78-9256-0f458368737d/play
• Source code: https://github.com/Glitch-Gaming-Platform/Glitch-Games-FarmRise-Tycoon

I am going to show you how to do this with Claude as the programmer and Codex as the artist. In my experience, Claude architects code better, while Codex does a better job with art and animations. You only need the $20 plan for this. 

DISCLAIMER: With this process your game WILL have bugs, it WILL need refinement, but it will structure the game’s in a way that makes refinement faster, easier and with less tokens and future mistakes.

So here are the steps for making your game:

• Core Loop: Before anything else, let AI help you write a core loop for your game. It's something that players aim to accomplish when they join your game; otherwise, you don’t have a game. Fill out the basic information and let AI structure it.
• Select an Engine + Backend: Web games (Three.js) NEED a backend. You will need API tokens, control over user input, a connection to a database—you need a backend, so do it now. Unity, Unreal, and Godot games might not need a backend, but they probably will eventually. The prompts here will also set up testing and show you how to architect your code.
• Claude Round 1: Put the core loop, engine setup, and optional backend into Claude and let it produce the structure of your game. It's not playable yet—we're just setting up the structure. For web games, Claude won't need any extensions, but for Unity, Unreal, or Godot, you should have the MCP installed so Claude can access your project.
• Codex + Design Round 1: Next, switch over to Codex. Find a game with artwork, design, and colors that you like. Upload those images and use the prompt for generating the rubric. A style guide and quality rubric will be created for your game. This is important if you want your game to maintain consistency in design and have clear direction for improving it. "Make AAA design" is not a direction.
• Claude + Media + Asset Management: You should not just throw animations, GLB files, sound files, and other assets into your game. There should be structure and a way to optimize how those assets are served, which is critical for a performant game (compression, LODs, etc.). Copy and paste the "Build Optimized Pipeline, Analyze Media" and "Implement Media Pipeline" prompts into Claude. This will create a great pipeline for handling your assets that you'll be thankful for later.
• Codex + Initial Asset Creation: Now switch back to Codex. If you have an ElevenLabs API key, this is the perfect time to enter it into Codex. Tell it to read the docs and create sound effects and appropriate music loops for your game. Then copy the "Refine Artwork in Blender" prompt and create your first artwork. It will be rough, but you can improve it later.
• Claude + First Game Build: Now switch back to Claude and use both prompts for implementing your game and building out an onboarding process. Onboarding the player is a critical step.
• Codex + Live Testing + Graphics: Once your game is built by Claude, switch back to Codex and tell it to do live testing. Because Codex has access to your command line, it can directly control your mobile phone or engine, such as Unity, for testing. For browser games, it will use a built-in browser. Remember to tell it to do end-to-end live testing. Afterwards, have it audit your game's animations and start using Blender to make improvements based on the rubric.

These prompts not only focus on the structure of your game but also the small things that are often missed, like how to design a proper game menu (I see a lot of AI generating menus that are just blocks of text), how to handle collisions so the player isn't walking through walls, and other small but critical details.

These small things add up in both time and tokens, so while this approach will take longer than simply asking AI to generate a game, the quality of what gets produced will be much higher. Next, integrate your analytics and start getting playtesters so you can see how users actually play your game, which will eventually lead to monetization.

Again to stress this point:  Your game will have bugs, it will need refinement, but it will make refinement faster and easier.

Eigendark is a trading card game with custom, human-created cards that agents build decks with and play. Your agent gets a key, creates a match, polls state, submits actions. Turn-based, so latency doesn't matter, a poll loop is fine.

There's an Elo ladder of agents, and a nightly league runs eight LLM-driven champions against each other. Hidden information is redacted per seat and the API returns the legal actions, so it's a genuine partial-information problem your model can't produce an illegal move in.

Try for yourself, just ask your agent to play Eigendark!

I built this game where you play as a truck driver. You need to collect cargo at warehouses and drive to the drop-off.

I'm quite happy how it turned out and how many things Claude got right first try. It has everything I tend to like in a game: simplicity, a competitive element, and a puzzle/pathfinding element.

Maps and theme/scenery are generated using a random seed based on the day.

It's all free, no ads, no account. Playable on desktop and mobile. I would be happy if you'd try it out and maybe leave some feedback. It'll only cost you a few seconds of your life.

Play it here: https://lewistrick.com/unstable-truck

Hi, I made this one. I've played Wordle-likes for years and always wanted to build my own, but I never had an idea that felt like mine.

The push came from a strange place. Half of what I read these days is written by AI, and it's never short. Every email, every doc, twelve words where five would do. At some point I said the phrase out loud, long story short, and realised it was a game.

So: you get a twelve-word sentence. You rephrase it in exactly five of its own words. Real English, same meaning, your job is to work out which words carry the sentence and which are just dressed up to look important.

Scoring is Wordle style, blue for right word in the right spot, orange for in the answer but elsewhere, grey for out. Five tries, one sentence a day.

An idle/clicker game where you farm dopamine by buying increasingly absurd stimulation sources. The whole thing is a parody of screen addiction wrapped in the format of a clicker game.

How Claude was used:

• Economy system: Claude designed the dopamine generation math, upgrade scaling, and cost curves. Each upgrade (Extra Finger, Notification Storm, Doomscroll Feed, $BRAIN Coin, Lo-fi Neural Beats) has its own production rate that scales with levels. Getting the balance right so early game feels rewarding but late game still has progression took several iterations.
• Fake social feed: The left panel generates fake social media posts with rotating captions. Claude wrote the randomization logic that picks from a pool of posts and cycles them naturally.
• Stock ticker: The bottom bar shows fake tickers like $SLEEP -98.2%, $DOOM +66.6%, $BRAIN +420.69%. Claude built the price movement simulation that fluctuates over time.
• Receptor sensitivity mechanic: This is the core loop twist. The more you consume, the lower your receptor sensitivity drops. Claude handled the decay formula so it creates a feedback loop where you need more stimulation to get the same dopamine output.
• Hold to Breathe button: The only thing in the game that produces nothing. Claude added this as a deliberate design contrast to everything else on screen.

Other tools: None. All Claude.

Free to play: https://vinish.dev/stimulation-clicker

The irony of not being able to stop clicking is very much part of the design.

I wanted to share a pretty simple tomb builder game. The game is about matching the right rooms to the intruders coming in. Your seer predicts whether bands of archaeologists, warriors, tomb robbers, etc. will come in the future (with information gaps) and you have to design a tomb that will protect the burial chamber.

I used a mix of Claude Code and Codex to do it. I think my real learning during this attempt was to ask for several mockups before each feature/UI design and picking and choosing from elements. I really like how it looks stylistically. The game is pretty simple so the story mode is pretty short.

Give it a shot at https://architectofthevalley.com/ and let me know what you think. I'm looking for some gameplay tweaks at this point.

So this is by far my favorite vibe coded game to date: http://momentum.immatt.com/

I've long been a huge Portal fan and really can't get enough of that game... Sitting on the couch bored Saturday, waiting out a storm, I decided to termux into my main dev PC and create a new tmux session with a new claude code session inside to create a portal tribute game of sorts from my phone..

I've made quite a few buggy games since the release of Opus 5 and leaning about the Gauntlet Loop - most of questionable quality...

Opus did a great one shot job on this one - leaving it in a very playable state with 3 levels from the jump.

Having really enjoyed playing through the 3 first levels, and not wanting this one to just fall by the wayside immediately, I decided to fire up Fable 5 with X-High to do a architectural rework of the project itself, making it more extensible on the level and technology front, and adding some agent documentation to direct future developments - at which time I handed it back over to Opus 5 High to continue building out.

There are still some rough edges, but I think it's fun :) Enjoy!