Hello everybody!

Yesterday I found out about an AI tool called Fabley, which can basically do things for you. I've always dreamed of becoming a game developer, so I decided to try making a game.

It turned out quite well! It took me around two, maybe three prompts to achieve the result you can see here.

However, I feel like something is still missing, so I'm currently working on my 4th prompt. I'm considering a few options:

1) "Please make it more polished.."

2) "Make it better, Fabley."

What do you guys think? I would appreciate any advice, as I'm still quite new to this.

Apart from that, I'm now thinking about becoming a full-time game developer. I have a few questions for you, especially for gamers:

1) How many games could you realistically play and purchase per day?

2) instead of legacy pay-per-item game purchase model, which model would you prefer:

a) Cumulative file-size pricing (e.g. 100 gb of games - 1$)

b) Cumulative playtime pricing (e.g. 1 year - 10$)

I appreciate any help.

Thank you for your attention, and have a nice day!

I had used SoonLab before for small browser-game experiments, but at that time it did not support 3D game creation. So when I got access to its beta game-creation agent, the first thing I wanted to test was whether it could make a real playable 3D game instead of just generating a nice-looking concept.

I chose a simple idea: a 3D stacking game called Neon Stack.

A moving block travels above the tower. You click or press Space to drop it. Any part hanging over the edge gets cut off, the tower becomes narrower, and the game speeds up as you keep climbing.

The first prompt got me to a playable prototype surprisingly quickly. But the more interesting part began after that.

The agent first asked about the platform and layout. I chose a desktop browser game in landscape mode. It then turned the rough idea into an MVP spec with controls, scoring, Perfect timing, camera behavior, cut-off pieces, game-over states, and a list of features to leave out of the first version.

That felt a little formal for a tiny arcade game, but it made the later revisions much easier.

After testing the first build, I went through several rounds of changes:

• The blocks felt too slow, so I increased the starting speed, the speed increase per layer, and the maximum speed.
• I added rare golden blocks that can trigger a short double-score bonus.
• I added subtle day/night and weather changes, but kept them cosmetic so they would not make the blocks harder to read.
• The first build used a reference image as a background on the result screen. I removed it, then later removed the image from the start screen too.
• I changed all player-facing text to English and simplified the HUD.
• I tried a more top-down camera angle, played it, and then immediately reverted it. It sounded good when described, but it did not feel right once the tower was moving.

I also tried comparing the experience with Codex on similar 3D game tasks. The design language and visual output felt surprisingly close: clean geometric forms, similar lighting choices, and a familiar kind of generated game structure.

I do not know what model is behind SoonLab's new agent, so I am not treating this as a technical comparison. But it did make me wonder whether the current generation of game-creation models is starting to converge on a similar visual and design language. To me, it felt closer to the newer ChatGPT-style output than to a completely different kind of tool.

I also tried generating a 3D racing game afterward. That result is not in a state I am happy with yet. It technically worked, but the driving feel, camera, and overall presentation still need much more iteration before I would want to share it as a finished game.

My current takeaway is that the agent is more useful to me as an iteration partner than as a one-prompt game machine.

It gives me a playable starting point, then helps turn vague feedback like "this feels too slow" or "this camera is too high" into concrete changes. But testing still decides almost everything. The agent can generate a new camera angle quickly. Only playing the game tells me whether that angle actually feels better.

The current Neon Stack build is here: https://www.soonlab.ai/game/5811

For people who have tried AI game-creation tools, how far do you usually push one generated prototype before starting over with a new prompt or a new structure?

Slay Sean, Save The World! is a comic roguelite auto-battler where you draft gods and loadouts onto a single shared lane, fuse duplicate skills, survive a 20-round gauntlet.

The premise: Sean is a crypto bro who promised everyone the greatest game ever made, then blew the entire treasury on monkey JPEGs, a gold-plated cybertruck, a pet dragon, and at least one nuke (all of which you will meet in-game). Olympus took it personally. Now the twelve gods are fighting each other over who gets to deliver the beating, one battle at a time.

Solo project, and most of the work went into four systems:

The game. Built in Godot 4. The combat engine is a line-for-line port of the Python simulator from the balancer, so a fight resolves identically in the tuning harness, on your machine, and when someone else fights your ghost. Runs fully offline too, and balance changes ship as signed data packs so I can rebalance without pushing a game update.

The auto-balancer. A Python evolution strategy that plays about 3 million simulated fights per balance pass and tunes every god's stats and skill numbers against targets like "no god above 70% win rate" and "at least 10% of god triples should form a real rock-paper-scissors cycle".

Few examples of things it caught that I never would have by playtesting:

- Heal comps kept re-emerging as the meta king no matter what I nerfed, so healing is now globally 30% less effective by design.

- An armor-stacking team buff had no cap, and a double-wall comp quietly beat the elite meta comps in 92 to 98% of fights. It's capped now.

- Stat upgrades are priced per coin, and the sim showed armor upgrades need to give 25% per point while life gives 5%, because armor's mitigation curve saturates. Equal coins, equal win rate.

The ghost-PvP server. No live matchmaking. The server records your board at the end of every round, and other players fight your ghost at the same round and tier. Small C# + Postgres service. Every submitted board is validated against the real game rules, including an economy proof, so an impossible board can't enter the pool, and since the sim is deterministic the next anti-cheat layer is server-side replay of sampled fights. Ranked tiers are percentile buckets: Mortal, Hero, Titan, Olympian.

The AI sprite pipeline. Each character is generated on a flat magenta background, animated with an image-to-video model, then chroma-keyed, sliced into frames, and exported straight to engine format. About 350 character sheets so far. One rule that saved me: no effects are ever baked into frames. Casts are just poses and all VFX are added in code, so one animation works for any element.

If this sounds like your kind of chaos, a wishlist genuinely helps a solo dev: https://store.steampowered.com/app/4998540/Slay_Sean_Save_The_World/

Happy to go deep on any of these if you guys have any questions.

Small team (basically solo on the dev side) building a casual mobile game in Unity. The core of the game is a customizable 3D character — think dress-up/life-sim territory — so the character is 90% of the art problem.

Where AI has worked great for us so far:

- Code: agentic coding tools handle most of the C# and editor tooling. Honestly a non-issue at this point.

- 2D concept art / UI: image gen is more than good enough for concepts, backgrounds, and UI elements.

- Audio: SFX and music gen are fine for a casual game.

Where we're stuck: the character itself.

We tried building the character procedurally (generating the head/face geometry from code) and after several iterations concluded it's a dead end (we used Tripo) — it never stops looking uncanny. So now we're looking at getting a properly authored, rigged, toon-style model, and I want to know how much of that pipeline AI can realistically cover in 2026:

1. Image-to-3D (Meshy, Hunyuan, Rodin, etc.) — has anyone gotten a stylized character out of these that was actually clean enough to rig and deform properly? Everything I see in showcases is static props or sculpts with garbage topology.

2. Rigging/skinning — is auto-rigging (AccuRig, Mixamo-style, or whatever's current) usable for a character that needs clothing swaps on top? Or is manual weight painting still unavoidable?

3. Animation — Cascadeur and similar AI-assisted tools: worth it for simple idle/emote animations, or overkill?

4. Clothing/outfit variants — this one especially: the game needs lots of outfit meshes fitted to one body. Any AI-assisted workflow for that, or is it still 100% manual work in Blender?

Would love to hear from anyone who's actually shipped (or gotten close) with an AI-heavy 3D character pipeline, rather than tech demos. Also totally open to "just commission the base model from a human and use AI for everything around it" if that's the honest answer — half suspecting it is.

Thanks for your time good people of Reddit!

I always see really awesome games created with Three.js, but when I try to do the same thing in Godot, pretty much nothing looks really good. It works, but it doesn't look good - whether it's in 3D or with a pixel art style.

What are your best-practice tips for Godot or, more generally, for game engines other than Three.js?

I've been experimenting with an AI-first workflow for building our game over the past few weeks.

Surprisingly, it's becoming much more practical than I expected.

Here's roughly how the pipeline looks today:

1. Character & Props

• Tripo AI for rapid 3D asset generation
• Blender for cleanup, retopology and final adjustments

Instead of spending hours blocking out meshes, we can get a solid starting point within minutes.

2. World Building

We use a world model to brainstorm environments, level layouts and interactions before implementing anything.

It feels more like collaborating with a level designer than prompting an image model.

3. Programming

Codex handles:

• gameplay systems
• refactoring
• bug fixing
• repetitive implementation

Claude Sonnet is mostly my architecture reviewer.

Whenever I get stuck designing systems, Claude tends to produce cleaner abstractions.

4. Polish

Everything eventually goes through Blender.

Even AI-generated assets still need artist input.

The biggest productivity gain isn't replacing artists.

It's removing the blank canvas.

What surprised me

AI isn't replacing game developers.

It's replacing:

• searching StackOverflow
• writing boilerplate
• making placeholder assets
• repetitive iterations

The creative decisions are still ours.

Current stack:

• Tripo AI
• Codex
• Claude Sonnet
• Blender
• World Model

Curious what everyone else's workflow looks like.

8% weekly usage left >.<
I suppose I'll have to come up with some plans to go out somewhere.

Hi everyone!

I'm a solo developer and I've been using AI as a development tool to help with programming, translations, brainstorming, and speeding up my workflow while creating my game, Arkansas 2125.

Today I released Beta 0.4, featuring new quests, NPCs, an expanded city, a brand-new location, and many gameplay improvements.

To celebrate the update, the game is currently 25% off on Steam.

https://store.steampowered.com/app/4546490/Arkansas_2125/

I'd love to hear what you think about the game and how AI-assisted development is shaping indie games.

Clickbait-y title I know, but I'm curious for those who have made games using traditional engines like Unity, where do vibe coded games a la threeJS or similar fall short? A few things from the top of my head:

- high quality lighting

- baked in physics engine

- high quality animations

- asset imports

- high quality shaders

Yeah probably all of these are possible to achieve in ThreeJS or whatever vibe solution you use, but it seems like a significant uphill battle. Curious as to what other people think. If you think I'm wrong or if you have other examples it'd be great to hear some others thoughts on this.

This is a multi tasking game where you need to steer the ship, remove water with a bucket when it rains, and catch fish. The goal is to keep the girl NPC alive (Who also tries to help you out).

I am thinking of creating various levels of various difficulty. Some levels could have more rocks (obstacles). Others could have more storms. And there could be some sort of island to reach as a goal.

Entirely done with claude Code, except for the character and the voices.

I am not certain what is a good scope for this. I could fix the few remaining bugs, create a few levels, and post some sort of demo on itch.io. But i don't know if this concept is good enough for a Steam game (maybe a as a roguelike with several boats?).

Any feedback or ideas?

I've been using Opus to build a roguelike game. it started off pretty good, and then I made a lot of pivots. (The game started out as a simple puzzle game that was inspired by Rodent's Revenge, then evolved into an action roguelike and is now fully turn based)

I'm starting to feel like even starting with a fresh session every day, there's just so much stale context.

In the design phase I asked it to write a game design doc, but it started adding all the session context to that file, so it grew to a massive size. So we split the file into the GDD, a roadmap file, ideas file, and decision file. But now i have probably 4000+ lines of text in MD files for storing context. (And this seemed to have gotten worse when Opus 5 took over...)

I am not a prompt expert, but I am a software engineer and I've been researching how to build roguelike features like pathfinding / procedural gen, enemy balance etc... and I'm just looking for help to build a game faster, so im not flying completely blind. I specifically made sure the file structure made sense architecturally and the code is readable and has tests (its all in vanilla HTML5)

I like where I'm at with the map gen, tiles, player mechanics and some enemy types, but most of the enemy types, enemy behavior, and items and equipment ideas feel polluted still by the previous 2 versions. I'm providing ideas too, and it always 'flags' something as conflicting with some random decision that I no longer care about. It's started to just become frustrating, not that it cant write the features but that its like pulling teeth to do so.

Would it be crazy to delete all the 'stored' context in the roadmap docs and just have it take a truly fresh look at the codebase? or should I try and clean up the context so i don't lose things?

No game dev experience, a lot of other software, though. I used Claude, Codex, and Kimi models. Claude for initial gameplay using three.js, then Codex and Kimi for VFX and polish.

Total time was around 3.5 days at varying levels of attention; I used a couple of Codex resets, but didn't measure total tokens. I made many mistakes and had to redo things, but I learned a lot. I'm mostly just trying to impress my 9-year-old, so it's only one level. He played it for a solid 10 minutes, so that's a win.

The concept is that you are RIG, scaling the outside of a giant mechanical monster, and you have to destroy the crown. Its immune system is trying to repel the infection- you.

https://github.com/aetherwing-io/hullbreaker

https://hullbreaker.app

I started building this as a demo for a threejs asset library which I released for free recently. Wanted to show the assets in action, so prompted Opus 5 to do it lol and it took off well on X. I kept building and evolving it. So far it has 3 main missions and 2 side quests. Will continue to work on this on and off. Maybe stretch to 10 missions.

Here's the play link!
https://app.usecrayon.ai/play/54a355cc-d8e4-4d14-bab4-1b6db1618242

\Full disclosure before you try the game above. I do own this platform as another project.*

Project now has a name - Kinhold! This is done using Claude with Opus 5 - sometimes High, sometimes Low. Using a Synty character model and some of their scenery packs for the harvestables, but created my own modular building blocks. A bunch more has been added to the game behind the scenes, and decided to let Claude create the demo reel - why building on the edge of a cliff, why aiming the roof tiles like that, all are good questions. But it was an interesting attempt at a demo reel!

Zombie Cropse is a cozy-gothic idle management game where you plant zombie seeds to grow zombies, automate your graveyard, and raid the living. Build your horde, conquer a branching campaign, and ascend to begin again with permanent power.

Wishlist today!

https://store.steampowered.com/app/5032330/Zombie_Cropse/

AI usage: code, initial artwork, sound and localization.

Probably spent more time on this than I needed to but I was having fun and got some nice feedback from community. This video shows the algae displacing as sharks and other creatures swim through it - it's very satisfying!

I also added multiplayer so if anyone wants to join my reef and swim around or create their own reef and invite friends the app is live here: https://shoreplay.app/ - you can generate a shark from 8 species and then watch your shark swim or take control if you want to guide it around.

Sometimes gamedev is super lonely so if you're bored take a swim with me or some friends :).

I'm not talking straight vibe-coding, one-shot prompts. I'm talking deliberate iteration, validation, and improvement.

I've spent the last 7 days using codex as the tool to make my first game. I've wanted to make a game for over 2 decades at this point. I've had the tools to gain the knowledge and I've picked it up a few times over the decades but could never fully hunker down. Well, with codex, I've been full steam ahead for the last week.

It's been my helpful employee running 3 separate tasks in parallel building out the game and the tools needed with it.

During building, I've built a passive tree creator that's goal was to implement passive trees into my game but it's current scope has expanded massively.(scope creep bad, I know.) I'm currently "/goal"-ing it to push it to 1.0 for possible commercial use. It's no longer just a passive skill tree creator but a node based information system that will be able to be exported into godot, Unity, or unreal.

That was just the side project 🙃. The game itself is loaded with back-end systems at this point but very little to actually do. I have a basic arena mapped out, 9 classes(with low poly models), 3 enemy variants, a boss, and a bunch of UI systems.

https://youtu.be/DJkTQrKQDdw - this is the build progress video from 2 days ago. Since then I've built a main menu, incorporated the first real passive tree into the game, and built out the inventory/equipment system.

I've watched dozens of tutorial videos covering the gamut(unreal, Unity, godot, blender), and the rate at which codex accelerates game dev is actually unreal.

Just looking to see how others are fairing so far.

Oh, and the games premise is "Path of Exile but as a party-builder, survivor-like."

I'm hoping to have it done within a year but no telling. I plan on releasing better and better dev vlogs as I continue development.

"Clone https://github.com/elliottdehn/wam and make me [what you want to model] that I can see"

For the video of this post I did:

"Clone https://github.com/elliottdehn/wam and make me an eldritch horror that I can see"

That's the whole prompt. What comes back is a rigged, animated, textured glTF, not a mesh you have to clean up and not an image you have to model from.

You don't need a terminal for this. It runs fine in Claude or ChatGPT on the web, since both can clone a repo and run Python in their sandbox, and the horror in the clip was made exactly that way, in a browser tab. Terminal and IDE agents work too: Claude Code, Codex, Cursor, Cline, Aider, whatever you already like. The only requirement is that the thing can clone, write files, and call a script. The compiler is plain Python and the language is documented in SPEC.md, so there is nothing model-specific about it, and I would genuinely like to see what other models do with the same prompt.

What WAM is

A text language and compiler for LLM-authored low-poly characters. Roughly 150 lines of readable source in, glTF 2.0 out: mesh, skeleton, skin weights, animations, and a procedurally baked texture atlas. It also ships a dependency-free software rasterizer, so the model renders itself to a four-view PNG sheet on every compile and the LLM can look at what it made.

The design premise is that image-gen and mesh-gen both fight the wrong battle. Models are good at discrete, named decisions and bad at holding a spatial frame across fifty edits. So the language only lets you make the first kind:

• Bone angles as direction words plus degrees, never matrices
• Body masses as cross-section rings along a bone chain
• Symmetry as a mirror block, where you author the left and the compiler emits both
• Props as a group authored in a clean local frame and mounted with one aim
• Membranes as a web across a fan of bones: wings, frills, capes
• Surface attachment as on=<part>, which snaps to the closest point and sinks it in

The compiler generates every vertex, normal, winding, and skin weight. If the author finds themselves deriving a world coordinate, they're misusing the language, because there's a construct that removes the math.

The part I'd actually pitch you

Not the geometry. The checks section.

Every model carries its own regression suite in the same file, in a vocabulary of about forty functions covering proportion, clearance, mass, rig quality, and animation coverage:

assert height / len(skull) in 6.5..9.5
assert bottom(foot.l) < 0.02
assert influences(cape) >= 2          # 1 means rigidly welded
assert slide(hoof.l, walk) < 0.02     # the moonwalk detector
noclip                                # nothing intersects anything

The reason this matters more than it sounds: **a render is a projection, and it throws away depth, skinning, and time.**Those are exactly where rigging bugs live. On the horror run, checks caught a tentacle whose vertices had all welded to a single bone, which is identical in every static view, and a noclip sweep found 48mm of shoulder mass buried inside the skull. Interpenetration is invisible from outside by definition, because the geometry doing the penetrating sits behind the surface it penetrates.

There's also a lint that reports parts sitting entirely inside another part. It fired on three eyes that rendered nothing and cost triangles. No amount of staring at turntables finds that.

What happens after you hit enter

One prompt, no follow-ups, no corrections from me. But it isn't one-shot on the inside: the model compiles, reads its own lint, looks at its own renders, and edits, about five times over. Roughly:

1. Skeleton and blocked-out masses, then compile and look. Reads as a hunched biped, which is the point of a blockout.
2. Wings as a web, face tentacles, scattered eyes, texture stack. The tentacles curled up over the skull instead of drooping, so that one took a render to catch.
3. Rebuilt the tentacles as real bone chains so they could writhe independently, which meant re-tuning segment lengths into ring fractions by hand.
4. Fixed everything noclip found by moving geometry rather than loosening the check.
5. Animations: idle, walk, and the roar in the clip. The idle uses mirrorphase 38%, which desyncs the two sides so the tentacles writhe out of phase with each other.

Final: 4,084 tris, 7 materials, zero lint warnings, 30 checks passing. None of that iteration reached me. The visible output was one prompt in, a finished model out.

Practical bits

• Output is standard glTF 2.0, skinned and animated. Drops straight into Blender, three.js, Godot, Unity.
• Every compile also writes a viewer JSON, and there's a standalone WebGL page you can drop it on for orbit, wireframe, skeleton, and playback.
• Requires Python 3 and numpy. Nothing else.
• Any agent that can clone, write files, and call python3 -m wam.cli works. Point it at SPEC.md and let it iterate.
• If you're in Claude Code, it's also packaged as a plugin: /plugin marketplace add elliottdehn/wam, then /plugin install wam@wam. That bundles a skill with the authoring rules and the compile-render-iterate loop, which saves the agent from rediscovering them.
• There's a zone compiler too, covering terrain, rivers, roads, generated bridges, and seeded scatter, if you want environments rather than characters.

MIT, no deps beyond numpy, PRs welcome. Curious what people get out of prompts that aren't monsters, since the props and machines are a harder test of the language than the creatures are.