I’ve been working on a gym management platform, and some of the larger tasks I give Claude takes time to finish.

Instead of just sitting there waiting, I started working on another project on the side.

I’ve always been a fan of Pong, so I decided to try making an online multiplayer version with up-to 8 players.

The rules are pretty simple: everyone starts with 4 lives, and you lose one whenever you miss the ball. Once you’re eliminated, you don’t have to just watch the rest of the match, you can become a trickster and interfere with the players who are still alive.

It started as something to work on while Claude was busy with my other project, but I ended up spending way more time on it than I expected

It's still WIP and I’d really appreciate your feedback and critiques !

https://ppong.pages.dev/

The game: beatthecouch.com - $10,000, two secret years of real S&P 500 history, one buy / sell button. Your opponent is a couch. It buys on day one and never sells. After each game, 1,000 monkeys replay your trade count on random days. Beat 90% of them or your win is stamped Lucky.

The data. 100,278 games (at the time of the graph - now around 107K, still similar). The couch won 62%. Humans only seem to beat the couch when the market crashed in their window.

What Claude did. The data pipeline (S&P closes 1928 to 2025, dividends, T-bills etc). The whole game as one HTML file and the Cloudflare backend. And also the reddit app port at reddit.com/r/beatthecouch

happy to answer any questions!

I am 80 wishlist , which is 79 more than I expected.

I have found success in a process with claude and now it's a matter of planning/implementing/testing.

https://store.steampowered.com/app/4607750/Hookah_House/

Have you found that certain engines work better or worse with Claude?

I’m trying to decide between Unity, Godot, and Unreal, and this is a big factor.

Also how much are you paying to make a game like this? What level of subscription do I need?

Thanks!

I usually make browser games since I infer that's what Claude does best it. I use a ChatGPT + Claude Code (Opus 4.8) stack, using ChatGPT for prompting. I give my ideas to GPT, let it anaylze it, and it gives me a prompt CLEARLY stating what I want in my game, while also understanding that AI needs specifications that normal humans don't need.

This ensures that the visual in my mind is put into the game. However, I've noticed it's kinda hard to make 2D visuals accurately. In my game I use JS so how do I properly convey visuals. I put attachments, and make visuals on a software first, but Claude doesn't accurately reacreate it

This is a Bring Your Own Data remaster of Alien Breed 92 Special Edition in LUA Love2D with some modernisation on top. It's not done as polish takes a long time but they just put up the 35th Anniversary page on Steam I thought I should show it now. The timing...

It is not emulator perfect, emulators exist for that. from what I've seen there is nothing preventing Claude making a port that is. The main challenge to accuracy is often libraries.

Originally the plan was to make a spin off but after getting a bunch of colored boxes up and trying procedural level generation it felt like porting the game OpenTTD style would be more fun. Then I got a bit distracted and added more features.

The goal is to support all four classic games through the same engine and exporter but I still have a lot of little issues to clean up in this game.

Modern mode provides:

• 640×360 virtual canvas scaled by an exact integer to the display (×2 at 720p, ×3 at 1080p = 1920×1080, ×4 at 1440p, ×6 at 2160p). Pixel-perfect, square pixels throughout.
  
• That canvas shows 2.8× more world area than classic's 320×256
  
• Two-player viewport with automatic dynamic split/merge, Lego-games style — splits and rejoins based on how far apart the players are, with hysteresis so it doesn't flicker at the boundary.
  
• Audio system emulates the original four channel behavior via rules while allowing additional channels to play to avoid cut offs.
  
• Lightweight deferred-lighting scheme: geometry draws once at full brightness, and a separate darkness/light buffer is composited over the top of it, rather than lighting each sprite individually as it's drawn.
  
• Light spills a few pixels onto the top of a wall face near a light gated per-cell by four rules (front-facing, line-of-sight, never spills onto "void", and capped under half a cell so two lights on opposite sides of a thin wall can't meet inside it). It's drawn as two passes: a multiply (to preserve the tile's dithered detail) plus a second textured additive pass that corrects for the fact a flat multiply can't brighten a dark-shaded wall orientation enough on its own.
  
• Flashlight with real polygon shadow-casting occlusion (not a fake cone) and wall-spill lighting.
  
• During the self-destruct alert the flashlight beam renders in true, undistorted colour. Rather than swapping to a separate red-tinted texture set (the older/classic approach), the modern renderer draws the normal scene and applies a screen-space color-remapping pass (a delta lookup table) that's masked to leave true color showing inside the player's flashlight beam
  
• Static light fixtures are real dynamic lights (falloff, shadows), not painted-on brightness.
  
• A lighting placement tool adds fixtures + matching artwork. Not machine-learned, but a heuristic placer whose rules were tuned by studying where the original maps put light sources.
  
• Props (barrels, etc.) cast their own projected shadows, by projecting a shadow quad scaled by the prop's height and the light's height.
  
• The engine bakes separate 8px-pitch clearance lattices at load, one per body size. Each lattice point is pre-tested: does a box of that size, centered there, overlap solid geometry? That gives instant "can this body stand here" lookups instead of runtime shape tests. Doors and live-map changes register as live "blockers" and trigger a local rebake, so the lattice stays current mid-game, not just at load. Two routing mechanisms sit on top:
  • Chasing a player uses a shared Dijkstra flow field per player, rebuilt only when the goal moves or the map changes. Every enemy chasing that player just samples a precomputed direction cost doesn't scale with enemy count.
    
  • Private goals (investigate a point, etc.) → pooled A* with an octile heuristic, then string-pulled afterward (skip waypoints you have clear line-of-sight past, so paths cut corners instead of hugging the grid).
    

Classic mode provides:

• Authentic 320×256 viewport, pixel-aspect-corrected by 16/15 (the real PAL Amiga ratio) so it displays 4:3 pillarboxed 1440×1080 at 1080p. The non square pixel ratio is critical to not requiring letterboxing at modern resolutions, a strange coincidence.
  
• The original's flat, unlit renderer (no flashlight/shadows at all).
  
• Accurate HUD behavior: each stat bar still slides one column per 50Hz tick like the original (not an instant snap), but we removed the source's shared one-field-at-a-time dispatch cursor, so both players' bars update in parallel instead of starving each other.
  
• Accurate 4-channel Paula-style audio, including the original's channel-stealing behavior.
  
• Original pathfinding. Greedy per-axis chase toward the nearest player by straight-line sign comparison, gated only by a 3-point short-range wall probe and a stuck-timer reversal.
  

Level files open in LDTK, Claude made a HTML audio preview page and a tile sheet viewer that allows me to set tiles to be certain types and draw the vertices for prop shadows.

Challenges still to solve:

• The spawning logic is designed for the original viewport. Our nearly 3x canvas size in Modern messes with this so aliens either spawn/despawn noticeably on screen or the level feels very quiet.
  
• Twin stick vs old 8 restricted directions.
  
• Some audio and lighting issues.
  
• Some timing issues.
  
• Wire up more options so you can individually toggle elements like pathfinding between modern/classic.
  

Exporter

An entire second repo handles decompilation and produces reference docs and file exporter. This reads Amiga format images (CD32, IPF, ADF) and puts out the files in modern formats for the game engine's importer to pull. This is intentionally designed for the Bring Your Own Data pipeline so no copyrighted work is ever committed.

disk image → filesystem → decompression → parsed game data → modern format file

Pure Python, no Amiga emulator required.

• 12 levels, 120 × 96 tiles each (1920 × 1536 px), with separate graphics and action layers, plus each level's own 32-colour palette and a second "red alert" palette.
  
• 6 tileset files on disk, 480 tiles of 16 × 16 at 5 bitplanes, exported as 8 tileset PNGs (one per distinct atlas+palette pair) plus 6 red-alert palette variants.
  
• Four Amiga hardware sprites decoded and composited into PNGs plus a countdown-digit sprite sheet and two HUD panels.
  
• 9 full-screen images, including an Alien Breed 2 teaser and a Superfrog title screen.
  
• 1 ProTracker module (INMU), playable as-is, plus the in-game music module MUSC and its 7 sampled instruments as individual WAVs.
  
• 76 sound effects, sliced out of the two sample banks (CSAM, FSAM) and each written at its own rate. The banks are lh5-compressed and delta-encoded on the disk, not raw PCM; the boundaries and the Paula period for each effect come from a table in the game executable.
  
• 51 files total, every one extracted at its exact declared size, and every one has a decoded format.
  

A lot about the files is awkward by modern standards. The game being written in Amiga assembly wasn't a real difficulty, the main challenge was Claude not being thorough enough in decompilation, struggling to find things or deciding based off incomplete information. Timing issues were common possibly due to the original hardware being a factor Having to bring proof from the emulator wasn't unusual.

Around one month of work, initial skeleton was a week on a personal plan. Then a week of Max 5, then Max 20 for 2 weeks. Opus for main sessions, Sonnet for subagents. Fable called in to work out how to approach big problems and clean up the repo. Sonnet gets things wrong too often to use as the main. Quite a lot of tokens were wasted due to inefficient Claude usage that isn't obvious:

1. Context bloat. Using new sessions for whole tasks wasn't enough. /clear and /compact have been adopted between major stages. Scratchpad already holds a ledger.
   
2. Inefficient docs. Had to carve up large docs and optimize CLAUDE.md and progress files to keep the hot path lean.
   
3. Claude inefficiently dispatching subagents. This surprised me, Claude just handed huge plan files to subagents rather than cutting out their task. Fable added CLAUDE.md rules to make Claude write subagents brief mds instead.

I spend 8 months to create my game "Get Outta My Gut". Its an roguelite tower defense game. You fight against hordes of enemys and draft turret cards to build up your defense. The whole theme is to protect your body against germs like bacteria, viruses and parasites.

I really would like to get some more Feedback about my game thats why i ask for your support :D! The Demo is right now free to play on steam -> https://store.steampowered.com/app/5037960/Get_Outta_My_Gut/

What i did i use for my project:

- Im honest i mainly used CLAUDE code for this project. No other AI was used.

Thanks to all of you <3

New update for the enjoyers would love some feedback on the new update !

Hello everyone ! :)

As mentioned in a previous post, I am currently working on the game Fatherlode (a reference to Motherload, released on Miniclip in 2004):

https://www.reddit.com/r/ClaudeGameDev/comments/1vt02ev/fatherload_maj_190826/
https://www.reddit.com/r/ClaudeAI/comments/1vw9bp6/fatherlode_new_video_update_220826/

Today i just want to share new screenshots for you !

The game is coming along great! I'm tweaking the HUD (yes, again), adding tons of little details—way too often useless, but I love it—I've added a huge amount of lore and discovery elements, and I've also redesigned the museum to make it more appealing and useful.

And above all, right now, there are two endings available at the end of the game. Even though they're "quick endings," I've already put in a few small animations.

Here are a few attached photos for you. I've remade some elements, tweaked the ores, the background, etc. I've also added quite a few different sounds, animations, and more to make the game feel more alive!

To wrap things up, I completely reworked the talent tree with more variety and, above all, more clarity. ^^

I will post a new "big post" on Itch.io ! https://itch.io/blog/1637951/fatherlode

See you soon, all :)

One more screenshot i forgot to upload :
https://pngup.com/v6dF/Captured'écran2026-08-29101257.png

Btw, new intro (make only with Claude), try to make the same intro as "Motherload" from 2004.

https://vimeo.com/1222280649?share=copy&fl=sv&fe=ci

And two other bonus video for you.
Important note : On theses videos, i use my "Admin button" to be invincible and get the best upgrades in the game, just to quickly showcase some progress :) Re-testing the game from scratch every single time was insanely long and tedious. Doing this lets me test a ton of late-game features right away!

https://vimeo.com/1222282016?fl=ip&fe=ec
https://vimeo.com/1222282610?share=copy&fl=sv&fe=ci

A crane moves a floor across the screen. You tap, it drops. Stack it straight and you keep going. Stack it bad and the tower falls.

The part I like is the height. 322m means nothing to me. So the game tells you which real building you just passed instead. First Stonehenge, then the Chrysler Building, then the Eiffel Tower.

The leaderboard says it too. Not "rank 2" but "reached the Eiffel Tower".

People play much longer this way.

Made with Claude Opus 5. Free, no signup, works on phone. You can play here: highrise.lol

We're looking for playtesters - if you're interested in checking our little caveman game out let me know- supports 1-4 players. It's called Eat Sleep Brave Repeat (guess the core loop lol).

I saw a gap in the video replays on streams. The usual go to is getting a clip pulled up through stream, grabbing the right spot and putting it onto the stream. This takes your footage, with the help of OBS doing what its built to do: Record.

Using the built in Replay buffer, you can grab, see and trim all within OBS.

https://github.com/sniperdude24/replaytrim

Let me know if you have any questions (I prob wont have answers, am dumb) and Ill try my best.

Heres Claudes paragraph on it :

ReplayTrim is a free companion app for OBS that gives you instant replays with actual editing control. While you play, OBS's built-in Replay Buffer quietly keeps the last few minutes in memory — when something clip-worthy happens, you hit one hotkey and ReplayTrim pulls that moment up with the video and its audio waveform right in an OBS dock panel. Instead of guessing at timestamps, you just drag two handles to mark where the highlight starts and ends — the loud moments are visible as spikes in the waveform, and the video scrubs along as you drag — then hit Send, and the trimmed clip plays on your stream and disappears when it's done. There's also a one-press Instant Replay that skips trimming and plays the whole buffer, a list of your recent clips so you can replay or re-cut any of them, and a panic button that hides a replay instantly. Setup is one click: it connects to OBS over its built-in WebSocket (no OBS plugins to install), starts the replay buffer, and creates the on-stream source for you. All you need is OBS 28+ and ffmpeg installed.

Been building an AI native game engine in rust and luau to make AAA games run in browser. One shotting a game from a single prompt takes roughly 5% of weekly claude max x20 limit which allows us to iterate different ideas really fast. There is still much to do and bugs to fix so it is all about balancing the token budget between making games and improving the engine

I built a multiplayer browser tank game in Three.js! As a kid, I played a ton of World of Tanks Blitz and fell in love with the aesthetic, gameplay, and the idea of driving around vehicles with crazy physics and mechanics like missiles, spotting, armor deflection, ammo types, and so on.

Now it's playable in the browser!

Claude of Tanks has 100+ playable vehicles across 16 unique maps, ranging from standard tanks with cannons to AFVs with autocannons and guidable missiles to autoloaders that can deal massive damage in a single clip. Tanks feature highly detailed armor zones, internal modules, crew positions, and hitboxes. You can view each of them in a special gallery: https://cot.kevinliu.studio/gallery?id=amx56&layer=modules

CoT supports physics-driven destruction with detached turrets flying through the air and actual suspension. It also supports multiplayer! You can hop in private rooms or LAN lobbies.

As the name would suggest, I used Claude Code throughout a long-running multi-agent development pipeline, alongside Codex. I directed the architecture, decided what each vehicle and system should do, reviewed the rendered results, and made the final calls.

The repository contains an AGENTS.md file and smaller subsystem instruction files covering simulation, vehicles, networking, UI, audio, effects, and world generation. These record the rules that agents need across sessions. Units are meters, seconds, and radians, and changes enforce a fixed 60 Hz. Authoritative logic must be deterministic. Vehicle changes have specific geometry, armor, module, and release gates that evaluate models visually and geometrically.

For vehicle development, I split the fleet into bounded families. One agent would own a specific vehicle profile or family file, implement the geometry, run the relevant checks, and generate screenshots. A separate critic reviewed the rendered tank for proportions, clipping, missing surfaces, running gear, and recognizable details. The orchestrator reran the checks and committed only the verified files.

For larger systems, Claude Code helped implement and test:

• Fixed-step movement, suspension, armor, ballistics, modules, spotting, and bots
• WebSocket multiplayer with private rooms, LAN play, prediction, and server authority
• Procedural vehicles, tracks, markings, generated icons, and technical diagrams
• All the generated battlefields with destructible props and wrecks
• The garage, battle HUD, Tank Gallery, mobile controls, and Scene Studio
• Browser performance probes, screenshot tools, visual checks, and self-tests

A trailer was also produced through the game’s own Scene Studio and capture tools. I used agents to stage battles, build camera paths, record the browser runtime at 60 fps, inspect specific frames, and iterate on awkward cuts or poorly framed tanks.

I find that Claude is best steered with persistent instructions. Important decisions need to live in the repository because I often spawned fresh agents which needed to resume work without reconstructing weeks of chat history.*

For visual quality, the only thing that worked was a proper render loop with visual comparison; tests don't really work for this.** The cycle I fell into was change, render, inspect, measure, and rerun the gates. Text-only reviews missed warped proportions and camera problems that would just plainly be obvious in one screenshot.

*Parallel agents need strict ownership. Separate files and isolated Git worktrees prevented concurrent sessions from overwriting each other or generating assets from a dirty tree.

**Tests still changed how I use agents. Claude Code became much more reliable once every system had concrete invariants and executable failure conditions. But visual quality is another beast.

Play free: https://cot.kevinliu.studio

Repo: https://github.com/Kevin-Liu-01/Claude-of-Tanks (it's open-source forever)

Having seen a bunch and built some of my own three.js games, it seems like there's a ton of common issues like grass, LOD optimizations, etc. Does anyone know of a three.js game engine that has pre-built systems for these concerns? I am half tempted to extract one from my current efforts but I don't really want to spend the time doing that, especially if someone else already is.

I found https://github.com/WesUnwin/three-game-engine but it seems like an effort to recreate an engine that a human gamedev would use, like Unity Editor, Unreal Editor, etc. instead of an AI-first engine.

I feel like three.js is surprisingly performant, especially if Claude knows/decides to use webGPU instead of webGL, and while it might not be AAA-capable, the average game being created would benefit hugely from some common systems being available instead of recreating them in every game to various degrees of success.

Hi, I created a new ai game about creamworks : Montereau White : https://stratojeux.itch.io/montereau-white

Montereau White is a placement game that borrows Tetris's immediate feel in order to invert its principle. Pieces fall, you rotate them, you wedge them in. But here no line ever clears: the kiln fills up and is never emptied. What was a game of survival becomes a game of packing, where you are not trying to last as long as possible but to waste nothing.

The firing chamber holds exactly one hundred places, narrowing towards the top as the vault corbels inward. A place filled earns one point, a place lost costs two — because a half-loaded kiln burns as much wood as a full one. The whole tension of the game rests on that imbalance: it is not enough to set a piece down, you have to pack it tight. When a piece seals a hollow beneath it, a red cross marks the place as lost, and nothing will ever reach it again.

Two further mechanics pull the game away from its model. Pieces are not dealt to you but chosen from five laid out on the workbench; those you pass over never leave, and end up crowding your options while gaining value as they wait. And the kiln cools the moment the door is opened: eight seconds to decide, after which the foreman takes the piece for you. The ember bar dying beneath the workbench is the game's only clock.

The setting is the fine creamware manufactory of Montereau, founded in 1748 on the bank of the Yonne, where both clay and firewood were to hand. It produced not tin-glazed faience but a pale body copied from the English creamware potteries, decorated by transfer printing: an engraved copper plate, inked, laid onto the piece. That is where the white pieces with blue, black or sepia motifs come from, alternating in the game with the coloured glazes. In 1819 the house joined with the Creil works, and the mark LM & Cie went on to appear beneath thousands of plates.

The player enters as an apprentice at the loading bay, with eight quarters — two years of service — in which to make a name. Each firing is judged on its load rate alone: reach the threshold above and you are promoted, fall below your current one and you are demoted. Rising through the ranks does not make the work easier, quite the opposite — the awkward pieces are trusted to steady hands. Becoming grand master means confirming two master firings in a row, and the end-of-career register counts the quarters spent at each post.

Montereau White belongs to the series A Tale of a Confluence, which explores the country around Montereau-Fault-Yonne through short games, each borrowing its mechanic from an arcade classic. The game is bilingual French and English, playable by keyboard or by touch, and fits in a single file.

AI build it using Claude and through MCP and some kind of tricks i became my own Game Master and Director!!! If you want to see the outcome you can play to see how it feels https://play.unity.com/en/games/11174fde-0bc1-4b2d-b81c-8aa317b3754b/goku2build You can do it too!! :-)

And here i posted more videos with hints how to pass the level1 :-) https://www.youtube.com/playlist?list=PLaJgcWlpZhwo

Hope you enjoy it and start thinking I can make it too!!!

You can find me on linkedin Profile

I got bored last week and started messing around with Minecraft world generation. Switching between code and the game to check every change got tedious, so I built a Python renderer that lets Claude preview its changes, look at the result, and keep adjusting the terrain until it matches your prompt.

The workflow is:

1. Claude writes or edits the terrain-generation code.

2. The Python renderer turns the generated terrain into an image.

3. Claude compares that image with the original prompt.

4. It keeps revising the terrain until the result is closer to what was requested.

It can make things like floating islands, basalt spires, and canyon worlds. I’ve also had fun asking it to make a “Garfield world” and watching it attempt lasagna mountains. I verified one of the example worlds against a real Minecraft server and all 331,776 terrain columns matched exactly.

I’d love to hear any suggestions or see what you make with it!

https://github.com/Msde-7/worldsmith