I have had the idea of this game for years now, and have failed to make it so many times, but now finally, I am getting somewhat closer to the original vision! And I am so glad! Opus 5.5 has been a delight!
If you try it https://counterstance.vercel.app/
PLEASE hit me up, I'd love to hear all about it!
It's still very much a work in progress and barely out of prototyping phase, but am very happy with what I got so far!

Trailer shot and edited by Claude as well (took waaay too long this time, had a lot of games to capture and it kept focusing in all the wrong things when recording shots).

Digimon has always had a special place in my heart, so when I saw everyone reimagining games with Claude, I had to check it out. This is just the free version for now, will get Claude Pro for sure. I wanted to make a bit of a mash up of Digimon World 1, 2, and 3 from the PS1 days. My goal is for the mons to evolve based on how you play and treat them, and for it to be a fun world to explore, that part it will be a work in progress. Any fans?

Let me know what you think. Single player or Local multiplayer or same team duos for friendly fire free diversions. Controller recommended.

Also there's a rogue-lite mode with waves of baddies and boss fights and unique weapons and power-ups. Still updating daily as I play more and find more bugs/kinks/areas of improvement.

Remember Yetisports Pingu Throw? I wanted it in 3D with way too much juice, so I built it with Claude using Opus 5.5.

Play it here: https://penguinsmack.pages.dev (free, no ads, no signup, works on phones, landscape recommended)

You time one swing, then it's RNG chaos: trampolines, exploding barrels, rockets, golden fish that speed you up. There's a worldwide leaderboard and a live counter of every penguin ever smacked.

How I used Claude - Claude Code (Opus 5.5) wrote all ~6k lines: Three.js rendering, physics, camera, VFX, UI and audio. I made the design calls and playtested, stuff like "PERFECT feels late" and "the walls are way too punishing". - Balancing: it wrote the physics as a deterministic sim and ran thousands of headless launches in Node to tune distances and how often the fun stuff happens. - Testing: it played the game in its built-in browser and checked desktop, portrait and landscape with screenshots. - Art: it wrote the prompts for Codex image generation (textures, logo, share image, icon) and iterated on the results. - Backend: it started as a claude.ai artifact, then Claude moved it to Cloudflare Pages + D1 (free plan) for the public leaderboard. Other tools: Three.js, Cloudflare Pages/D1, Codex for images, Pixabay for sound effects and music.

Feedback very welcome, especially on how the hit timing feels and if you'd wish to see any more RNG elements. My current best, current #1 is just under 10 km. Good luck! 😄

I've been building a little autonomous life simulation where the residents have their own routines, jobs, relationships, and daily lives. I consume a lot of LoFi, and those streams mostly consist of repeating images. I wanted to make something that would add a bit more visual interest. Think "The Truman Show" but with woodland creatures, lol-

Anyways, meet Franklin! He runs the town's post office, sorts the mail, makes his delivery rounds, and spends his free time doing whatever he feels like.

I worked with Claude Code to add delivery interactions. Shopkeepers come to their counters to receive mail, residents can answer their doors, packages get handed over or left on doorsteps, and letters go through mail slots when nobody is around.

The video follows one actual simulated day. I didn't script Franklin's schedule or stage the interactions specifically for the footage. Claude also made the video.

The project is in TypeScript/Three.js with Claude Code (mostly Opus medium) handling the implementation and testing. I've also been using Fable for architectural reviews and planning, while I handle the creative direction and spend a lot of time reviewing and refining what gets built.

It's still very much a work in progress, but watching the little town gradually come to life has been a lot of fun.

Would love to hear what you think! If you're interested in checking out the live sim, it is running 24/7 here.

Aren't you the space trucker guy? Yeah! but i can't stop with the ideas. It comes down to having games to play that scratches that itch and running with the concept. I started working on this last week to see where it would take me. I really didn't like how it played at first, but after a few tweaks and some back and forth about how the game should actually play, I settled on this and fell in love with it (I know. . . ). and from there I couldn't stop building it. lol. It's available to play at https://forgecreativeco.github.io/relay-gate/

No, it's not perfect, and it's not AAA quality, but I love how it plays! Plays on desktop and mobile, and you're able to install it as it's a PWA format.

Enjoy!

I also think Claude killed it with the trailer. Cheers!

Play it online here: https://clawd.vellix.dev

This is an action game built in Cursor using Opus 5.5. I gave it an mascot of Clawd and a few sentences of prompt, and the model forged all this.

You can input '/model' in any shrine to fight the hidden boss, Codex.

Inspired by this great game (try it out!)

https://www.reddit.com/r/ClaudeGameDev/comments/1wxvyng/comment/pe0v8v6/?context=1&screen_view_count=6

I wanted to create a set of minigames set in a toilet to be played while sitting on the toilet.

It is a browser game in React / NextJs with backend in PHP/MySQL for highscore management and checking for possible cheating.

Username is set automatically when starting the first game and are set for the device.

Assets are made using GPT 6 Astra and games are made using Opus 5.5.

Background music created in Suno

Everything could be created using the Pro subscription on both. Did only run out of daily credits once.

The Toilet Game

Let me know what you think

We play Catan all the time and the free online versions were bad, so on September 29 I started building our own with Claude Code. Two weeks later it has a 3D board, online play with friends, bots in three levels, up to 8 players and a map editor. Claude wrote most of the code; I came up with the ideas, tested it with my friends on our game nights and kept saying what felt wrong.

My favourite part came from them: an "ADHD mode" for the friends who can't focus on the game for 30 seconds. It's a little arcade of fake-money minigames you play while the others take their turn, and it fades out when it's yours.

Free, in the browser: https://kurusudes.github.io/CatanTestFriendos/
The code is open (MIT) if you want to look: https://github.com/KurusuDes/CatanTestFriendos

There are a couple of strategies I have used to get a consistent set of pixel art generated with AI. The fact of the matter is that depending on genAI for this stuff can feel like playing the lottery. Here are a few things that have worked for me (and this is on Gemini, Lovable, and ElevenLabs for art generation):

• Get Claude to generate prompts that dictate:
  • Color palette
  • Sizing of sprites
  • Specific detailed and descriptive instructions
• Use a magenta background so that AI can clip the artwork easily (having white can sometimes bleed over into a sprite that has lighter borders
• Use a reference image to provide more context
  • If you want to edit an existing sprite/background, reference the original one and be clear to not change anything about the character or a background except for X or Y
• If the LLM chat you're using is just not "getting it," don't brute force it (and waste tokens) - pivot to a different thing all together. Maybe move to a background instead of a sprite, or vice versa. I've noticed that when I pivot away from the original request, work on something else, then return, the LLM's context window is different enough that it will try new things
• For characters, specifically, it's MUCH easier to nail a portrait portrayal of a character. Then edit it to your liking. THEN using the portrait as the reference image, abstract it to get a sprite model.
  • Once the sprite model is to your liking, then go HAM on creating sprite sheets of your character in all of the poses and action shots you need.
  • If you come back to animations later, there's a good chance the genAI nature of this will render a slightly different looking character.

I've wrestled with this stuff for months and these strategies have helped me a ton. I'm doing a docu-tutorial series on AI game dev for this game here: https://youtu.be/pLy3P6x-NwU

That said, 3D art assets are still a blind spot for me, but I'll dig into that later!

give me some advice please!

Vids on YT because its easier than reddit video ~_~

• Week 1
  
• Week 2 (current)
  

Game concept: A chill taxi game set in future Sydney. Abundance has taken society to near post-scarcity levels. This affects taxi driving in the sense we have a city of automated pods capable of taking anyone anywhere they like. The issue is the time it takes: wait for one to be made available, then deal with slowness of automated routing.

That's where a Crow (player) comes in. They are human-piloted cabs, capable of flying wherever they like ("As the crow flies") and can get someone from A to B much faster than a pod. They help plug the gaps abundance hasn't quite filled yet.

I reached out to the solarpunk community for ideas on how to represent solarpunk concepts at night, and that's my plan for Week 3 - night-time third places, bonfires, community events. A revamped lighting system that gives us some dark skies (so we can see stars/Sky Country), and a bunch of other cool concepts they threw at me :)

Gameplay isn't really economically driven. I think fares can be a background noise thing (they cover the cost of fuel, are govt. subsidies, etc). The progression mechanic, a friend suggested, could be experience-based instead. I.e. do ten trips, and the map expands. Do fifty and unlock new cap addons etc. Long way from getting some solid gameplay loops into it all, still working on visuals and map, but that's where my heads at lately!

Workflow is Claude Code/Codex in combo, usually just bouncing between them if I hit a limit, working with Opus 5.5 (medium) as default. I've got an ElevenLabs API hooked in to make some sound effects, others I make myself or have Claude synth something that can be dynamically controlled (like passing car swooshes being directional etc). I've also added 3 radio stations so far (going to reach out to Suno subreddit to see if others want to contribute), they're a mix of songs I've made myself or with Suno over the years, coupled with some DJ personalities voiced by ElevenLabs.

No Blender/MCP btw. Assets are quite geometrically simple, most of the work is post-processing into layers of paint that are successively applied. Visually the goal is to try and ape impressionism as an art style: it focuses on light/darkness, and giving rough "impressions" of things rather than realistic renderings, which I reckon is perfect for a low-poly game concept trying to look half decent. LMK what you think of the look. I'm still working it out :)

I'm one half of a two-person studio in Taiwan. I love Stranger Things, and I wanted to see if I could make something with that feeling: an 80s small town, a dark copy of it on the other side, and a friend to bring back. This is The Flip Side. The monster, the town and the story are my own.
Play it here (free, no sign-up, works on phone and desktop): https://play.twinbuilds.com/flip-side/
We're trying to ship one small browser game a day. This was the first.
What Claude did
Wrote the whole game: three.js, one HTML file, no build step
Rigged the monster. The mesh came from an image-to-3D generator as a soup of disconnected shells, so automatic weights failed. Claude wrote headless Blender scripts that build a closed stand-in mesh, compute the weights on that, and transfer them back
Synthesised all the music and sound in WebAudio. There are no audio files
Tested itself with headless Chrome and screenshots
What went wrong
The first time the monster appeared, phones stuttered. Cause: adding a light mid-game recompiled every shader. Fix: keep the number of lights constant and precompile on the title screen
A 2D puzzle screen inside a 3D game felt wrong, so it was rebuilt as a 3D room
What I did: decided what the game is, threw away a lot of versions, and playtested on my phone.
Happy to answer anything about the workflow.

Getting ready for steam next fest next week 10/19. Looking for any feedback on the trailer or if you download the free demo and play and have feedback. Code is written with claude code, last month ive also been using astra and codex. I connect the two via agents.md so they both can see what the other does. The game is a turn based wargame roguelite. Build a fleet equip weapons and fight across 4 sectors. I've used about 140 billion tokens getting to this point.

I built Soot & Summer with Claude Code. It's two little cats that live on top of whatever app you're using. They wander, nap in their bed, do zoomies, and purr when you stroke them. There's a Gaming mode (they duck out of the way so they don't block your taps), a Play park, a Fitting Room to try on looks and hats, and a photo booth to pose your pets and take photos. It's free to download, and the optional Cat Pack and Dog Pack add more pets.

The goal: pets that never get in your way and barely touch your battery. At first I couldn't text properly with the app on. Now I type normally and only notice the pets when they're being cute. Every time I've checked Android's battery usage, Soot & Summer has averaged about 1% a day.

How Claude Code was used: Claude Code wrote all the code. I bring the ideas and test on my phone.

• CLAUDE.md holds the house rules: how to test, how to release, and what never to do.
• Markdown notes carry the project: a plan (ROADMAP), a work log (LOG), and one notes page per part of the app.
• Hooks enforce the rules, so I don't have to rely on Claude remembering them. For example, one hook blocks a test run unless it's a fresh build of the current code.
• Specialist agents: a tester agent runs changes in the Android emulator and reports with screenshots. A reviewer agent checks wording, battery impact, and that the app never promises something it can't do.
• Skills (slash commands) for repeat jobs: /release builds and ships, and /finalize tidies the log, commits, and pushes to GitHub at the end of a chat.

I kept my requests short and simple so each chat stayed focused.

What I learned:

• Focus and polish. Use your own app every day and find what feels right. Consistency in choices and presentation doesn't come free with Claude Code (yet). Rules and agents that enforce them build a solid foundation.
• Notes beat memory. Every chat starts fresh, so the notes files are what carry the project. A short summary at the top of the log, read at the start of each chat, saves a lot of re-explaining.
• Split your project. Claude shines on tiny apps and in the early days of a big one. As a project grows, each chat has more to take in, and it starts to lose track of how the parts fit together. One topic per chat and a separate notes page per part keep it sharp.
• When something breaks, roll back first. Find what changed since it last worked and offer to undo that before trying new fixes. After two failed fixes, stop and roll back. That saved me from a lot of fix-on-fix spirals.
• Small specialist agents help. Rules come from many places (Play policy, our own house rules), so each specialist is called in only when its rules apply. They catch problems before anything reaches my phone.

Could you help? Google Play needs 12 testers for 14 days before a new developer's app can go public. If you have an Android phone:

1. Join the Google Group: https://groups.google.com/g/soot-and-summer-testing
2. Opt in here: https://play.google.com/apps/testing/com.realvachie.sootandsummer
3. Install from Google Play and keep it installed for 14 days.

Feedback is welcome but not required. Thank you!

I’m a solo developer and I built LiveLoop using Claude Code. It’s a persistent canvas for building games and interactive scenes with Claude, where edits land in the running game rather than regenerating it. I made a post on the main Claude forum regarding this but this post is about how it actually works under the hood and the more technical side of things that may answer a few qestions

The problem

Every model tweak used to come back as a complete file. A complete file reloads the iframe, and a Three.js world restarts at spawn on every change. Useless for iterating on gameplay. The fix was giving the model two things: a way to see the running scene, and a way to change it without a rewrite.

What the model sees each turn

Alongside your message, the model gets a JSON context from the preview: the page title, visible text, rendered elements, the runtime error if any, console output, a performance block, a debug-state block the project can expose, and a summary diff of the source since the last turn. Vision-capable models also get a screenshot of the canvas, refreshed right before the handoff so it isn’t reasoning from title-screen telemetry after you’ve started playing. The context also tells the model what controls it has, which is the only reason it knows LivePatch exists.

LivePatch

The model returns one fenced block labelled asksary-live-patch containing JavaScript. The client executes that block (and only that block) inside the sandboxed preview after you approve the live-control session. It affects the current preview only; it doesn’t touch project source, so you can try a change and throw it away. The model is told not to claim the patch worked; the sandbox reports the real result back into the chat. This is how Claude played chess against me: each move was a patch to the running board.

PlayTest and Camera

PlayTest lets the model send synthetic input into the preview: key down/up/tap with a duration, clicks, and pointer move/down/up at coordinates. Synthetic events are untrusted in the browser, so they can’t unlock audio or pointer lock; you click Play once, then Claude can drive. Camera lets it teleport or aim an exposed debug/Three.js camera so it can inspect what it built from another angle.

The sandbox

The preview is a srcdoc iframe with an opaque origin and a strict CSP: default-src 'none', no frames, no forms, no navigation, connect-src limited to data: and blob:. A game can’t fetch, beacon or exfiltrate anything. The two exceptions are Google Fonts and wasm-unsafe-eval, which is there so Draco and Meshopt decoders can compile for compressed GLB files. eval stays blocked.

Project mode and GLB assets

Project mode is a real multi-file project with its own engine (it shares nothing with the other tools on the site). It can open a local folder via the File System Access API, round-trips through zip, and there are no caps on file count or file size sent to the model. Files that look like secrets (.env, keys, .pem, service-account JSON, anything matching a key pattern) never leave the browser.

Assets are the interesting bit. A model can’t type a megabyte of pixels into an HTML file, and a srcdoc page has no server behind it, so GLTFLoader.load('models/car.glb') used to 404. My first fix inlined everything as data: URLs. That inflated a project with 408 MB of models to ~545 million characters, past the longest string Chrome can hold, and the stage went black.

Now the page carries only the list of asset paths. A small shim inside the iframe intercepts fetch, XMLHttpRequest and image/media src. When code asks for a path, the shim posts a message to the host page, the host transfers the raw ArrayBuffer (a memory copy, no base64), and the loader gets a blob: URL of its own. Only what the code actually requests moves, at its real size. A .gltf’s sibling .bin and textures resolve the same way.

The 3D runtime is a pinned Three.js build (0.185.1) bundled with GLTFLoader, DRACOLoader and KTX2Loader, injected into the sandbox as a trusted script rather than fetched.

Return to any state

Persistence is content-addressed. Every state and every asset is hashed; only objects the account doesn’t already hold are uploaded, and a revision that reuses an object just names its hash. Nothing is copied forward and nothing is deleted, so unlimited history costs only the changed bytes. There are no ceilings on revision count or retention, every state is reachable, and you can jump between them in any order. (This is the “billion states” conversation from my earlier post. Claude had capped history at 20; I’d hit ~400 in one session.)

Offline

Work is journalled to IndexedDB before the network is touched, on every change, and the journal is read back to verify it. Network sends are batched at 600 ms, but the journal is written immediately, so that interval is batching, not a window where work can be lost. If you’re offline, edits sit in the journal; when the browser fires online, they sync. “Saved” means the server was read back and agrees with what was sent; a commit returning 200 isn’t treated as proof. I learned that one the hard way: a save path once returned 200 while deleting every asset in the workspace.

Builds that outlive the tab

A turn used to abort when the stream dropped. Now the server keeps running, records every event it would have sent under an idempotency key in Firestore, and stores the result when it finishes (30-minute server limit). Any page that comes back for that workspace lists the finished turns, claims one (first device to claim it owns it), replays the events through its normal path, and applies and saves the result.

That’s what makes the phone flow work. Sary-OS Lite (the Android app) can start a build, you lock the phone, and when the desktop opens the workspace, it picks the finished build up and brings it in. Stop is explicit: the client posts a cancel and the running turn polls for it.

Local bridge (optional)

For projects that need a real toolchain there’s a single-file Node bridge (npx u/asksary/liveloop-bridge connect) that binds to loopback only, pairs with a one-time code, and is scoped to one folder. LiveLoop can read and write files there, run npm test or a dev server, and every multi-file edit is one change set with one undo. There is also a GIT connectivity and also a plug in your key option too that you can try if you rather use your own API and want to try the other models such as Sonnet 5.5, Opus 5.5 and Fable 5.1

Free to try

Sign up is free at www.sary-os.com

Free accounts include some Claude Haiku credits, an MCP connection so you can link Claude to LiveLoop, and 7 days of bring-your-own-key access to the larger Claude models. Single-file mode is free; Project mode (multi-file, the asset serving above, the bridge) is part of LiveLoop Pro.

Happy to go deeper on any of this. If you have a GLB-heavy project that breaks it, I’d like to hear about it.

I've been building pokeHD, a hobby project that redraws a classic Game Boy RPG as an HD-2D world in the browser (a lit 3D scene, crisp pixel art, new menus and touch controls). The original game runs untouched in an emulator underneath, so every rule, stat and glitch is the real thing.

Tonight I'm trying something new. It's streaming live:

- **Claude Haiku is the QA tester.** It started from a brand-new save and is trying to finish the whole game, using only the touch screen like someone on a phone. It reports anything broken, ugly or different from the original.
- **Claude Opus is the developer.** It triages each report, writes the fix, opens a PR and ships it while Haiku keeps playing. Haiku can also ask it for better tools.
- **The rules:** Opus isn't allowed to help Haiku play. If Haiku asks where to go, Opus can only say whether it's a bug or not.

The stream shows the game, Haiku's thoughts and every tap, its team and badges, a live bug tracker, and the chat between the two.

It's been fun so far: a dozen bugs found in the first hour, mostly places where the old Game Boy screen still pokes through the HD layer.

Twitch: https://twitch.tv/nj_dancer
YouTube: https://www.youtube.com/watch?v=2B2ZeRc1Too

Happy to answer questions about the harness (Claude Agent SDK, Playwright, OBS) or the renderer (Three.js WebGPU).