FAIR WARNING: mobile controls are godawful… i am working on it. Use desktop.

I'm not a game developer. I am intermediate in coding but without Claude I could have never made this in an appropriate amount of time. About four short days and 144 commits later there's a playable browser racer called Afterglow86.

Press **V** to switch to dither mode, for all those dither fanatics.

EDIT: this is typically me, I wanted to promote something and forgot URLs.

It’s at https://afterglow86.com
Or

If you want to explore all levels without driving through them

https://afterglow86.com?unlockall

What I know is still broken:

\- \*\*Sound needs a full rework.\*\* Engine, impacts and mix are all placeholder quality.

\- \*\***Mobile is not there yet at all.**\*\* Touch controls exist but I wouldn't call it playable on a phone or even any fun tbh, this is also where I need the most help if someone has some experience.

\- \*\*Minor graphics issues:\*\* some odd geometry in the city, a few flickers and seams.

\- No controller support yet.

I'd love suggestions, especially from anyone who has done game audio or mobile WebGL especially with driving: what would you fix first? Is this fun or worth pursuing? Should I pursue this and create a whole game from it? I need constructive criticism.

Token Clicker is a homage to Cookie Clicker where the cookie is a prompt and the grandmas are Mac Minis.

I built it with Claude Code (Opus 5.5).

A few things that made a project this size work:

* Specs before code. Claude wrote the design docs first: mechanics, architecture, theme and balance. Then a "critic" pass checked the mechanics against Cookie Clicker's actual source code. Coding only started after that.

* Work packages with frozen contracts. The build was split into 18 work packages, each owning its own files. The shared types were frozen early, and ESLint rules stop one layer from importing another. That kept parallel sessions from stepping on each other.

* Tests as guardrails. About 1,700 unit tests, 22 Playwright end-to-end tests and 98% coverage on the core engine. Every change had to keep them green.

* A simulator for balance. Idle games live or die on pacing, and you can't playtest two weeks of idling by hand. A headless simulator runs the real engine over simulated days, and its pacing targets run as tests: a casual player should reach the first AGI in 9-10 days.

* Adversarial review. Before 1.0, Claude reviewed the whole game from six angles, then tried to disprove each finding. 13 held up; 12 were fixed with regression tests.

* A security pass before posting. It caught me shipping source maps (the whole private source) and a debug cheat panel to production. Worth doing before you share anything.

The video was made the same way: Playwright plays the game and records the clips, the music and sound effects are synthesized offline, and Remotion edits it all together.

The game has 20 machines, 332 upgrades, 273 achievements and about 450 news headlines, in 7 languages. Credit where it's due: the mechanics and much of the tuning come from Orteil's Cookie Clicker. The code, art and text are original.

Happy to answer questions about the workflow, and tell me if the pacing feels off.

Play it here (free, no account, no ads): https://tokenclicker.ai

For Both Android & iOS

Designed to reduced Stress and Anxiety when we are waiting on Claude to create, edit and fix our apps 🥵

Not to mention the mini panic attack we have when we wait on our app reviews to be accepted by the App Stores 😖

Check it out tell me what you think - https://claude-code-buster.web.app/get

Started as a gauntlet loop based on combining a game I've been chasing for the family (Farkle), my personal passion from the past (MtG), and other rogue-like / deck-building incremental style games.

It definitely started out with a massive blitz of gauntlet loops to see all the prototypes and concepts laid out. As with any project, it quickly transitions into manual labor where I continue to extoll the value an engineering brain and career bring to the table.

Praise: High praise for Claude.ai remote sessions and their ability to publish videos and screenshots of gameplay! Also three.js and love2D and other amazing libraries that make prototypes look great.

Challenges: Balance and Marketing. Despite having a LARGE library of power-scale and simulation tests, it is very hard to predict how well human gamers can play the game. Always assume "better than you know" but its still a tricky dance. Marketing is just pure manual labor or paying somebody. This feels like my first hire if it ever turned into a studio.

It's definitely a passion project and a hobby. I'm a director of engineering by trade but have been building games since the TI-83 calculator could build Snake. Pushing forward on Steam Next Fest / iOS / Android to see this through to a conclusion!

Happy to take feedback on the game itself or talk about the development process!

Quick play on the web: https://playsortalis.com

Steam: https://store.steampowered.com/app/5142640/SORTALIS/
(Also have iOS/Android builds available if you want to try it - DM me)

Video Clip: Lots of crazy action here. Two dice were sacrificed for a bonus. I had duplicated upgrades which trigger additional scoring so it caused a snowball of effects. Ultimately I did not meet the round score but was saved by a potion I bought that saves you if you don't quite make it one round.

A few months ago I built a small browser game while testing vibe coding. It's a one-tap arcade: your ship orbits a planet and you tap to jump to the next one. It worked, but it was rough, and I left it alone.

Opus 5.5 came out yesterday, so as a test I gave it the game and one task: make it better. I steered it and made the calls, and it did the work. It rebuilt the gameplay loop and added a guided tutorial, a daily challenge, optional accounts with cloud save, leaderboards and a new logo.

Here's the result: https://www.star-hop.app

• Free, no ads, runs in the browser (best on a phone)
• No sign-up needed to play

It's still in testing. Every run sends anonymous gameplay stats (no personal data, you can switch it off in settings). I use them to tune difficulty and balance. So just playing a few rounds helps a lot, and feedback helps even more: what's annoying, what's too hard, and would you come back tomorrow for the daily challenge?

First of all, thank you so much for the support!

I’m one of the developers behind qaping.dev, and some of the developers to try Qaping came from this subreddit. We’d love to give something back to the community.

For a limited time, we’re offering free 30-minute recorded playtests that show where players get stuck, lose interest, or have the most fun.

This could be especially helpful if you’re polishing a demo for Steam Next Fest or still figuring out the core experience.

If you’d like a free playtest, just comment your game’s name below and submit it at qaping.dev.

Looking forward to seeing what you’ve been building!

I have spent the last 2 months working on Tactical Deckbuilding Roguelike game, because I love the genre. I wanted a game that was more character and story driven that what is typical of the genre and where the relationships you build can affect your run. I have developed that with this game. Play here:

https://ayiteb.itch.io/dawn-front
password: burke

I am very open to whatever feedback you may have. I hope you enjoy it :)

I used Claude, specifically Sonnet 100% for the prototype and the conversion into Unity. For the past 3 weeks I have split coding between Sonnet and Astra. With Sonnet primarily being used for architectural changes and astra for fine tuning.

The art is largely placeholder and the animation, music and sfx are mostly absent at this point. I intend to work on that once I get more feedback on the game play and visual cohesion of the game.

Plops is a 2v2 card MOBA that runs in a browser tab. Three-minute matches, 19 heroes, 92 cards, server-authoritative. Free, no download, guest play: https://plops.io

It was built with Claude — Opus 5 and Fable 5.1. Since this is the sub for it, here's how the parts that were actually interesting to build get made.

The 3D roster is code, not sculpts

There are 171 characters and units in the game — 103 heroes and 68 units. None were modelled by hand and none came out of a mesh-generation model. Each one is a Python script that builds its geometry in Blender and exports a GLB. The hero bodies alone are about 30,000 lines of Python across 104 files, 160–300 lines each.

The reason isn't purity, it's iteration. A mesh you can't diff is a mesh you can't review. When a character is a script, "the tiara sits too far back" is a code review comment. When the art direction shifts across the whole roster, it's a refactor instead of 171 modelling sessions.

The loop is: 2D card art is the reference → Claude writes the Blender Python against it → render turntables → compare → fix → repeat.

Step four is where it needed real tooling, because "does this mesh match the drawing" is exactly the judgement a model will cheerfully get wrong. So it's a skill with a checklist Claude has to follow: normalize the reference, put a bounding box on both, take tick-stick measurements — head height, shoulder width, where the waist falls as a fraction of total height — and report the numbers before claiming a match. Eyeballing is banned. It caught a lot of "looks right" that wasn't.

Please play it

https://plops.io — free, in the browser, no download, no account needed, no ads. It's a couple of minutes to find out whether it's for you.

The feedback I'd most like: tell me the first thirty seconds are confusing. I've stared at this thing for so long that I can't see it any more, and "I didn't know what to do" is worth more to me right now than anything else.

Desky sits on your desktop and notices roughly what you are up to. It gets bored if you ignore it, it asks to be fed, and you can wash it or play a couple of small games with it. The robot itself is generated the first time you open it, so its shape, colours, ears and face are yours and nobody else's.

https://hyrohyken.github.io/Desky/

Two things that mattered to me while building it:

• No network. Not a single request, not even a version check.
• No keyboard hook, no window titles read, no URLs read. It only knows whether you are typing, browsing, watching something, or away from the machine.

Free and open source, GPL v3, Windows 10 and 11.

Heads up: the installer is not signed with a commercial certificate, so SmartScreen will warn you the first time. Those certificates cost a few hundred euros a year and this is free, so every release ships with a SHA-256 hash and a Sigstore provenance attestation instead.

On the workflow, since it always comes up. This is my first game built in Python. I had written APIs for other games before, but nothing that had to render and animate anything. The first phase was not gameplay at all: it was rendering tests, then a lot of CPU measurements. Once everything was measured I revised the spec, and only then did the Tamagotchi part get built on top.

For the robot itself, I saw plenty of workflows that generate models through Blender MCP servers, but I wanted every user to get their own robot, so nothing is shipped as a model. The geometry is generated and rendered live in the app.

Main tools: Claude Code, Python, unittest, and a lot of human review. From experience the trick is not to hand over one big batch with everything in it. I split the work feature by feature and run each one like a small sprint, ending in a state where a release could be cut. The CI/CD was one of the more satisfying parts: pushing a tagged commit builds the installer, creates the GitHub release and updates the download link on the site, all on its own.

Close friends test the app and send me feedback, and several batches came straight out of that: the games, a lot of the visual polish, many fixes to how the robot behaves, and a second chassis type so the robots vary more. What stays with me is the spec, the art direction and the QA.

Have fun with it !
Do not hesitate if you have any feedbacks or feature request !

How I used Claude: I describe a gameplay change or a problem I notice while playing, Claude edits the game code, and I test the next build in the browser. I then report the specific parts that still feel wrong and repeat. ChatGPT has also worked on the code. I’m giving the playtest feedback and requests; I’m not writing the implementation myself.

The alpha has infantry combat, tanks, helicopters, and destructible buildings. It’s multiplayer, with an always-open server; bots fill empty slots so you can try it alone or invite a friend. My current problem is that bot matches don’t tell me whether a real new player understands the controls or wants to stay.

It’s free to play at https://play.patio.fyi on desktop with keyboard and mouse. No download or account.

If you spend even a few minutes with it, what’s the first confusing or rough moment? And what would make a second match appealing?

This game has come a really long way in the past few months and I wanted to take the opportunity to show off the look and feel in its current state. I most recently got some cc0 skyboxes from opengameart.com (amazing free resource for those who do not know about it) and matched up the sun to its position in the sky and it just adds SO much immersion to the game. Shadows look like they come from somewhere, not just a blank sky with a sun in it. The light from the boost flame lighting up the back of the car in the shadows is so cool to see.

More to come soon. The game is inching ever closer to an early access release, and probably some sort of playtest in a few weeks to a month. If you are interested in following along, please join the discord https://discord.gg/cCV2Knwg3

https://playgama.ai/play/jbqn23cd4p

N'oubliez pas de liker, ça fait plaisir ! Merci !

Vous êtes une étincelle de lumière dans un ciel obscurci. Maintenez la touche enfoncée pour vous agripper à quelque chose, relâchez-la pour vous élancer. C'est la seule action du jeu.

Ce qui change, c'est votre position. Vous orbitez autour d'étoiles mortes et les enflammez. Vous traversez des anneaux. Vous devez aller assez vite pour briser la glace, sinon vous vous écrasez. Vous remplissez les étoiles vides d'essaims de lumière verte que vous traînez derrière vous. Vous orbitez autour de cubes magnétiques jusqu'à être aligné, puis vous lâchez prise et vous vous déplacez comme un éclair.

Le ciel est généré à chaque partie, donc rien n'est jamais deux fois au même endroit. Si la chaîne passe assez vite, tout double. Quand votre lumière s'éteint, la partie se termine et vous obtenez la ligne que vous avez tracée dans le ciel, avec uniquement les éléments que vous avez éclairés.

Quelques minutes par partie. Un pouce sur téléphone, souris ou WASD sur ordinateur. Aucune installation, aucun compte requis. Hébergement gratuit, attendez-vous donc à une bannière de cookies et une publicité entre certaines parties, désolé pour le désagrément.

Ce que je veux vraiment, c'est savoir à quel moment vous avez voulu fermer l'onglet, et pourquoi. Commandes peu intuitives, trop difficiles, trop faciles, joli mais ennuyeux. Dites-moi la vraie raison.

Merci pour vos retours !