LLM Assisted Game Development Workflow

A lot of game developers still think AI coding is basically autocomplete with better marketing.

That was a fair read in 2022. It is not where things are now.

The useful way to think about LLMs in game development is not "the AI will make the game for me." That is how you get slop. The useful frame is that a lot of jobs that used to be hard, slow, or outside your skillset are now average-effort if you know how to steer the model.

That changes what a solo developer can attempt.

It does not make you an expert animator. It does not make netcode easy. It does not magically give you taste. But it can help you write shaders, build editor tools, generate models, translate your game, refactor systems, test performance, and prototype mechanics that would have been too annoying to try by hand.

This is a snapshot of what is available right now from my own workflow. I mostly build solo multiplayer web games using tools like Three.js, Godot, Solid, Svelte, Cloudflare, Wavedash, and Rune.ai. My strengths are architecture and level design. AI fills in a lot of gaps around code, assets, tooling, and production work.

This is not a list of things every game developer should do. It is a menu. Take what fits your workflow and ignore the rest.

Idea generation and game design documents

I use AI before any code exists.

Usually I start with a genre or theme. I ask what kinds of mechanics, structures, or game loops fit that space. I am not looking for the model to decide the game for me. I am looking for options I can react to.

When I vet an idea, I usually care about three things:

• Platform fit
• Novelty
• Technical risk

Platform fit matters because not every idea belongs on every platform. A browser multiplayer game has different constraints than a downloaded game, a mobile game, or a big 3D project.

Novelty matters because the idea needs an angle. It does not have to reinvent the medium, but it should have something specific to say.

Technical risk matters because AI makes hard things easier, but it does not erase complexity. Some ideas are possible as isolated demos but become painful when combined with other hard systems.

Once an idea seems worth trying, I ask for a game design document. The useful part is not that it sounds official. The useful part is that it gives the project a target and breaks the work into phases.

A useful AI-generated game design document should include:

• The final goal
• The MVP for each phase
• What needs to be tested after each phase
• Technical risks
• What can be cut if the scope gets too large

The important workflow idea is to avoid letting the LLM run for an hour and then testing a pile of junk. I want the project built one stitch at a time. Build a piece, test the piece, then move to the next piece.

What is available here

LLMs can help with early idea exploration, platform fit, scope planning, technical risk analysis, and phased game design documents. The model does not need to know your game better than you. It just needs to help turn a vague idea into something structured enough to test.

AI game prototyping and technical proofs

For prototypes, I usually want to prove one thing at a time.

Can the camera work? Can the terrain system work? Can the multiplayer state sync work? Can the player interact with this object? Can the editor build the thing I need?

A useful trick is to point the LLM at another project where something already works and tell it:

This definitely works in this project. Do it this way.

That removes a lot of guessing. AI is much better when it has a working reference than when it has to invent an implementation from nothing.

One mechanic I built this way was for a first-person shooter. Instead of reloading your gun, you could throw away your current gun and pull the next gun from a separate gun queue.

If the queue was empty and you double-tapped R, you could disarm somebody nearby. In another case, you could use a ranged weapon interaction to pull a weapon away from a distant enemy.

That meant the player almost always had some way to reload, unless they were truly alone with nothing around them.

I broke the behavior into separate prompts. One prompt for throwing away the gun. One prompt for pulling from the queue. One prompt for the nearby disarm. One prompt for the ranged weapon pull. The LLM handled each case correctly. I probably would not have built that mechanic manually.

There are also ideas that are possible by themselves but difficult together. A sphere world is possible. A tile-based world builder is possible. Terrain digging is possible. Trying to combine all three in one project from scratch would be much harder.

AI does not remove the cost of combining complex systems.

What is available here

LLMs can help build small technical proofs for movement, cameras, terrain, networking, UI, weapons, inventory, and editor behavior. The safest workflow is to prove one system at a time before combining them.

Code and gameplay implementation

Day to day, AI is mostly coding for me.

I hand it math-heavy systems, UI, shaders, multiplayer logic, persistence, build scripts, and editor tools. If something involves math, I am usually happy to let AI take the first pass.

Shaders are almost entirely AI-assisted for me. Multiplayer logic and persistence are also AI tasks, though multiplayer still needs careful review.

For gameplay behavior, I describe things as rules and user stories:

• If this happens, then that should happen.
• Given this state, this result should occur.
• When the player does this, the system should respond this way.

The more concrete the behavior is, the better the implementation usually is.

One thing you learn fast: if you never tell the AI how to structure the project, it will keep dumping code into one file forever.

You either need to modularize from the beginning or let the prototype grow until it hits a practical limit, then do a modularization pass. For me, around 2,000 lines is usually where I start thinking about splitting things up.

I do not treat modularity as a religion at the start. Sometimes the right move is to get the feature working, then do a pass for structure.

I also often prefer isolated branches of code over forcing everything to be reusable immediately. That sounds wrong from a traditional engineering perspective, but with LLMs it can be practical.

If a reusable helper already exists and the model misses it, it may create a second helper anyway. Now you have accidental duplication that can affect logic in confusing ways. Early duplication can be safer if it keeps behavior isolated. Reuse can come later when the behavior is stable.

The failure modes are real:

• Camera math is often wrong.
• Forward direction and orientation are often wrong.
• Positioning objects relative to each other is hard.
• The model may stub features instead of implementing them.
• It may cover the happy path but miss important cases.
• It can code itself into a corner.

ECS can be a good AI-friendly pattern, but you have to keep steering the model back to it. If you do not remind it to use the architecture, it may drift away.

What is available here

AI can write gameplay systems, UI, shaders, save systems, multiplayer logic, editor tools, build scripts, migrations, and refactors. The important skill is not prompting magic. It is specifying behavior clearly and controlling the structure of the project.

Art, assets, animation, and audio

I use AI across almost every asset category:

• Concept art
• Textures
• Sprites
• Icons
• UI layouts
• 3D models
• Audio
• Music
• Shaders

For me, AI assets are not only placeholders. I am a solo developer with no dedicated content budget and no traditional asset production skills, so some AI assets end up in the final game. I am fine with that.

The workflow usually starts rough. During polish passes, I replace placeholders with better generated models or assets. Then I ask AI to hook those models into the game, build animation state machines, connect the animations, and make the result responsive to input.

For 3D models, I use tools like Meshy and Hunyuan. They can export GLB or FBX, depending on what I need.

For rigging, there are tools like Mixamo and Mesh-to-Motion-style services. Mixamo is useful but has size and complexity limits. Other tools can handle GLB files, more complex models, humans, and sometimes alternate skeleton types like animals.

A typical 3D asset workflow looks like this:

• Generate the model.
• Export GLB or FBX.
• Rig it through an external tool.
• Bring it into a Three.js project.
• Use AI-written Python or JavaScript scripts to reduce texture size.
• Optionally reduce mesh complexity.
• Compress or convert the asset for faster loading.
• Prepare it in Three.js.
• Export to Godot once it is finalized.

File size matters a lot for web games. AI-written scripts can reduce texture sizes, compress images, and simplify meshes. That is a major practical win.

Animation is still not solved. There is no great AI animation system in my workflow yet. I mostly use Mixamo-style animations or whatever animations come with the rig I chose.

Skeleton rigging is also still out of reach for me as a complete custom solution. It is extremely math-heavy. I have tried building my own rigging workflow, and I am maybe 60% of the way there. It may take smarter models, larger context windows, deeper reasoning, or better training data before that becomes easy.

AI-generated 3D assets fail in predictable ways:

• Bad topology
• Poor retopology
• Messy quads
• Asymmetry
• Soft, bloated forms
• Weak textures
• Incorrect details
• Holes when manipulating meshes
• Difficult customization
• Hard-to-edit clothing or accessories

The assets can be useful, but I do not have a fully production-ready asset pipeline. It works, but it is still manual and fragile.

What is available here

AI can generate concept art, sprites, icons, textures, music, audio, shaders, UI references, and 3D models. Other tools can rig, compress, convert, and optimize assets. The weak spots are animation, topology, consistency, customization, and production-ready pipelines.

Level design and world building

Level design is one of my stronger areas, and plain LLMs are still not naturally good at it.

The issue is spatial reasoning. An LLM can describe a level, but it does not really understand space the way a level designer does. It can put things in the wrong place, face objects the wrong direction, invert cameras, or fail to line up objects that are supposed to fit together.

The better workflow is not asking the LLM to imagine the whole level in text. The better workflow is connecting the AI to tools.

I have had success connecting Codex CLI into a level editor so I can prompt through the editor and build things in the world in real time. That changes the AI from a text advisor into an interactive world-building assistant.

This matters because a level editor contains context that text does not. If the AI can operate through the editor, it can help create and modify the world closer to where the actual work happens.

That said, humans still need to inspect the result.

If I need a store with a counter, an NPC behind the counter, shelves lined up properly, and items placed on the shelves, that still requires human judgment. The AI can help create the pieces, but spatial composition still needs review.

What is available here

AI can help with level concepts, layout ideas, editor tooling, procedural placement, and real-time world building through custom tools. Spatial alignment, composition, and environmental storytelling still need human taste and inspection.

Balance, progression, and game juice

I use AI to help design balanced games.

That includes fair enemies, fair level design, progression curves, and ideas for extra production value. I think of some of this as game juice: the small touches that make a game feel more alive than the basic mechanic.

I do not usually ask AI for vague judgment. I do not ask, "Is this mechanic good?" and trust the answer. I use it more concretely.

I ask it to simulate whether something seems balanced, reason through values, propose enemy behaviors, or suggest progression pacing.

To keep design from becoming bland, examples matter. One useful workflow is to generate gameplay screenshots with an AI image generator, then give those screenshots back to the coding or design AI as references.

This worked well for HUD design. Image generators can create good-looking gameplay screenshots with polished UI. Those images give the implementation model a target. Without a target, it may produce generic UI. With a target, it can work toward a specific composition.

This is true broadly: AI is better when you give it references. Concept art, screenshots, UI examples, theme boards, and existing games can all steer it away from the average.

What is available here

AI can help with enemy design, progression, balance, UI concepts, HUD references, and game juice. The key is to use examples and references. Do not ask for generic "good design" and expect taste to appear automatically.

Debugging, testing, and performance

For debugging 3D games, the biggest improvement is giving the LLM eyes.

A tool like vitexec can let the model inspect a running 3D game, take screenshots, send those screenshots to the LLM, and check performance. That removes a lot of friction because visual bugs are hard to explain in text.

When something is broken, the best bugs for AI are the ones you can describe clearly:

If this happens, then that should happen.

If the expected behavior is clear, the model can usually trace why it is not happening. AI is also useful for data bugs, corrupted data, migrations, and refactors.

Performance optimization is another useful area, but you need to give the model real signals. I usually point to things like:

• CPU getting hot
• Chrome tab RAM usage
• FPS
• Draw calls
• Network tick payload size

Draw calls are especially important for 3D web games. For multiplayer, I watch the payload size of the tick broadcast state object.

Memory leaks are harder. AI can help optimize after you identify a problem, but it is not great at detecting long-term leaks by itself. Humans are still better at noticing performance degradation over time and connecting it to what changed.

Manual playtesting is still required for runtime behavior, especially triggers. If a trigger is supposed to fire an event and it does not, you often have to test that inside the engine or runtime. There may not be a clean headless way to catch it.

What is available here

AI can help debug behavior, inspect screenshots, analyze performance signals, fix data problems, refactor systems, and optimize assets. Human testing is still required for feel, triggers, memory leaks, visual alignment, and runtime regressions.

Multiplayer and infrastructure

Multiplayer is hard.

If a package or platform covers the hard parts, use it. If it does not, AI can still help, but netcode becomes one of the areas where you need to be more careful. State sync, prediction, reconciliation, payload size, and runtime edge cases can get complicated quickly.

For my games, Cloudflare is a strong default because it is cheap or free for a lot of use cases, and it works well with tools like PartyKit.

Wavedash and Rune.ai are also interesting platforms for multiplayer or web-based games. You can host classically on GCP or similar infrastructure, but containers can get expensive for games.

The important infrastructure question is not "what is the most powerful platform?" It is "what platform fits the game and keeps the operational cost low enough that I can actually ship?"

For AI games and AI-assisted workflows, compute cost also matters. Tokens are tied to real compute cost. If you can get generous usage limits or free compute, use it. Daily free generations, free model credits, and subscription usage limits can meaningfully change what is practical for a solo developer.

What is available here

AI can help implement multiplayer systems, inspect state payloads, write server logic, and optimize network messages. Multiplayer is still one of the highest-risk areas, so use packages and platforms when possible.

Workflow management and multiple agents

My workflow alternates between two states: build and refine.

In the build state, I design or build out a new feature. Then I switch into refinement, where I improve what exists and make it work better. Once there is nothing obvious left to refine, the feature is probably ready to commit.

For big tasks, I ask the AI to create a plan first, often as a markdown checklist with phases. Each phase should end with a test cycle. That gives the agent a way to track where it is and prevents the project from becoming a pile of untested changes.

I manually play the game at state transitions. I test after a build phase before moving into refinement. Then I test again after refinement to check for regressions. Then I move back into building.

I also use multiple agents in parallel, but only when their work can be separated cleanly. Safe splits are things like:

• Frontend vs backend
• UI vs game logic
• Assets vs gameplay code
• Planning the next feature while another agent finishes the current one

Core game logic is usually not safe to parallelize because it touches too much. If an agent is working on core game logic, I usually do not want another agent editing nearby files at the same time.

There is no magic way to prevent multi-agent workflows from becoming chaotic. Managing agents is a new skill. Each developer has an "agent max," the number of agents they can manage before quality drops.

I might be able to run six agents at once, but my output might be better with three because there is less coordination overhead.

Downtime is the enemy when vibe coding. You should usually be in one of these states:

• Planning
• Designing
• Prompting
• Reviewing
• Testing

If one agent is busy, another can prepare the next plan. If a feature is being implemented, you can review assets. If a build is ready, you can test. The workflow is strongest when you keep momentum without letting chaos take over.

What is available here

AI can work as one assistant or many agents. Multi-agent workflows can increase output, but only if file ownership and task boundaries are clear. Managing agents is a real skill, and more agents is not automatically better.

Tools and platforms

The IDE can be anything. I use JetBrains because I like it, not because it is required.

For AI tools, I mostly think in terms of use case, usage limits, and dollar value. Different tools are useful for different jobs. Subscriptions are often better than direct API usage for personal or hobby development because you get much more practical output for the money. Doing the same amount of work through direct API calls can become expensive fast.

Useful coding and CLI tools include:

• Codex CLI
• Claude Code
• Gemini CLI
• OpenCode
• Cursor
• IDE chat agents

For someone new to AI, I would not start with a complex multi-agent CLI workflow. I would start a new project, use an IDE chat-window agent, and use one agent at a time.

The project should be something the developer actually cares about, because they need enough willpower to finish it.

For image and video generation, tools keep changing, but the categories matter:

• Image generators for concept art, screenshots, icons, UI, and textures
• Video generators for motion references or sprite sheet workflows
• API services for generating assets inside apps
• Model generators for GLB/FBX 3D assets

For infrastructure, I like Cloudflare because it is cheap and practical. PartyKit is useful for multiplayer. Wavedash and Rune.ai are also worth watching. GCP and container-based hosting can work, but cost can become a problem.

Godot is especially AI-friendly because so much of it is plain text. Scenes and project files can be created or modified directly by CLI tools. The LLM does not always need to interact with the editor.

Moonlake AI is interesting because it wraps Godot with an agent that understands Godot workflows, templates, and examples.

For Three.js, I recommend building your own tools. If you build tools inside your game, they can evolve as your game evolves. That is often easier than learning a separate editor or forcing your game into a workflow that does not fit.

Asset optimization matters across everything:

• Compress images.
• Compress audio, often to OGG or another efficient format.
• Reduce GLB texture sizes.
• Reduce mesh complexity when possible.
• Minify JavaScript.
• Keep load times low.

The faster your game loads, the more likely people are to stay and play it.

What is available here

There are AI coding tools, CLI agents, IDE agents, image generators, video generators, 3D model generators, rigging tools, asset optimization scripts, multiplayer platforms, and hosting platforms. The right choice depends on the game, budget, platform, and workflow.

Risks, taste, and AI slop

AI can make a game worse when it increases output faster than judgment.

It can generate more mechanics, more UI, more assets, more systems, and more content than the game actually needs. If the developer does not curate aggressively, the game becomes bigger but not better.

The biggest risks are:

• Feature bloat
• Generic feel
• Bad cohesion
• Fake completeness
• Overcomplicated code
• Loss of taste
• Bad game feel

AI slop in games usually comes from trying to one-shot the game. LLMs are lazy by default. They will complete a task in the most minimal plausible way unless instructed otherwise.

That is why AI-generated websites often look the same, and AI-generated games will have the same problem if developers accept the default output.

People with no development experience or weak taste in games may have the hardest time understanding why their games do not gain traction. The missing piece is not output. It is judgment.

Taste still matters. Authorship still matters. The way I keep authorship intact is the same way regular game developers do: concept art, consistent themes, world-building, references, and curation. I am not just asking AI to make a game. I am building a world and using AI to produce parts of it.

Be skeptical of hype, CEO claims, and one-shot stories. AI is not magic. It is a computer program. Garbage in, garbage out.

Anything that sounds too good to be true is probably a niche demo or just too good to be true.

What is available here

AI can multiply output, but it cannot replace taste. The strongest workflows use AI for production and iteration while keeping human judgment in charge of scope, feel, cohesion, and final decisions.

Closing

The practical value of AI-assisted game development is that more things are reachable now.

A solo developer can build systems that used to require more specialized knowledge. A programmer can generate usable art. A designer can prototype mechanics. A web developer can build 3D tools. A small team can localize, refactor, optimize, and test faster than before.

But it is still game development.

You still need taste. You still need playtesting. You still need to understand your platform. You still need to manage scope. You still need to know when something feels wrong.

AI does not remove the work. It changes where the work is.

The new skill is knowing what to delegate, how to specify it, how to test it, and when to take control back.