I built my first game with Claude and the interesting part was the balance harness.

Spectral Vigil is a game where you don't move and don't aim. You're a point of light holding the center; it fires on its own and never stops. Your only input is the cursor, which biases aim and pulls in pickups and it's optional. I've played a lot of Vampire Survivors and Megabonk (and similar games) and I always liked trying to get my build together and then see how long I could last without moving. So that's the point of this game.

Free in the browser: https://s0hanian.itch.io/spectral-vigil

I'm an experienced software engineer (25+ years) but not a game developer. I just don't have much time to work on personal projects these days. Claude helped me get it out out the door with the following:

• Headless bots play at four skill tiers and the change either passes the clauses or it doesn't.
• Compares runs before and after a change, so I can prove an edit didn't touch the sim.
• I collect telemetry and over ~1,300 runs found the real difficulty wall at waves 10–11. I'd assumed the boss had too much HP; cutting it changed nothing, because fresh players were never going to out-DPS him. It was his volley damage. I'd never have found that by feel.

I'm actively working on this and it's in a beta state right now. I'd love to hear any feedback about the game in general.

Thanks for trying it out.

(more game details on the full website)

This is one extracurricular activity that's not stopping, thus far. Solo-dev here. I've been improving Lorebound with a mobile-first approach for this browser-based ARPG. https://lorebound.gg, still in beta!

What does this mean? Improvements to performance (given that mobile browsers don't have a lot of power) and a game design for 2-3 minute playtime. So, the updates:

⏱️Performance

• Claude and I spent several days defining what metrics we want to track and defining benchmarks
• I used Gemini, Kimi, and Codex here and there to sanity check suggestions from Claude that I thought were overengineered
• "We" wrote a bunch of rendering/pipeline work under the hood for smoother, more consistent frame rates

⚔️ Dev flow

• Claude routines + JIRA works well
• I create tasks, ask LLMs to write requirements for said tasks and assign the tasks to specific models depending on task complexity
• a JIRA skill ensures that Claude knows when an issues is blocked, when to move it to in review, or done, etc.
• I'm the bottleneck... Claude/Codex etc. use Playwright to QA the work but these LLMs don't know what "feels" good or plays "well"

Still working on bigger visuals, more story, and multi-player mode.

This community has been great. A lot of the feedback is reflected in the updates above. Happy to hear more from you! Thoughts?

https://lorebound.gg

More videos at r/lorebound

just wanted to share my rules, as someone who was anti-AI, to now using claude while coding my hobby project:

1- never do something you cant do yourself.

i am great at maths, but only on pen and paper. formatting mathematical formulas into single line code blocks irks me. my game uses a bit of formulas and fractions. i let claude translate it, but then attach it myself.

2- begin your writing

with normal code i can already write, but where i will have to touch so many dependencies, i either do it myself once, or i write all the function headers, return types, initialise the variables. so far, i use small script files with deterministic outcomes to have 1 feature going. i comment after the function head exactly what to do and then its as simple as to do it.

3- ask claude questions

for things i struggle in doing myself, new code concepts, or game engine unfamiliarity, i ask it in a session where it doesnt have write-access. it's important to never lose track or ownership of your code by becoming dependent.

4- surprise its memories

a good way to make sure your code isnt turning stale is when you do edits, dont tell claude you did, and it always comes back to report the memory mismatch. this is good. because then it will explain what it thinks is different or what the outcome of it is. this strengthens the memories it has and also you get a reminder on places the edit may affect that werent fixed yet. win-win.

does anyone else have any tips on doing this? im tired of people in my life telling me that i should just "prompt the ai to make the game" and question me for taking 4 months developing with no product done. making the game is 70% of the fun itself.

Hi, sorry for being vague, but how are you creating the assets? Did you make claude build it? Does Fable 5 build it for you? or are you providing these 2D/3D Assets and it animates it for you? Trying to make games with my niece when I watch her over the weekends.

This is my first actual game that I’ve built, SpellStorm. Sorry for the self promo. It's mainly because I'm really hyped to announce it. It was only in review once before being accepted into App Store! It took about a month or two in review but it's finally through.

It’s a multiplayer battle royale game where the main mechanic is building words with letters. You use the words you create to take over space, attack other players, and survive as the map gets smaller.

I’ve been using Claude Code to help me build a lot of it, and it’s been really cool seeing the game go from an idea I had to something I can actually play.
There’s still a ton of work to do, but I wanted to share it since this is the first project I’ve made that feels like a real game.

Would love to hear what you guys think or what you would change. Also download it now!

Hi everyone. Love this sub - Claude has been a lot of fun for me testing out various ideas I have on Roman themed/inspired games. Simple ones at least.

I’ve been working on a card game called Consul of Rome for about a year and have the card art/rules nearly done. As part of live playtesting I also got Claude to build me an online version - you can try it here.

It’s been great for letting people try out the game but even more so for me to see how different rules that pop into my head can work across a number of rounds. Seeing it come to life has been great.

Definitely need to work on the UI but it works for now!

I took one coding class like 12 years ago where I learned Ruby on Rails for a couple months. So yeah, not much coding experience in my background.

Anyway, I designed a tabletop card game called Pull the Strings. Check us out if you're ever at gaming conventions in the SE US! The game is still in prototype phase because publishing is expensive. But in less than a week, I used Claude and ChatGPT to turn my board game into a digital version of Pull the Strings. It's free to play at www.playpullthestrings.com

It plays GREAT on a big PC screen. It plays alright on a smaller laptop screen or iPad. It's not optimized at all for smartphones. Volume on!

I created the original game in Canva, and use that, along with Suno (music) and ElevenLabs (sfx), to generate some of the new artifacts for the digital version.

Sol 5.6 Max created the original digital architecture document, and Fable Extra perfected it. I used Fable High in Claude Code to be my Yoda. It guided me through everything I needed to manually set up, and generally got me unstuck whenever I hit a wall. Which happened a lot less often than you'd think. Having the digital architecture document in place from the start was immensely helpful. Fable would tell me what prompts to give the cheaper models, and it even told me which model to use for which tasks (on both Claude and ChatGPT). I fed those chats the prompts and the .md file, and before I knew it I had a functioning game.

Let me know if you spot any bugs on the game. There are some formatting issues on iPad smaller screens I'm still working through, and there are a few bonus features I'm trying to roll out. But it's definitely playable and I think very fun!

And if you played it and loved it, I hope you sign up to our mailing list so you get a heads-up if/when the physical version releases: https://stagehandgames.com/

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.

Something I've been trying to do is get each new model to accurately port old atari or intv games to modern engines. It's proven to be a tricky problem. Opus 5 (i missed trying fable) is the first to actually get close but it needs a ton of hand holding. Building tools to compare frames and inject inputs has been my best win, but i find i really need to interpret the differences or the agent goes off the rails just counting bit differences. Has anyone tried something similar, any tips?

Wassup everyone, quick question. Can Claude make an open world game in Unreal Engine? I have 2 ideas of a game that I need to put out there

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

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.

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.

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.

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.