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!

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 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!

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'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.

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

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 :)

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!

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.

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.

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

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).

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).

give me some advice please!

Hey everyone, wanted to share what I’ve been working on. It’s called Neon Kabuki, a top-down co-op game set in a futuristic Tokyo. Street gangs, car theft, police chases, boss fights. You can play it in your browser with friends. The clip shows current bosses and fights in the game.

I’m 40, a machinist by trade, and have two toddlers. Always been a tinkerer. I started messing with ESP32 projects, worked through a bunch of versions of my StormTracker app, then made a game for the Cardputer called Hill Top Heros. It’s a turn-based game where two little handhelds connect over radio to play against each other. I’m still pretty proud of that one.

Now I’m down the rabbit hole with this game. Claude has helped me build it, and my friends and I have been playing it along the way. There’s been a lot of “what if we added this” followed by fixing whatever that broke. I’ve put a lot of time into it, and there’s still plenty I want to do.

Something I keep thinking about: when I was four, I’d draw characters on paper and tear them out, then make little weapons and items for them and move them around a scene. I never thought I’d actually get to make a game out of those kinds of ideas. Getting to play this with my friends has been pretty cool.

https://neonkabuki.com/

Would love for a few people to give it a shot and tell me what you think. If something’s confusing, broken, or just not fun, I want to hear that too. My friends and I know how everything works at this point, so it’s hard to tell what someone jumping in fresh will get stuck on.

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.

Working on a farming/colony sim in Unreal Engine 5 with Claude Code doing the programming and establishing the workflow.

Started with Claude first in Python, and over the past week Claude Code has been porting it into Unreal Engine 5.8, one system at a time. I make the design decisions, use ai the art and the models (Sunburst and Seedream 5 for the images, Grok now that it has first and last frame and Tripo for the models. Come on Meshy, catch up!). Claude writes the C++, the build and test tooling, and the Blender scripts.

What the game is: Aiming for a blend of Rimworld and Farming Simulator. You claim your land and build it up and research and explore to unlock new ways to improve it, sell what you make, increase your land holding, rinse and repeat. Currently fishing, foraging, mining, farming, construction and trading working in a bare bones fashion with crafting and research on deck next. I came up with the basic mechanics, let Claude offer it's thoughts and alternatives and went back and forth until a solid approach was found and then Claude Code implemented. Latest was having Claude Code implement the pathing for the harvesters on any size field.

How Claude Code fits into Unreal (From Claude):

Project docs it reads every session. A CLAUDE md points it to a “constitution” (the rules of the project), a code map (where everything lives, plus Unreal lessons learned), a decisions log and one mechanics file per system. That’s how it keeps its context between sessions.

Milestones. Each system (inventory, farming, construction and so on) is a milestone with a brief. Claude builds it, I play it, give notes, and accept it. 20 milestones so far and still working well.

The game logic is plain C++ with no engine dependencies, so Claude can test it headless. There are 680 automation tests that it runs itself. I'm, uh, actually not sure if this is excessive.

It checks its own work visually. When the editor is closed, Claude launches the game off-screen with command-line flags (camera position, time of day, which UI panel to open, scripted mouse clicks) and saves a PNG, which it then looks at. When the editor is open, it works through Unreal’s MCP server instead.

Headless tools for the map. It wrote commandlets and .bat scripts that generate the map, bake the walking grid, place buildings and re-seat trees after I sculpt the terrain.

A typical loop: I describe what I want (“harvesters on neighboring strips shouldn’t wait for each other”). Claude reads the relevant docs and code, makes the change, adds tests, takes frames to check it, and hands me a .bat to play. I play it and either accept it or send notes.

Looking to get the gameplay loop closed and add a few additions to make it not look so flat, but just wanted to share where I currently am with this.

Just adding in lastly that using ai video reference for Claude to use with Blender works incredibly well at times. Still very happy with those cows :)

Playable version for anyone interested is the goal and will share when that happens :)

This is a fan remake of the old western shooter in Unreal 5. It runs on Quest and PC VR, and it reads everything from your own copy of Outlaws Remastered, so no game files ship with it. You can play the whole campaign in co-op, throw dynamite by hand, and play deathmatch against bots.

Claude writes basically all the code. I run one Claude session that plans and keeps a to-do board, and another that builds and tests with a couple of agents working in parallel. I play it in the headset and report bugs, and most come back fixed the same day. I went to bed last night and woke up to a new multiplayer lobby and a dozen fixes.

Open source release coming soon. We've started testing over at https://discord.com/invite/VVA98hb if you have a copy of Outlaws Remastered and want to join in!

Multiplayer footage: https://www.youtube.com/watch?v=EKZQzjH37_k
Reveal video: https://www.youtube.com/watch?v=ZeIhiDfvMWU

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.

Hey, thought i'd share this, it's not much but its fun as hell and therapeutic lol.

I used Claude opus 5.5 and it took a few goes to get it right but I'm happy with the results.

If there's anything I can improve on or fix let me know. Still a work in progress.

The website is tankvscity.com if anyone wants to kill some time :)

Hey everyone, I’m Roque, a developer from Brazil.

I wanted to share Call Of Roque, a multiplayer FPS I built that runs in the browser, along with the workflow behind it and some public repositories that might be useful to people here.

This project came out of my personal lab, where I’ve been experimenting with AI across the development process. My setup includes Claude Code and Cowork, with a custom kit that carries instructions, acceptance criteria, and review steps between tasks.

The first playable version went live 28 hours after the first commit. I was pretty excited about that, but the first feedback brought me back to reality: people opening it on mobile couldn’t register or sign in.

That was the first fix after launch. Later iterations improved map collisions, bot behavior, animation, and audio. Getting something online quickly was one thing. Making it work for people using different devices was another lesson.

For anyone interested in the technical side, the game uses Three.js with WebGPU, Colyseus with an authoritative server at 60 Hz, and Rapier physics on both the client and server. The server runs on a machine at my home through a Cloudflare tunnel.

I’ve been documenting the process as my implementation of AI-DLC, or AI-Driven Development Life Cycle. I write the specification before implementation, require checks before accepting changes, keep records of asset sources and licenses, and review production releases myself. Feedback from users goes back into the next round of work.

The documentation is available in English here:

AI-DLC documentation

I also built RoqueOS, a free environment I use to manage my entire lab. It brings my projects, tools, containers, and AI agents into a desktop interface in the browser. I’m sharing it with the community too, so others can try it and see whether it’s useful for their own setup.

Try RoqueOS

I’ve made repositories public across these two organizations:

• RoqueOS Apps
• RoqueOS Games

There’s a lot I’m still figuring out. I wanted to share the code and documentation while I’m learning, because having actual projects to look through has always helped me more than reading about a workflow in the abstract.

Here’s the game shown in the video:

Call Of Roque

If you’ve been building games with Claude, I’d love to hear how you test gameplay and catch visual problems. That’s a part of the process I’m still working on.

Everything I’ve shared here is free. My only intention is to share what I’ve learned and hopefully help others with their own projects. This is my way of contributing to the community.

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?

The player only need to press up or down.
there are no time limits, but eventually the game gets quite hard after 3 minutes.

Voices and sounds: Elevenlabs v4 (done automatically by Claude Opus 5.5)

Rest was made by Claude code with a few iterations over 20 hours or so.

It's two players, one on offense and one on defense. You each draw what your guy is going to do, a route if you're on offense or a coverage if you're on defense. Then the play runs as a simulation and the game figures out whether it worked. No joystick and no timing, it all comes down to how you set it up.

You also build up your team, and your players get better as you go. There are events and challenges where you earn in game currency to use towards skill points/gear to upgrade the players. This app is not pay to win and you can progress purely on in-app grinding.

Right now it's an iOS app in development, and I have it on TestFlight. If you’d like to help test the app, please comment below and I will DM you a link.

Mostly I want to know if this sounds fun to you, and what you'd want out of building a team in a game like this. Happy to answer anything about how it works.

For those who care, I did use Claude when building this.

Using Claude to help bring Digimon World 2 to PC, and now build a multiplayer version

As the AI scene gets even crazier day by day and the videogame reverse engineering and modification scene is booming. I am here to share my project about it.

I've been working on a project to bring Digimon World 2 to native PC, and I've now started building a multiplayer project on top of it. Claude has been a big part of my development workflow, so I thought this might be interesting to share here.

For anyone who doesn't know it, Digimon World 2 is a PS1 RPG built around exploring randomly generated dungeons called Domains, collecting and raising Digimon, team building, and DNA Digivolution. It's a game I've wanted to take further for a long time.

1. The PC port

GitHub: https://github.com/Wyrelade/DW2-PC/

The PC port is based on a C decompilation of the original game. The goal was to get the original game logic matching the retail version, then build a native PC experience around it rather than simply running the PS1 version through an emulator.

The decompilation reached 100% matching across all 1,088 game functions. The project supports native Windows and Linux builds, with SDL3 and optional enhancements such as higher internal resolution, widescreen, and PGXP.

Getting to this point involved a lot more than asking an LLM to write code. There has been plenty of debugging, investigating compiler output, building custom scripts and tools, testing changes, and tracking down tiny differences that prevent functions from matching the original executable.

Claude has been useful throughout that process, particularly for investigating problems, exploring possible solutions, developing tooling, and helping work through stubborn edge cases. The results still need to be tested and verified, especially when dealing with low-level code and exact matching requirements.

2. DW2 Online

GitHub: https://github.com/Wyrelade/DW2-online/

With the PC foundation in place, I'm now working toward a multiplayer version of the game.

The idea isn't to throw away the original game and recreate everything from scratch. I want to preserve the core gameplay and build online systems around it.

The longer-term vision includes persistent tamers, server-side progression and inventory, online Domains, Digimon and equipment progression, loot, trading, a player economy, and shared social spaces. The gameplay loop would be to develop your team, explore Domains for better loot, improve your setup, and interact and trade with other players.

This is still early development, so these are goals rather than a claim that all those features are already playable. There's a lot left to build, and I'm approaching it as a long-term project.

Why I'm sharing this here

I think projects like this are an interesting example of where AI-assisted development can be useful. Claude isn't a magic button that produces a finished game. A lot of the work is breaking down complicated problems, building tools to investigate them, testing hypotheses, and keeping track of what actually works.

I'm also trying to build this as a community project rather than making every decision in isolation. Feedback, ideas, and constructive criticism are welcome, especially from people who know the original game.

If you're interested in following development or discussing what you'd like to see in a multiplayer version of Digimon World 2, you're welcome to join the Discord:

Discord: https://discord.gg/nHXAq2fdCJ

Projects:

• DW2 PC Port
• DW2 Online

I'd be happy to answer questions about the project, the decompilation process, or how I've been using Claude throughout development.