I used Claude to create a plugin for Unreal Engine. It can make physic based games in Unreal and has skills to talk to Claude. I’m astonished that it was able to add a a new physics engine to something as complex as Unreal - this as my first thing I’m releasing for other to use via fab. I would have never thought I would be able to tinker with an engine’s physics engine and use a opensource project to do it! It will be accessible to anyone for free waiting on fab to accept the plugin

I missed playing Catan & Civ, so I built my own strategy game over the weekend with AI's help.

Rajasuya, 12 turns, two rival claims to the high kingship of ancient India based during the times of Mahabharata.

Free to play, in-browser.

Hope you find it fun.

https://amlanchak29.github.io/rajasuya/

sunabox.dev — free, no account, opens in one click!

Some fun things to try:

- Paint sand and then hit it with lightning - it turns to molten glass and cools transparent!

- Drop "Orbies" (Orbeez) onto water and watch them swell and grow.

- Connect Mortars (fireworks) with a fuse and light the fuse for a personal fireworks show.

- Heat popcorn kernels until they burst into fluffy popcorn and steam!

- Wax behaves like a lava lamp: melts, rises, cools, sinks.

- Drop some metal into a pool of acid, and ignite the fumes!

- Play with gravity, emitters, collectors, vehicles, wheels, rigid bodies, elastics, PNG-as-material imports, fun visual styles, session recording and playback, and more!

SunaBox is a from-scratch rebuild of OE-CAKE, the popular 2008 physics toy that effectively fell off the radar. I've included a Classic mode that recreates the original interface, and it even supports the same .oec files people made fifteen years ago.

Drop any PNG in and it becomes matter. Light a fuse and watch it carry fire to your nitro-bomb!

A more feature-rich version of the game will be coming soon to Steam, if you'd like to wishlist and support this project.

Nitty-gritty about the project:

Some of SunaBox's features are only possible due to SunaEngine: an open source, cross-platform bit-deterministic WebGPU particle physics engine, also made with Fable 5: https://engine.sunabox.dev

This engine/game started out about a month ago as an idea for a data encoding format. I was experimenting with storing data in images and movies with Claude, and suddenly it struck me: "What if we could store data within the various reactions of a particle physics engine, like Powder Toy / OE-CAKE?"

It occurred to me that between the various kinds of materials and the way they interact with each other, a lot of information could be stored in a recorded physics sandbox gameplay session.

What I didn't know was that this was basically impossible with a typical physics sim, which usually relies on floating point math to calculate interactions between particles (long decimal numbers where the end is rounded off). This slight rounding error introduces chaos into floating point simulations; which makes most particle simulators impossible to encode data with!

There's another layer of chaos introduced in the way that different GPUs calculate physics interactions, with different GPUs delivering solutions in different orders.

SunaEngine solves this in a novel way by using integer-based, bit-deterministic physics, and accumulates the solutions in the correct order before rendering a frame- it's been tested to be consistent across NVIDIA(RTX 2070S), ARM (Steam Deck), Apple Silicon, iPhone, and Intel integrated graphics.

It sounds simple, but there's not much like it out there, and I've made it open source for everyone to build with.

And of course, it's not limited to 2D; SunaEngine can be used to build 3D games too.

This actually unlocks some **REALLY** cool potential applications

1. Low latency, cross-platform, multiplayer physics: When all of the GPUs compute physics in the exact same way without variance, only player inputs need to be streamed over the network in order to have accurate, fast multiplayer physics games.
2. Session capture, smooth rewind, and playback - session captures can be saved in very small file formats, replayed on anyone's machine, smoothly scrubbed through like a movie in forward and reverse, and will always render exactly the same, no matter which device you play it back on. (Unless you interact with the scene mid-playback, which is also possible)
3. Research and world models: SunaEngine was built for SunaBox which is, essentially, a toy - but, it can be tuned to more closely resemble real-world physics. With realistic physics and bit-determinism - research simulations can be easily saved and reproduced for inclusion with whitepapers. Predictable, small formats for environments in which to train world models.

I'm happy to answer any questions about the engine, game, build process, etc.

This is being made with Claude Code. I have been working the last few days to get the settlement portion of the game going, including settlers with gear and animations, completing gather and crafting jobs, etc. Thought I would do a stress test with getting a lot on screen at once, and here it is with 600 settlers, all in different armors/weapons, doing attack animations. Considering the goal is to have up to 300 settlers in your settlement, and if you decide to conscript all of them and attack a large enemy settlement, you could in theory have 600 NPCs in a fight around you. I am still working on optimization, as well.

EDIT: Registration does not require an email. It can be added later in the game settings to enable the forgotten password feature

Lythravel is a 3D voxel MMORPG that runs in a browser tab. It went live yesterday, it's free, and I didn't write the code. Claude Code did, over about six weeks of daily sessions.

Three things kept a project this size from turning to mush:

One design doc in the repo that every session reads before it touches anything. When a session and the doc disagree, the doc wins. Otherwise session 40 quietly reinvents what session 12 already decided.

Every architectural call written down as a numbered file - 194 so far. The model has no memory of yesterday, but it reads. The repo has to be the memory.

Nothing is done until a bot proves it. Scripted clients connect over the real network protocol and play: levelling 1 to 50, a 20-bot PvP match, six bots clearing a dungeon. They print PASS or FAIL. "The code looks right" is worth nothing when you didn't write the code.

Where it consistently failed was anything you judge with your eyes. The world ran at 20 FPS for weeks because animating one Babylon scene setting broadcasts an update that marks every material dirty, so the whole scene re-evaluated every frame. Nothing in the code looked wrong. You only catch that by playing it.

Six classes, two continents, levels 1-50, dungeons, a 12-player raid, world bosses, 10v10 battlegrounds. Desktop browser, no download, no launcher.

https://lythravel.com

It's brand new so the world is quiet — the Discord is where we agree when to actually play: https://discord.gg/SdJrn5WPBQ

Come and have a look around — I'm in there most days, and I'll come over and say hi.

https://preview.redd.it/rqdiebzlajjh1.png?width=2560&format=png&auto=webp&s=c573ddd3c5439f0db2e707bfe5361decb73c89cd

My daughter (5) asked for a game for a unicorn on her lunch bag, and since we have AI, I thought I would sit down and just build it. I let her play it, and then she would suggest stuff. So this went on for a bit; most of the major things are hers. She keeps wanting to add stuff, so I keep doing it. So after I built it, she really liked it, and was spending too much time on it, so I figured I would add some learning and phonics to it as cards at the end. I am at about a week and half, I maxed out my $200 plan and I had to do my real work with Codex.

For the assets what I did was have Gemini create sprite sheets, and I built a bunch of tools around fixing them. For one asset I had to pull it into Photoshop. I am a coder and I have some game development experience.

However, this project I have no idea what the code looks like, I did at one point ask claude to "organize the code to make it easier to do stuff". I do have this multi-stage coding system where I communicate with different terminals via a central command (VS code extension). An important part was involving playwright, not just at the end but through out so AI could spin up the game to a point, take a screenshot, and then make fixes based on the screenshot.

I don't know when I am going to stop or if it will become Unicorn Jump GTA6. I know I am going to be adding more characters and more worlds. However, it's totally free and can be played at unicornjump.com

The last 1,5 week has been quite an eyeopener for me - I must say that Claude Code and the current frontier models are amazing.

A test of Fable (and later Opus 5) turned into a larger game. It’s very much inspired by the tank element of Battlefield 1942 and the round-by-round build system from Overwatch 2’s Stadium mode.

About the game: You join a game and enhance your tank, then you go out and destroy the enemy while hunting for salvage which is used to enhance your tank even further (balance patches pending). Some of the features:

• 6 different tanks (Tiger 1 is a beast)
• 3 maps (a desert, grass and snow map with destructible terrain)
• Round-by-round build system
• Customisation of tanks
• Matchmaking system, lag compensation system, ballistic shells (direct hits only), hit multiplier regions (many tanks fall on a single rear hit)
• Bots who backfill if theres not enough real players
• ELO ladder system
• Replay/clip system
• In-game power ups
• Career profiles
• Group system
• Friends system
• 3 layered chat system (global, match and team)

Feel free to try it out – I’ll personally greet you ingame: https://sweatypanzer.com/

I would love to hear what you think, and kindly report bugs if you find any. Its currently optimised for desktop, but should work on mobile too.

you all know the ritual by now. you post your game anywhere outside this sub and the first comment isn't about the game — it's about how the game was made. steam makes you fill out a disclosure like you're declaring contraband at customs. the itch comments turn into a philosophy seminar. r/gamedev treats "i used claude" like a confession. and the actual game — the thing you made, that works, that's fun — nobody talks about that part.

i got tired of that energy, so i built whim (buywhim.com): a marketplace where AI-assisted is the default assumption, not an accusation. nobody's scanning your screenshots for six fingers.

how it works:

- browser games and apps run instantly — buyers click play, no downloads, no installs

- upload a single html file or a zip (three.js stuff works great), set a price or go free

- you keep 90%. no $100 fee, no review queue, no disclosure checkbox

- first listing's free

it's early and small, and i'm not going to pretend otherwise — but that's also the pitch: the first 50 people who sign up become founding members (free listings for life), and right now a founding member's first game gets featured on the homepage for a week, because there's room for you on the homepage.

i vibe-coded the marketplace itself, obviously. come look: buywhim.com — and tell me what sucks

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!

For the past 3 weeks, I’ve been making a game with Claude Code called “Fatherlode” (as a reference to the game Motherlode released in 2004 on Miniclip), whose goal is fairly simple:

You have a POD, you dig deeper and deeper, you collect ores, sell them, upgrade your POD, and so on. Back in 2004, Motherlode was extremely addictive — a small Flash game that was really popular. Here with Fatherlode, I’m adding more and more mechanics:

• A real tutorial, a proper introduction, and a save system
• Implementation of a stats tree system
• 250 achievements
• 25 different ores
• About thirty treasures to find
• Dozens of different obstacles
• Over 2000 meters of depth
• Real objectives with an NPC dialogue system, lore, etc.
• The ability to build new buildings as you progress
• Diversified creatures to make the descents more complex
• Etc.

For now it's only in french, but i will translate it later in english, obviously. The game is progressing well — it’s still a long way from being finished. Little by little, I’m mainly trying to add small gameplay details, mechanics, and overall polish, things like:

• “NPC talking gibberish” voices during dialogues
• Small effects scattered here and there
• Gradually refining the pixel-art so everything feels consistent
• Checking whether the exploration feels good, if the POD upgrades are balanced (and not broken), and improving that
• Etc.

Honestly, from the very beginning it was just a little crazy idea… and I find it so much fun — and addictive — to code the game little by little that I even want to learn how to code myself. I went as far as paying for Claude Max just to get more usage per week, and in only 3 weeks I feel like the project has absolutely nothing left in common with how it started.

I've been building The Hidden Realm, a free-to-play UK location-based walking game inspired by Britain's landscapes, history and folklore.

The slightly ironic part is that a lot of the development involved AI, but the game itself is deliberately designed to encourage people to spend less time looking at a screen.

I'm a solo developer and started the project in May. Claude has been a significant part of the process, particularly through agentic conversations where I describe what I want the Realm to do, work through the design and systems, and then iterate on the implementation. Nothing had write access to anything. Every change went in by hand, one at a time, tested before the next.

It's grown into considerably more than I expected:

• A native Android walking app with GPS tracking and server-side anti-cheat
• A web-based game hub
• Supabase/Postgres backend with server-side gameplay validation
• Three competing Wards contesting territory
• 40+ folklore-inspired creatures, influenced by biome, weather and time of day, some anchored to real-world locations
• A lore system that grows around where players actually walk
• Privacy built into the design, including automatic deletion of route data

The creature artwork is AI-assisted, and turned into 3D models players can examine in the game. I'd commission an artist if I could afford one. I can't, and the alternative was not building it.

But the core experience is deliberately simple:

Start a walk.
Put your phone in your pocket.
Go.

Walk with friends. Talk. Enjoy the scenery. Explore somewhere you've never been. When you finish, that's when the game reveals what happened.

Recently the 100th Beacon was placed, which unlocked the next chapter of the Book of Forgetting. Along with 500 player encounters of the Bell Tower Wisp creature. That's been one of those moments where something I designed on a screen has started becoming a world shaped by actual players.

The hardest part of the whole project, though, wasn't any of the code.

The game attaches real local history to real places, so the content has to be true. Confident, well-written, entirely plausible history is exactly what these models are best at producing, and it's indistinguishable from the real thing until you go and check.

A concrete example. A fragment about a shopping centre built on a former isolation hospital included the detail that it treated American and Canadian airmen during the wars. It reads well. It fits. The site did treat servicemen, and that part is documented, but the airmen detail had no source I could find anywhere.

So the rule I ended up with: history is verified against real sources or it doesn't ship. Anything I can't confirm is either dropped or moved into a category explicitly labelled as fiction, so nobody mistakes it for fact. Nothing goes in unread. That discipline has been more work than the database schema, and it's the only reason I'd defend the content at all.

The project is now live on Google Play in the UK, with players walking it in different parts of the country.

There's something quite satisfying about using AI to help build a game whose purpose is ultimately to encourage people to look up from their screens.

Real-world testing caught something I hadn't thought about. If you want to pause the walk to duck indoors or stop for lunch, you have to take the phone out, which breaks the entire point. So there's now a Wear OS companion app shipping soon that handles pause, resume and stop from the wrist. The phone stays where it is.

https://thehiddenrealm.co.uk

I'd be interested in hearing from other Claude users: what have you built that started as an idea and turned into something much bigger than you expected?

The first thing you need to know is I tell Claude to do all of this for me. There are some places I must intervene, but anything that can be automated is.

ChatGPT makes the 2D art. It's the best of the free image models at holding a dense multi-part layout, which matters because of the money trick: don't generate one prop at a time. Ask for a showroom floor. Every prop the set needs, spaced apart on a plain neutral floor like a catalog page, soft top-down light, faint contact shadows only. One image, whole kit.

Tripo turns it into geometry. Image-to-3D is 20-30 credits, a credit is a penny, about ten seconds per bake. One showroom bake came back with 39 usable textured props. Hero props and characters get their own multiview bake, 2-4 images ordered front/left/back/right, front mandatory. Single-view only textures the faces Tripo saw. That is where gray clay backs come from.

Python splits the bake. Not Blender's separate-by-loose-parts. Tripo geometry is unwelded and loose-parts shatters it into micro-shards; we measured 21,409 on one scene. Load the glb with trimesh, per-face centroids on the floor plane, rasterize, dilate, label. Each cluster is one prop with materials and UVs intact.

Mixamo rigs the characters, free, and one clip library then serves every character forever because clips bind by bone name. The catch: prompt the character in a wide A-pose, arms 40 degrees off the body, fingers spread, feet apart. Tripo's default pose stands at attention and Mixamo rejects it. A re-bake in A-pose costs 30 cents. Deforming a welded 75k-vert mesh by hand cost a day and got rejected anyway. Send Mixamo a stripped FBX, geometry only, about 1.78m. Reapply materials to what comes back.

Blender is quality control and export. Scale, ground the feet, check joints, decimate plus Draco plus 1K textures, under 8MB per glb.

The part most people skip: almost none of this is done by hand anymore. Tripo has a documented API, so the bake-check-download loop is a Python script: create the task, poll it, pull the glb, and the rig check endpoint is free, so a script can ask "is this riggable" before spending a credit on rigging. We run the whole chain through an AI agent (Claude) that calls the script, splits the bake, and files the props.

The other half of that is giving the agent write access to the real project folders. Claude works directly in the repo on my machine: props land filed under assets\props, renders land where the build scripts expect them, sources get patched in place. No download-unzip-drag step, no "final_v3 (2).glb" in a Downloads folder. The asset either exists at its path or it doesn't, and the same agent that put it there can re-open it tomorrow.

Blender is on that loop too, through MCP. The agent sends Blender Python over the bridge, gets renders back as files, and actually looks at them. That closed the gap that used to eat whole evenings: the tool that made the asset is now the thing that checks the asset, at every step, with a picture.

Then everything proves itself in a sandbox before it touches a game: a walkable three.js room where the avatar runs around the props with a follow cam. Collision, culling bugs, seam shimmer, animation drift, all of it shows up there in minutes.

One rule saved more rework than the rest combined: render and look at every claim at the right resolution. A full-body render puts 60 pixels on a shoulder and cannot show you a broken joint. Close-up per joint, front and 3/4, or you ship a defect stamped verified.

AI-assisted, human-directed and edited.

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

They wrote this in a notebook: "Once upon a time there was a little slice of watermelon who lived in a very happy town. He met a lemon who said, there's an army of germs coming! I suggest you go to the market that sells weapons, it's not very far."

That's the whole design doc. It's called Le Royaume des Pépins. A fruit kingdom gets invaded by microbes, you play the watermelon, you purify the place and take down the evil germs that wants to destroy the kingdom. Love how kids think out of the box.

They wrote the story and drew every character. I did the parts that needed a keyboard.

How it went

We used their notebook page as the actual spec and typed it in close to verbatim instead of me rewriting it into proper design language first. That mattered more than I expected.

Their drawings drove the art direction rather than the other way around, so the characters look like theirs and not like generic AI fruit.

The core verb came from asking her what the watermelon actually does. She said purify. So that's the verb, and everything else got built around it.

Biggest thing I learned: a 9 year old iterating live beats prompt engineering. She'd play for thirty seconds and say "the germs are too slow." That is a better bug report than most I've received from adults.

Disclosure, it's built with Sandscape, which is my own tool but we use Claude and bunch of other tools like Meshy and ElevenLab.

And it's actually pretty fun to play https://sandscape.app/play?g=pDdi6wlB

Happy to answer anything about the process.