> [I give a small introduction to myself and my own work, that I’m omitting here, as you’re on my website]
kkukshtel: You should keep that info, with links, even if its links to your site. Dont burden the reader.
Edit: I read the first half of the article then skimmed the rest (I dont use LLMs outside of occasional searches).
I've been a gamedev for five years. I have a hunch LLMs will not take over game development because of the necessity to control many, many small details to shape a great experience for the player, and because some parts of development cannot be described with words.
Small details: My hunch is when it comes time to polish and fine tune all the moving parts, this process will remain much faster to do by hand. It will be faster to update a specific field or line of code and test/iterate than to prompt your way through that process (the last 20% of the work takes 80% of the time)
Describing without words: An artist with a vision can only bring that vision to life with body movements. It is not possible to communicate all the details that go into a great piece of art with words. The colors, lines, shapes, positioning, specific emotions, history... is beyond spoken language.
You are talking from a perspective of games as a medium for an artist with a certain bias and an audience that is interested in this specific bias.
You say "vision, colors, positioning, etc", yet you have Candy Crush being the most played game on mobile for 13 years which simply employs direct signals and ques from cognition and cognitive neuroscience to achieve this.
The games that you describe are a small subset of what the general public is playing or is interested in.
This can further be pushed into a monoculture by shaping the players expectations about what a game should be. Maybe Skyrim has too much walking and dead-time, it's better to optimize for fast combat and action, like in Fortnite, and mold the playerbase in a way which makes them susceptible to simpler games more tuned to neurophysiology.
Even Candy Crush, a huge part of what made it successful, was the tiny details. The bright colors, the art, the subtle and not-so-subtle animations... An LLM can technically do all that, if you keep reminding it, and have strong rules, and constantly keep it in check, but there's no way it would do it on its own and keep it consistent and coherent.
Eg, if the tall green pill candy and the red round one both scale by exactly 3px when you drag them, it might still "look" wrong, and get into uncanney valley territory. And that's even assuming the LLM picked the same value to scale when you prompted it to "add a red candy", or it picked a different one arbitrarily.
I've tried making games a few times, or even CSS animations, and I can tell that they don't "feel" right, even if I have no idea why, or what to change. I have mad respect for artists and animators that can manage that, and I have no idea how you tell an LLM "It doesn't feel right when I drag the candies", and have it be able to figure out that a tall vertical candy needs to scale differently on the X and Y axis than a round one.
The OP is absolutely not talking about making Candy Crush. They ARE talking about making art. Both can exist in the same world and be successful. The existence of and success of reality TV doesn’t negate the art of filmmaking and the enjoyment of watching a movie. Same with games.
OP is invalidating the blog with the reasoning of detail, art, taste, etc is necessary for a good game.
I am saying that a small subset of people care about this given what people choose to play in practice. It's currently much, much easier to not care about these things and focus on the cognitive aspects to capture player attention, and the human cognitive incentives are not stacked in favor of OPs view.
> I am saying that a small subset of people care about this given what people choose to play in practice.
1. Candy Crush is one of the highest grossing games of all time, but if you look at the other top 20 highest grossing games, the vast majority are nothing like it.
2. Janky crush wouldn’t have been the success it was without massive attention to detail and polish.
Also there is a huge effort to optimise the game for retention, LTV and UA arbitrage.
These are not the fun details but they are details none the less and whilst LLMs will probably be more useful here the insights that drive their actions are the taste humans provide.
Candy crush is not the first of its genre, yet it is the most successful. What made it stand out from its bejeweled predecessors? Vision. Colors. Positioning. Animations. Smooth movement. Feedback. Tighter gameplay loops. Sense of accomplishment. All of the above
What are choices of vision, colors, positioning, feedback animation, sounds, etc, if not the exact things you call "employing direct signals and ques from cognition and cognitive neuroscience"? The former is the execution of the theory of the latter.
>which simply employs direct signals and ques from cognition and cognitive neuroscience to achieve this.
Does anyone actually do this or is this all post hoc rationalizations on why certain things work? My experience and understanding is that it's all just a bunch of "let's try lots of things and then do more of what did well". Ie it's the result of a crazy amount of iteration rather than "employing cognitive neuroscience".
Candy crush has a team of hundreds of people, it's far from a simple game. I know for a fact they had individual product managers for certain features inside the game.
> My hunch is when it comes time to polish and fine tune all the moving parts, this process will remain much faster to do by hand. It will be faster to update a specific field or line of code and test/iterate than to prompt your way through that process (the last 20% of the work takes 80% of the time)
I think you're mostly right here -- however, I think you've framed prompting as an all-or-nothing (or maybe the OP did, as I only skimmed the article too...). LLMs are great for some things (scaffolding, review, refactoring, etc) but way less efficient at others (tweaking and letting the artist eye shine).
I think the crux is this: you shouldn't be asking an LLM to make these tweaks for you; you should be asking an LLM to build the tools that let you make these tweaks by hand faster or more effectively.
For example, we have probably a hundred tools [0] for quickly making all kinds of changes and tweaks in one of our Steam games, that are of course all done by hand. The tools were built by LLMs based on what would speed up our existing by-hand workflows, and once they're built they're just tools that let our people shine.
1. Do a thing by hand
2. Have LLMs build a tool that makes it easier to do that thing by hand
3. ????
4. An artist with a vision can bring that vision to life faster
I've found it to be useful for prototyping. You can throw a game mechanic up, have it build some AI players, tell you any balance issues it runs into, play against the AI yourself to see if the mechanic feels fun. Then iterate.
A few times I've made a tweak to a mechanic and the LLM balance tests immediately found a major issue. Sometimes the AI players it creates just suck at the game. You still have to think, but just having balance tests and then having them cheap to update when I experiment, it extremely valuable. I tested this on a game I had mocked up with cardboard and forced my friends to play. It found all sorts of stuff I missed in those gameplay tests. It didn't replace those sorts of tests with humans, but it let find issues faster so I got more out of human interaction tests.
When I'm using an LLM to program these days, I increasingly feel like I'm directing one of those renaissance-era painting schools that were sort of like painting-factories, where some Great Master would direct the output of a dozen or more painting-technicians to construct unreasonably-large and detailed paintings on unreasonably-brief time-scales.
They would still come in at the end of the day to add their brush strokes to pieces of the canvas that they thought needed extra attention. We still refer to those paintings as if they were made by the Great Master, and justly so because their artistic imprint is felt in the final work.
In the same way where if you and I were asked to write the same game with an LLM, they would come out looking pretty distinct from each other. And if we wrote them by hand, they would be distinct from each other and the LLM-assisted ones again. All of them are still art and games, though, it'd be silly to call them anything else.
I agree with you that polish and fine-tuning is faster to do by hand when you are well-appraised of the foundations. I think a lot of the challenge of developing Real Software with LLMs today is maintaining the appropriate proximity to the work, when we are no longer holding the paint brush ourselves, so to speak.
I'd encourage you to actually run this exercise! I think you'd be surprised.
I've proctored some interviews where we give people an LLM, and a fairly open problem (similar to "Build a game where you do X").
The first couple of iterations are a similar, but it diverges pretty quickly depending on where the human is focusing their attention. The logical bugs of different subsystems are a bit predictable, but the final results pretty reliably contain the "fist" [1] of the human.
Of course they're similar in the ways that all software are similar. But every human is knowledgeable and/or cares about specific things more than others, and that absolutely shows up in each iteration final product.
"My hunch is when it comes time to polish and fine tune all the moving parts, this process will remain much faster to do by hand"
Depends if what you want to do is new, or has been done a thousand times before
"Describing without words: An artist with a vision can only bring that vision to life with body movements. It is not possible to communicate all the details that go into a great piece of art with words. The colors, lines, shapes, positioning, specific emotions, history... is beyond spoken language."
And you absolutely can use sketches, pictures, drawings as input to the AI.
So in general I agree, at least right now it needs a lot of fine tuning. About the future I make no prophecy, I did not see AI coming this way, so why would I be right about AI in the future now.
I am making a novel game right now with heavy help from Fable and it is awesome. Because even though my game is novel - parts of it are not, but standard and I reinvented the wheel way too often before and am glad don't have to do that anymore.
LLMs will absolutely take over game development. That does not mean the result will be a fun game that has value. Just like a group of expert humans can put together a technically and artistically impressive game but it has little appeal.
Taste remains king. Despite that. LLMs will absolutely be able to create elaborate games by this time next year.
> I dont use LLMs outside of occasional searches
> I have a hunch LLMs will not take over game development
Not easy to make statements about things you don't use.
If you're developing software, LLMs will be ubiquitous eventually.
They aren't going to tune the turn radius or how long to hold a freeze frame but they will bang out a UI to let you do that quickly with quick turn around times.
So many simple little things that are helpful but not really worth doing will now be worth doing because the implementation cost is a fraction of what it once was.
I honestly didn't except this to get traction on HN so I'm updating the blog post now. I just read some recent post too that was like "mistakes technical blogs make" that I think brought up this same point yet here I am! Thanks for the tip.
> I stand by a lot of what I’ve said, but am in the process of shipping a project where I’ve also used none of this. I think the scale I’m targeting here is really larger projects.
The author appears to be on track to learn an important lesson about LLMs and art. LLMs have completely solved the coding side of game development. But this was never the hard part. Not even close.
The fixed randomness and determinism thing sounds great on paper (all of this does), but in reality this is an extremely confining way to build a video game. Ensuring you maintain determinism across many platforms is where things get super nasty.
If you want a turnkey AI game development experience, why not double down on diffusion? This sidesteps virtually all of the tooling and integration concerns. There is no game engine to integrate with if you use a diffusion model.
> LLMs have completely solved the coding side of game development.
This is not quite true. Currently you still need to give them guidance on what type of architecture would best work for your game, or after many iterations on gameplay you'll end up with terrible performance and a complete mess of a codebase. I expect that will be solved sooner rather than later, though.
Indeed, not even wrong. And it will whiff on the most basic gameplay issues. But it is still genuinely impressive how fast it can build a pretty but unplayable unfun thing out of nothing. And that's after many rounds of planning with it as it proceeds to ignore all that planning just because it can.
PS no, I am not interested in your alternative harness that will supposedly 100% trust me bro fix all these issues
I just built a fun somewhat clone of an old game I used to play as a kid within a day purely with LLM, i didnt even look at one line of code, nor do I have any experience in game dev.
Also was a single planning session and it executed the plan well.
Fwiw I tried the same thing ~a year ago and the result was horrible; like so much worse.
Sure it’s not AAA, the art looks like shit and most people would probably not enjoy it - but it was fun for me to play and I’ll work on it a bit more to see if I can bring it into a state where others can enjoy it too.
I've made some very playable and semi-fun games with AI. But in the end, beyond the acceleration in the tooling and unit tests, it didn't save me all that much time because the mindset of the AI is so strange. The most frustrating part is the sycophancy about executing precise requests and the AI more or less says "sure thing boss!" and then does something really stupid over and over again. I have abandoned several projects over this waiting for better frontier models.
Google's recent game framework is even worse, but it does make nice assets out of the box. Not much better though than the right prompts to Nanabanana from Claude through an MCP, it's nice to get the assets out of the box the first time.
I put one of them up as a free game on itch.io as an experiment. It was immediately ratings bombed by the AI haters.
The funniest part is when the haters accuse you of not knowing how to code and I have many decades of experience doing very low level coding. I just want to play with the new tools. Then when they find that out, you now have an unfair advantage because it's impossible apparently to learn how to code now. So the only winning move is not to play, no more games on itch.io.
The United States is really strange about AI. I'm no fan of the 10 billionaires steering the ship, but steering the ship into an iceberg doesn't seem like a great move to me.
Yea I guess if you already know what you’re doing the LLM won’t help too much.
I see this a lot in my professional work where I have a much better idea of what makes sense and what doesn't.
Thanks for the assets tip though, I’ll try that out - I tried to get Claude to use blender to create some assets and they look just awful.
Ultimately if I actually want to release my game to the public I will pay one of my artist friends to create proper art and assets for it.
If we're talking about game development from the 10 last years, it's not hard. It's long, tiring, sometimes boring. But most of the coding is already solved, done and reinvented maybe 50 times already. It's not hard as in "I need to think deep into solving this issue none ever solved".
I’ve been a professional engineer in games for 24 years and can safely say this idea that things aren’t hard anymore is silly. Programming games has definitely got less unpleasant as tooling is much better but the actual mental problems are tough as ever.
You might be mistaking the sheer variety of games and that some are really quite simple for all games being easier to make.
if you're thinking purely about game loops and game mechanics, yes a lot has been done before and used over and over again. but that's by no means all the programming going on.
just look at how much people complained about poorly optimized games in the past decade. the most impressive game dev feats in terms of programming were not the game mechanics, it was getting their game to run as well as it did on (very) limited hardware resources, a problem we are hitting again now. and it is very obvious looking at modern games that this problem is nowhere near solved, and in fact very hard.
Sorry, but no. This is not true. It definitely was hard. So hard that few people actually made games. I remember using GAS (Unreal Engine) and being baffled by the complexity of the framework. And then when I didn't use GAS, I was baffled by the complexity of what it handled. It's hard.
What are you talking about? Maybe for throwaway mobile games. Serious game dev is full of novel challenges. New graphics techniques are constantly being researched and discovered. There are critical resource constraints unique to every game, and each one needs bespoke solutions. There aren't one size fits all solutions to most high fidelity games.
I'm not sure time or money inherently equal difficulty. There's plenty of things that take a long time to build and/or are expensive to build, but are still easy to build.
> The fixed randomness and determinism thing sounds great on paper (all of this does), but in reality this is an extremely confining way to build a video game. Ensuring you maintain determinism across many platforms is where things get super nasty.
Why 'nasty'? I agree it's a problem to solve, but you just use a fixed-point math library and it's fine. Determinism is freeing, not confining. It allows you to do things like rollback netcode, replays and easy debugging. You can't just say that 'reality' happens to be what you in particular are used to.
> Why 'nasty'? I agree it's a problem to solve, but you just use a fixed-point math library and it's fine.
Assuming the agent didn't put in a native nondeterministic trig function deep in the code instead of using the library one, it's an easy mistake to make and hard to debug in a big game. It won't even show unless you have a robust CI matrix. It can indeed be "nasty" to maintain.
Also determinism might work for simulation state, but shader/gfx differences across platforms can be really nasty and a library can't save you. Not even something like WebGPU. Also if you're doing any sort residency streaming dependent on GPU timings trying to make that deterministic will be a nightmare.
Unless the GPU output is feeding back into the game loop simulation, there’s no nightmare.
I’ve worked on games with intentional determinism, and it’s a very valuable tool. A playtester can hand a dev a recording of the game inputs (including clock) for whatever bug they encountered, and the dev can fast forward to the exact point and repro it 100%. The amount of time saved chasing down difficult bugs is enormous.
Take a given start point; feed a set of inputs; compute a checksum on the resulting state. Check that the checksum matches on different platforms.
And if your language is good you can parameterize your logic on a particular numeric type, so that a particular fixed point implementation is consistently used
I partially agree. Coding is not the hardest part for a large portion of indie games. You can in theory build an AI-coded game that sells well if you have the right art and gameplay.
But many top games have complex engines and online services that require technical mastery beyond the current AI capabilities. For those genres, engineering is a huge barrier of entry.
For a not so extreme example, you won't vibe code Cyberpunk 2077 while just taking care of art and gameplay ideas. Gosh, humans could barely pull that one off!
> Ensuring you maintain determinism across many platforms is where things get super nasty.
I learned that one the other day - I've been building a little RTS game with a replay mechanism, and replays in Safari broke where they worked in Chrome. Opus 5.5 fixed it by replacing calls to things like Math.sin() and Math.cos() with its own deterministic functions: https://gist.github.com/simonw/7df96ed7296c69b70a9990102cae0...
It's definitely not my intention to try and describe ways for making game development be more turnkey. I'm more trying to directly address ways to make non-one-shot (read: actual) game development be more tenable when an agent is involved.
> Any time I tried to use an LLM for a game-y thing, it would fall over.
You know it's funny. I did a bit of LLM-assisted game dev this year.
I spent a few weeks working on a simple Pong game, just polishing it, making small changes here and there. Frontier models couldn't change or add a feature without breaking something else. It was still more productive than working "solo" but quite annoying.
Meanwhile, I asked a model to make an entire game -- about 100x more complicated -- and it just one-shotted it perfectly, no issues.
I'm not sure how both of those things can be true at the same time. Something something "in-distribution" ?
Yes, that's about right. It is much easier for it to roughly copy other code that it has seen, than to understand the code it has been given enough to make targeted fixes.
When you start from the end, model may make the proper architecture for everything you will need, and for everything it needs to know that implementations is correct.
The hard stuff that comes after "implementing the basics" and released game. The stuff that is hard to even verbalize and takes lots and lots of iteration. Good luck using AI for all that.
I one shotted a math game for my 4 year old complete with lots of juice “screen shake, explosion animations etc…”.
It worked great, but if I tried to change even the slightest thing the result was worse than the initial output. No matter how hard I tried to nail things down with tests and specs, each change looked or felt worse.
It's kind of funny how it took inventing AI for people to start caring about good software engineering practices (debuggability, iteration speed, reliability, etc.)
I kinda get it. To massively simplify: Without AI, your choice is 8 days implementing, or 5 days planning/designing/refactoring and 5 days implementing. With AI, your choice is 5 days wrestling with the AI to implement, or 4 days planning/designing/refactoring and 1 day with the AI to implement. I made up those numbers but the general idea is that good practices have a lot more leverage with AI, since the make the implementation "free".
It's strange, but as soon as I saw the first slide, I was "why are these properties hard-coded?" and then as we went through, it felt like a tour through "decouple your entities 101". Are games really hard-coded spaghetti like this?
I've never written a game (well, not since my Acorn Atom days writing Missile Command in Assembler) but I'm kinda inspired now.
The author of the article himself may answered your question:
"I’m decidedly less well versed and am inclined to think that whatever code the LLM produces is “good”. Maybe it’s actually garbage. But there is reason to believe the Svelte and web-stack stuff is quality, in part due to the fact that there are LOTS of high quality web projects with their source available online."
This matches what I came up with on a small project. The biggest ones being screenshots and separated simulation.
Meta level, just push your agent to make things more legible, it’ll figure it out.
One other observation, remember that your agent is infinitely patient. So prompts like “build an interactive design doc with videos of each game mechanic in the style of Factorio dev diaries” can make reviewing changes easier. The general idea, all the small QoL dev tools that you don’t have time for, you can just spawn a side agent to build; if they are orthogonal to your main thread you can just progress them in the background.
One thing I think game dev has not (AFAIK) invested as much in is observability. There’s a lot of perf instrumentation available in debug builds, but things like measuring DPS, health, etc as an exported metric time series I have not seen before. I think agents will benefit from this disproportionately more than humans, eg for inspecting progression curves and balance.
In my case, the most valuable prompt I made was, "please figure out how to run the game headlessly, so I can use my PC while you muck around". It did, and that gave it ability to run multiple instances in parallel, which it now uses autonomously whenever it needs to confirm assumptions or validate changes.
AI can definitely do all aspects of game development now, but this advice seems to mostly apply to small indie titles or experiments.
For example, the Thing approach is reasonable for a small game, but it's a dead end for a performance budget or layered subsystems. In a reasonably sized 3D game, iterating and copying 30 subsystems of 1000's of Things is impossible to do in frame time, the only fix is a total rewrite of literally everyThing. That's why there's ECS, SOA, etc. which needs a different kind of harness.
Also, art completely dominates the production cycle of modern games, which (even if AI generated) needs its own category of harness not mentioned here. And AI can be very good at optimizing, but samply won't diagnose your overdraw, and GPU needs its own ablation and attribution.
For the time being there's no panacea and we still need "game developers", though the bar for prototypes (and certain genres) is lowered.
Kyle seems smart and I enjoy some ideas on his podcast and blog. But I do think his many strong opinions about how games should be developed are reflective of a lack of experience shipping stuff with an actual playerbase
It's conceptually interesting but I don't know it is instructive beyond simple projects
"Thing" style systems are very common in AAA. I link to the interview with the Dreams (Media Molecule) team where they describe a system very much like this. ECS is also not mutually exclusive here.
Dreams did use a standard ECS [1] and despite being a first-party title it's not widely considered to be a AAA game (based on size of the team and budget compared to typical AAA games). There might be some AAA studio that eschews the approach, but it's very common for speed and efficiency, especially on consoles.
That said, I'm glad you shared your thoughts and experience. It's helpful to see what people try.
I wrote an automated testing system for my game engine to take screenshots and simulate input for automated testing and then I realized how good claude was at using it to make games that I wrote a guide about it in my engine documentation:
I started coding because of gamedev, seeing this and potentially having some agents take care of the coding part is a blessing. I doubt this works as advertised but imagine iterating on stuff with a couple prompts and you can alt tab back into blender or libresprite. Very cool, lets put economics and employment aside
Good planning is needed. All planning should be done without resorting to artificial intelligence, or the game should be fully explained to the AI and the plan should be handled by it, and that plan should be adhered to. Whichever you prefer...
A lot of the points the author made about game dev with AI are things that I notice in my experience as well.
That is why me and a friend started to work on https://folly.gg an AI game maker that internalizes several of these learnings.
Case study: a 1997 PC game I played as a kid, getting it to run on modern hardware, and in progress of making it look like it looked in my head.
Claude Code got the first part done in 30 minutes, and in process set up some basic RE environment. Then, iterating over various aspects, it gradually decompiled most of it, then - on my request, being annoyed with "computer use" plays taking over my PC - extended the shimmed DirectX DLL to run it headlessly (using "Private Desktop" feature of modern Windows, too, which I didn't even know existed), and this gave it the ability to run several game instances in parallel. As for playing, it quickly mapped relevant memory addresses and game logic scripts, and uses a combination of hand-written scenario files, patches to level data and memhacks, to do whatever it needs to be done.
All throughout, with some nudging from me, it produced a stupid amount of helper tools to give me insight into how the game is built, allowing me to verify its work and direct it better.
So I can't say I agree with the general gist, given that Claude is now writing me full level guides, complete with decent screenshots of important moments, all zero-shot.
TL;DR: just let LLMs instrument your game and figure it out on its own.
This is very cool and on a lower level (more in the trenches) compared to what I did earlier in the year (i did a small writeup and built some skills [1]).
Because I am so-and-so pixel artist, the biggest unlock for me has been in rapidly iterating with graphics assets and sprites, and it's actually helped me become a better artist and animator (I built my own little tool for this [2]). The rest Codex or Claude Code seem to handle incredibly well (plus I have 30 years of programming behind me).
I was able to get a decent FPS out of around 40k lines (excluding tooling). Tooling consisted mostly of level editing and asset conversion which I tried to keep out of the main code-base.
> Any time I tried to use an LLM for a game-y thing, it would fall over. Maybe this is my own bias. I’ve been a game programmer for nearly 15 years, I think I know how things work. I can sniff out “bad” game code a mile away. But when it comes to Svelte web-apps, I’m decidedly less well versed and am inclined to think that whatever code the LLM produces is “good”.
It feels like the discovery of a specific form of gell-mann amnesia. I know when working with an agent through areas where I have domain expertise I catch bad assumptions, decisions, etc. But then, unfortunately, have to trust it much more where I have minimal expertise.
i usually tell claude to autism optimize on low frame rate areas. i made eden emulator from crashing, to like 2 fps, to 30-20 fps on botw on a pixel 10
the harness is basically adb + some profiling changes and the ability for the model to dump frames
I was a game developer for many years, at large scale (MMO) and at small scale (indie).
With the advent of AI, I've been _trying_ to use AI to accelerate game development and have come to a few conclusions.
1. AI models want to make everything deterministic. This sounds like a truly sound way to write a verifiable program. Games are not verifiable simulators except in the niche of ...simulators. Even in those cases, the vast infrastructure devoted to this leads to a lot of churn, bugs (AI forcing things to align with the verifier), and rigidity.
2. Making a game != Fun. This one is obvious but needs to be stated. Anyone on earth right now can say "make me doom" or "make me a super mario clone" and Opus/Astra will dutifully comply and make something generic and bland. Once the novelty of "oh wow it actually built it" wears off, you're left with a mediocre clone, lacking depth, that no customer would want hoisted upon them.
3. Content and novelty are the hard parts. AI models always create the mediocre middle. There's real work (and interesting work) involved in both inventing novel gameplay systems which LLMs will never stumble upon despite infinite 'brainstorming prompts'. But, AI is 'OK' at taking your novel idea and proposing directions -- that you can then strike down viciously until something interesting emerges.
On the content side, this has always been a truism for an independent developer. AI art tools aren't quite there yet. There's image-to-3D and there's Mixamo for animation but we're not there yet. Nearly though! But again, will every game look like a bland generic AI generated image with bland AI generated models?
4. AI models are crap at building re-usable large-scale architectures. Even building with Opus 5.5 and Astra they will happy design themselves into a corner. Yes, they can _also_ design themselves out of that corner at speed - with a lot of pain and code churn and mess. I've found it vastly better to iterate slowly, using your experience (if you have it) to structure the core architecture and systems the way you want (AI writing the code) -- and then build upon that solid base -- taking special care to reject updates that butcher your architecture. I think this applies to most coding projects actually.
5. Game dev currently surfaces very clear differences in model capabilities with Opus 5.5 leading the pack (in this domain) and Fable 5.1 and Astra/GPT-6.1 Sol following a decent distance behind. Part of this is wrong usage of the tool. If you say "make a game" -- Opus will outperform the others by a large margin -- in making a generic "game" that was undefined (a paragraph of text is not a defined game). In these cases, the model has filled in all the gaps in undefined areas with average 'what probably looks good' content. You're left with something devoid of creativity. This is the problem with the myriad three.js tech demos.
If you instead have a clear understanding of what you're building, models (nearly all SOTA) will get you there cheaper by building what you've asked without speculation. I don't believe you should hand off the one human worthwhile trait, creativity, to the AI -- so "Opus build a game" is indeed the wrong way.
6. It seems hard (and pointless) to collaborate with other human developers when AI coding on smaller/indie projects. Each AI model is trying to "solve the whole thing". The speed also makes it hard to stop at arbitrary boundaries and promotes a rushed feeling or conversely a sluggish feeling (AI did all the stuff, now I'm waiting to integrate with a friend/collaborator). This is probably easily solvable but has thus far felt weird when I've collaborated.
7. The return of custom engines? While models do great with Godot and Unreal, this is the chance to build custom engines like the golden years of the 2000s. OK, this one is a bit of nostalgia but I miss the world of dozen of game engines each with their own unique look and feel. Otherwise you get XBOX 360 era where every "realistic" character looks like a Gears of War meathead. Every adventure game has the same mechanics, you're hooking something, you're scooting under something, you're scooting between walls or things, you're on collapsing things that require either button sequences or hitting your 'hook' (every adventuring has some hook of infinite rope of course). OK, this entire bullet is just a rant about samey-ness. LLMs should unlock our human creativity and allow experimentation outside of that cost imposed same-ness.
All things said, it's _clear_ that the acceleration is here if you know what you want. You can go from concept to prototype in a few hours. You then have to be disciplined enough to step back and rebuild that thing (with AI) correctly and towards a useful objective that you've thought up. I'm looking forward to went content creation catches up. Or perhaps that's a sad day when creativity vanishes.
I've been building virtual worlds, games and game engines for 25 years, and the last year has been amazing. Last December was the start of a revolution, and in the ten months since, the models have just kept getting better.
These days I can sic Opus 5.5 on ten issues from my todo list, go to bed, and wake up to them fixed. It's always faster than I would have been, but speed isn't what impresses me. It holds every issue in mind at once and connects them in ways I never did.
It has real limits. It's great at connecting what's already there, but it doesn't invent anything. It's weak on visual detail, and consistency is a foreign word to it. You have to keep steering it. Do that well and it will blow you away.
Whenever I have tokens to spare, I point it at architecture reviews, code reviews and security reviews. It keeps the codebase tight.
Over the last year it has written 250k lines of code for me, it has generated all of the icons for the game, it has written retargeters to take Maximo animations and put them on my model. Damn.
Oh no they're not. I built dozens of small games for the web and five games in Swift and they're spectacular, getting better since day one. Not like Call of Duty but just fun and bug-free enough to play them every day
Just like writing, the biggest threat to game development isn't the LLMs themselves, but a failure to disclose LLM usage. Humans want to read things humans wrote, and humans want to play what humans made.
Yes, and I don’t think this should be contentious. It’s the difference between talking to a friend, seeing their gears turn as they consider what you say, perhaps even changing them forever, and an LLM instantly provide a response that is cold and indifferent to who you are.
A human directing an LLM is often times no different than a human directing another human.
And the reality is you are setting yourself up for the most disappointing future you can imagine if your biggest concern is "failure to disclose LLM usage". Nearly everything you touch in every facet of your life going forward is going to have LLM usage to some degree. Some small, some very large. But you aren't going to be able to avoid it.
I'm not even advocating for anything -I'm just saying it's happening if we aren't there already.
A similar comparison would the consumption of meat. Factory farming causes a tremendous amount of suffering. Most people aren't privy to that suffering, and we can go on with our lives pretending that it doesn't exist. The invisibility of it doesn't mean that it doesn't matter.
> [I give a small introduction to myself and my own work, that I’m omitting here, as you’re on my website]
kkukshtel: You should keep that info, with links, even if its links to your site. Dont burden the reader.
Edit: I read the first half of the article then skimmed the rest (I dont use LLMs outside of occasional searches).
I've been a gamedev for five years. I have a hunch LLMs will not take over game development because of the necessity to control many, many small details to shape a great experience for the player, and because some parts of development cannot be described with words.
Small details: My hunch is when it comes time to polish and fine tune all the moving parts, this process will remain much faster to do by hand. It will be faster to update a specific field or line of code and test/iterate than to prompt your way through that process (the last 20% of the work takes 80% of the time)
Describing without words: An artist with a vision can only bring that vision to life with body movements. It is not possible to communicate all the details that go into a great piece of art with words. The colors, lines, shapes, positioning, specific emotions, history... is beyond spoken language.
You are talking from a perspective of games as a medium for an artist with a certain bias and an audience that is interested in this specific bias.
You say "vision, colors, positioning, etc", yet you have Candy Crush being the most played game on mobile for 13 years which simply employs direct signals and ques from cognition and cognitive neuroscience to achieve this.
The games that you describe are a small subset of what the general public is playing or is interested in.
This can further be pushed into a monoculture by shaping the players expectations about what a game should be. Maybe Skyrim has too much walking and dead-time, it's better to optimize for fast combat and action, like in Fortnite, and mold the playerbase in a way which makes them susceptible to simpler games more tuned to neurophysiology.
Even Candy Crush, a huge part of what made it successful, was the tiny details. The bright colors, the art, the subtle and not-so-subtle animations... An LLM can technically do all that, if you keep reminding it, and have strong rules, and constantly keep it in check, but there's no way it would do it on its own and keep it consistent and coherent.
Eg, if the tall green pill candy and the red round one both scale by exactly 3px when you drag them, it might still "look" wrong, and get into uncanney valley territory. And that's even assuming the LLM picked the same value to scale when you prompted it to "add a red candy", or it picked a different one arbitrarily.
I've tried making games a few times, or even CSS animations, and I can tell that they don't "feel" right, even if I have no idea why, or what to change. I have mad respect for artists and animators that can manage that, and I have no idea how you tell an LLM "It doesn't feel right when I drag the candies", and have it be able to figure out that a tall vertical candy needs to scale differently on the X and Y axis than a round one.
The OP is absolutely not talking about making Candy Crush. They ARE talking about making art. Both can exist in the same world and be successful. The existence of and success of reality TV doesn’t negate the art of filmmaking and the enjoyment of watching a movie. Same with games.
OP is invalidating the blog with the reasoning of detail, art, taste, etc is necessary for a good game.
I am saying that a small subset of people care about this given what people choose to play in practice. It's currently much, much easier to not care about these things and focus on the cognitive aspects to capture player attention, and the human cognitive incentives are not stacked in favor of OPs view.
> I am saying that a small subset of people care about this given what people choose to play in practice.
1. Candy Crush is one of the highest grossing games of all time, but if you look at the other top 20 highest grossing games, the vast majority are nothing like it.
2. Janky crush wouldn’t have been the success it was without massive attention to detail and polish.
Also there is a huge effort to optimise the game for retention, LTV and UA arbitrage.
These are not the fun details but they are details none the less and whilst LLMs will probably be more useful here the insights that drive their actions are the taste humans provide.
Candy crush is not the first of its genre, yet it is the most successful. What made it stand out from its bejeweled predecessors? Vision. Colors. Positioning. Animations. Smooth movement. Feedback. Tighter gameplay loops. Sense of accomplishment. All of the above
What are choices of vision, colors, positioning, feedback animation, sounds, etc, if not the exact things you call "employing direct signals and ques from cognition and cognitive neuroscience"? The former is the execution of the theory of the latter.
If you define art to be the transformation of cognitive scientifically addictive concepts into a game, then we are in agreement :)
>which simply employs direct signals and ques from cognition and cognitive neuroscience to achieve this.
Does anyone actually do this or is this all post hoc rationalizations on why certain things work? My experience and understanding is that it's all just a bunch of "let's try lots of things and then do more of what did well". Ie it's the result of a crazy amount of iteration rather than "employing cognitive neuroscience".
Candy crush has a team of hundreds of people, it's far from a simple game. I know for a fact they had individual product managers for certain features inside the game.
> My hunch is when it comes time to polish and fine tune all the moving parts, this process will remain much faster to do by hand. It will be faster to update a specific field or line of code and test/iterate than to prompt your way through that process (the last 20% of the work takes 80% of the time)
I think you're mostly right here -- however, I think you've framed prompting as an all-or-nothing (or maybe the OP did, as I only skimmed the article too...). LLMs are great for some things (scaffolding, review, refactoring, etc) but way less efficient at others (tweaking and letting the artist eye shine).
I think the crux is this: you shouldn't be asking an LLM to make these tweaks for you; you should be asking an LLM to build the tools that let you make these tweaks by hand faster or more effectively.
For example, we have probably a hundred tools [0] for quickly making all kinds of changes and tweaks in one of our Steam games, that are of course all done by hand. The tools were built by LLMs based on what would speed up our existing by-hand workflows, and once they're built they're just tools that let our people shine.
1. Do a thing by hand
2. Have LLMs build a tool that makes it easier to do that thing by hand
3. ????
4. An artist with a vision can bring that vision to life faster
[0] https://i.imgur.com/b4nSFjV.png
I've found it to be useful for prototyping. You can throw a game mechanic up, have it build some AI players, tell you any balance issues it runs into, play against the AI yourself to see if the mechanic feels fun. Then iterate.
A few times I've made a tweak to a mechanic and the LLM balance tests immediately found a major issue. Sometimes the AI players it creates just suck at the game. You still have to think, but just having balance tests and then having them cheap to update when I experiment, it extremely valuable. I tested this on a game I had mocked up with cardboard and forced my friends to play. It found all sorts of stuff I missed in those gameplay tests. It didn't replace those sorts of tests with humans, but it let find issues faster so I got more out of human interaction tests.
When I'm using an LLM to program these days, I increasingly feel like I'm directing one of those renaissance-era painting schools that were sort of like painting-factories, where some Great Master would direct the output of a dozen or more painting-technicians to construct unreasonably-large and detailed paintings on unreasonably-brief time-scales.
They would still come in at the end of the day to add their brush strokes to pieces of the canvas that they thought needed extra attention. We still refer to those paintings as if they were made by the Great Master, and justly so because their artistic imprint is felt in the final work.
In the same way where if you and I were asked to write the same game with an LLM, they would come out looking pretty distinct from each other. And if we wrote them by hand, they would be distinct from each other and the LLM-assisted ones again. All of them are still art and games, though, it'd be silly to call them anything else.
I agree with you that polish and fine-tuning is faster to do by hand when you are well-appraised of the foundations. I think a lot of the challenge of developing Real Software with LLMs today is maintaining the appropriate proximity to the work, when we are no longer holding the paint brush ourselves, so to speak.
> In the same way where if you and I were asked to write the same game with an LLM, they would come out looking pretty distinct from each other.
Honestly I actually think they’d end up being surprisingly similar.
I'd encourage you to actually run this exercise! I think you'd be surprised.
I've proctored some interviews where we give people an LLM, and a fairly open problem (similar to "Build a game where you do X").
The first couple of iterations are a similar, but it diverges pretty quickly depending on where the human is focusing their attention. The logical bugs of different subsystems are a bit predictable, but the final results pretty reliably contain the "fist" [1] of the human.
Of course they're similar in the ways that all software are similar. But every human is knowledgeable and/or cares about specific things more than others, and that absolutely shows up in each iteration final product.
[1]: https://en.wikipedia.org/wiki/Morse_code
"My hunch is when it comes time to polish and fine tune all the moving parts, this process will remain much faster to do by hand"
Depends if what you want to do is new, or has been done a thousand times before
"Describing without words: An artist with a vision can only bring that vision to life with body movements. It is not possible to communicate all the details that go into a great piece of art with words. The colors, lines, shapes, positioning, specific emotions, history... is beyond spoken language."
And you absolutely can use sketches, pictures, drawings as input to the AI.
So in general I agree, at least right now it needs a lot of fine tuning. About the future I make no prophecy, I did not see AI coming this way, so why would I be right about AI in the future now.
I am making a novel game right now with heavy help from Fable and it is awesome. Because even though my game is novel - parts of it are not, but standard and I reinvented the wheel way too often before and am glad don't have to do that anymore.
LLMs will absolutely take over game development. That does not mean the result will be a fun game that has value. Just like a group of expert humans can put together a technically and artistically impressive game but it has little appeal.
Taste remains king. Despite that. LLMs will absolutely be able to create elaborate games by this time next year.
> I dont use LLMs outside of occasional searches > I have a hunch LLMs will not take over game development
Not easy to make statements about things you don't use.
If you're developing software, LLMs will be ubiquitous eventually. They aren't going to tune the turn radius or how long to hold a freeze frame but they will bang out a UI to let you do that quickly with quick turn around times.
So many simple little things that are helpful but not really worth doing will now be worth doing because the implementation cost is a fraction of what it once was.
[dead]
I honestly didn't except this to get traction on HN so I'm updating the blog post now. I just read some recent post too that was like "mistakes technical blogs make" that I think brought up this same point yet here I am! Thanks for the tip.
> I stand by a lot of what I’ve said, but am in the process of shipping a project where I’ve also used none of this. I think the scale I’m targeting here is really larger projects.
The author appears to be on track to learn an important lesson about LLMs and art. LLMs have completely solved the coding side of game development. But this was never the hard part. Not even close.
The fixed randomness and determinism thing sounds great on paper (all of this does), but in reality this is an extremely confining way to build a video game. Ensuring you maintain determinism across many platforms is where things get super nasty.
If you want a turnkey AI game development experience, why not double down on diffusion? This sidesteps virtually all of the tooling and integration concerns. There is no game engine to integrate with if you use a diffusion model.
> LLMs have completely solved the coding side of game development.
This is not quite true. Currently you still need to give them guidance on what type of architecture would best work for your game, or after many iterations on gameplay you'll end up with terrible performance and a complete mess of a codebase. I expect that will be solved sooner rather than later, though.
Indeed, not even wrong. And it will whiff on the most basic gameplay issues. But it is still genuinely impressive how fast it can build a pretty but unplayable unfun thing out of nothing. And that's after many rounds of planning with it as it proceeds to ignore all that planning just because it can.
PS no, I am not interested in your alternative harness that will supposedly 100% trust me bro fix all these issues
I just built a fun somewhat clone of an old game I used to play as a kid within a day purely with LLM, i didnt even look at one line of code, nor do I have any experience in game dev. Also was a single planning session and it executed the plan well.
Fwiw I tried the same thing ~a year ago and the result was horrible; like so much worse.
Sure it’s not AAA, the art looks like shit and most people would probably not enjoy it - but it was fun for me to play and I’ll work on it a bit more to see if I can bring it into a state where others can enjoy it too.
I've made some very playable and semi-fun games with AI. But in the end, beyond the acceleration in the tooling and unit tests, it didn't save me all that much time because the mindset of the AI is so strange. The most frustrating part is the sycophancy about executing precise requests and the AI more or less says "sure thing boss!" and then does something really stupid over and over again. I have abandoned several projects over this waiting for better frontier models.
Google's recent game framework is even worse, but it does make nice assets out of the box. Not much better though than the right prompts to Nanabanana from Claude through an MCP, it's nice to get the assets out of the box the first time.
I put one of them up as a free game on itch.io as an experiment. It was immediately ratings bombed by the AI haters.
The funniest part is when the haters accuse you of not knowing how to code and I have many decades of experience doing very low level coding. I just want to play with the new tools. Then when they find that out, you now have an unfair advantage because it's impossible apparently to learn how to code now. So the only winning move is not to play, no more games on itch.io.
The United States is really strange about AI. I'm no fan of the 10 billionaires steering the ship, but steering the ship into an iceberg doesn't seem like a great move to me.
Yea I guess if you already know what you’re doing the LLM won’t help too much.
I see this a lot in my professional work where I have a much better idea of what makes sense and what doesn't.
Thanks for the assets tip though, I’ll try that out - I tried to get Claude to use blender to create some assets and they look just awful. Ultimately if I actually want to release my game to the public I will pay one of my artist friends to create proper art and assets for it.
> But this was never the hard part. Not even close.
This is revisionist history. Coding was definitely one of the hard parts!
If we're talking about game development from the 10 last years, it's not hard. It's long, tiring, sometimes boring. But most of the coding is already solved, done and reinvented maybe 50 times already. It's not hard as in "I need to think deep into solving this issue none ever solved".
I’ve been a professional engineer in games for 24 years and can safely say this idea that things aren’t hard anymore is silly. Programming games has definitely got less unpleasant as tooling is much better but the actual mental problems are tough as ever.
You might be mistaking the sheer variety of games and that some are really quite simple for all games being easier to make.
if you're thinking purely about game loops and game mechanics, yes a lot has been done before and used over and over again. but that's by no means all the programming going on.
just look at how much people complained about poorly optimized games in the past decade. the most impressive game dev feats in terms of programming were not the game mechanics, it was getting their game to run as well as it did on (very) limited hardware resources, a problem we are hitting again now. and it is very obvious looking at modern games that this problem is nowhere near solved, and in fact very hard.
Sorry, but no. This is not true. It definitely was hard. So hard that few people actually made games. I remember using GAS (Unreal Engine) and being baffled by the complexity of the framework. And then when I didn't use GAS, I was baffled by the complexity of what it handled. It's hard.
What are you talking about? Maybe for throwaway mobile games. Serious game dev is full of novel challenges. New graphics techniques are constantly being researched and discovered. There are critical resource constraints unique to every game, and each one needs bespoke solutions. There aren't one size fits all solutions to most high fidelity games.
> It's long, tiring, sometimes boring
all those things equal time and money eg. difficulty
I'm not sure time or money inherently equal difficulty. There's plenty of things that take a long time to build and/or are expensive to build, but are still easy to build.
No, those are simple: add more money or add more time.
The hard parts are the bits that you can't just "add more" to.
> The fixed randomness and determinism thing sounds great on paper (all of this does), but in reality this is an extremely confining way to build a video game. Ensuring you maintain determinism across many platforms is where things get super nasty.
Why 'nasty'? I agree it's a problem to solve, but you just use a fixed-point math library and it's fine. Determinism is freeing, not confining. It allows you to do things like rollback netcode, replays and easy debugging. You can't just say that 'reality' happens to be what you in particular are used to.
> Why 'nasty'? I agree it's a problem to solve, but you just use a fixed-point math library and it's fine.
Assuming the agent didn't put in a native nondeterministic trig function deep in the code instead of using the library one, it's an easy mistake to make and hard to debug in a big game. It won't even show unless you have a robust CI matrix. It can indeed be "nasty" to maintain.
Also determinism might work for simulation state, but shader/gfx differences across platforms can be really nasty and a library can't save you. Not even something like WebGPU. Also if you're doing any sort residency streaming dependent on GPU timings trying to make that deterministic will be a nightmare.
Unless the GPU output is feeding back into the game loop simulation, there’s no nightmare.
I’ve worked on games with intentional determinism, and it’s a very valuable tool. A playtester can hand a dev a recording of the game inputs (including clock) for whatever bug they encountered, and the dev can fast forward to the exact point and repro it 100%. The amount of time saved chasing down difficult bugs is enormous.
But that CI is very easy to setup.
Take a given start point; feed a set of inputs; compute a checksum on the resulting state. Check that the checksum matches on different platforms.
And if your language is good you can parameterize your logic on a particular numeric type, so that a particular fixed point implementation is consistently used
There’s way more to making a game deterministic than slapping in a fixed point library which isn’t strictly necessary in and of itself.
I partially agree. Coding is not the hardest part for a large portion of indie games. You can in theory build an AI-coded game that sells well if you have the right art and gameplay.
But many top games have complex engines and online services that require technical mastery beyond the current AI capabilities. For those genres, engineering is a huge barrier of entry.
For a not so extreme example, you won't vibe code Cyberpunk 2077 while just taking care of art and gameplay ideas. Gosh, humans could barely pull that one off!
> Ensuring you maintain determinism across many platforms is where things get super nasty.
I learned that one the other day - I've been building a little RTS game with a replay mechanism, and replays in Safari broke where they worked in Chrome. Opus 5.5 fixed it by replacing calls to things like Math.sin() and Math.cos() with its own deterministic functions: https://gist.github.com/simonw/7df96ed7296c69b70a9990102cae0...
[flagged]
I think it's more generous to say it's not the only hard part. It's certainly very, very hard for a lot of people.
LLMs certainly haven’t solved coding.
hello, author here!
It's definitely not my intention to try and describe ways for making game development be more turnkey. I'm more trying to directly address ways to make non-one-shot (read: actual) game development be more tenable when an agent is involved.
[flagged]
> “LLMs are Bad At Games”
> Any time I tried to use an LLM for a game-y thing, it would fall over.
You know it's funny. I did a bit of LLM-assisted game dev this year.
I spent a few weeks working on a simple Pong game, just polishing it, making small changes here and there. Frontier models couldn't change or add a feature without breaking something else. It was still more productive than working "solo" but quite annoying.
Meanwhile, I asked a model to make an entire game -- about 100x more complicated -- and it just one-shotted it perfectly, no issues.
I'm not sure how both of those things can be true at the same time. Something something "in-distribution" ?
Yes, that's about right. It is much easier for it to roughly copy other code that it has seen, than to understand the code it has been given enough to make targeted fixes.
When you start from the end, model may make the proper architecture for everything you will need, and for everything it needs to know that implementations is correct.
I think verifiable game engines are slowly starting to appear. After all, nothing can stop you from unit-testing the game like Factorio does ( https://youtu.be/CgMV2dFFdFE?t=48 ) other then your not bothering to think about it. I have made one even, see https://github.com/Dimava/gensokyo-survivors/tree/master
> this year
Models change so fast now that even "this month" becomes abstract. Everyone, please make sure to mention the name of the model.
> Frontier models couldn't change or add a feature without breaking something else.
Have you tried working with Rust (e.g. Bevy) and all of its compile-time guarantees to prevent that? I imagine it must help a lot.
To clarify, there were no compile or run time errors, it just kept breaking the game.
The code might've been garbage in the one shot case. But it doesn't really matter IMHO
Yeah sounds like you didn't polish the new thing.
The hard stuff that comes after "implementing the basics" and released game. The stuff that is hard to even verbalize and takes lots and lots of iteration. Good luck using AI for all that.
That’s 100% it.
I one shotted a math game for my 4 year old complete with lots of juice “screen shake, explosion animations etc…”.
It worked great, but if I tried to change even the slightest thing the result was worse than the initial output. No matter how hard I tried to nail things down with tests and specs, each change looked or felt worse.
[dead]
It's kind of funny how it took inventing AI for people to start caring about good software engineering practices (debuggability, iteration speed, reliability, etc.)
Do they? Genuine question, because I don't see how.
I googled "good practices for ai coding" and got these two pages as the top results: https://dev.to/ranndy360/ai-coding-best-practices-in-2025-4e... https://statistician-in-stilettos.medium.com/best-practices-.... Half the things listed on those pages are just good software engineering practices, regardless of AI.
Some excerpts:
> [Code] in small increments. Run unit tests after each integration.
> Write tests before integrating [new] functions (TDD mindset).
> Define project-wide standards and style guides
> I took the time to map out the modules, data flow, and responsibilities of each component of my app.
> periodic cleanups helped prevent the codebase from becoming overly complex or disorganized
etc.
It feels like returning to the origins, now with the excuse that it's good for the robots.
Step 1: Follow these best practices, they really help humans develop and maintain software.
Step 2: Whatever, we will just be "agile" and humans need to deal with it or get fired.
Step 3: Follow these best practices, they really help robots develop and maintain software.
Somehow "it reduces token usage" is more important than "it prevents developer burnout".
I kinda get it. To massively simplify: Without AI, your choice is 8 days implementing, or 5 days planning/designing/refactoring and 5 days implementing. With AI, your choice is 5 days wrestling with the AI to implement, or 4 days planning/designing/refactoring and 1 day with the AI to implement. I made up those numbers but the general idea is that good practices have a lot more leverage with AI, since the make the implementation "free".
It's strange, but as soon as I saw the first slide, I was "why are these properties hard-coded?" and then as we went through, it felt like a tour through "decouple your entities 101". Are games really hard-coded spaghetti like this?
I've never written a game (well, not since my Acorn Atom days writing Missile Command in Assembler) but I'm kinda inspired now.
The author of the article himself may answered your question:
"I’m decidedly less well versed and am inclined to think that whatever code the LLM produces is “good”. Maybe it’s actually garbage. But there is reason to believe the Svelte and web-stack stuff is quality, in part due to the fact that there are LOTS of high quality web projects with their source available online."
I recommend to also take a look at Godogen[1][2] which includes other insights as well. I also tried it to produce 2D animations of fairy tales.
[1] https://github.com/htdt/godogen
[2] https://hn.algolia.com/?q=godogen
This matches what I came up with on a small project. The biggest ones being screenshots and separated simulation.
Meta level, just push your agent to make things more legible, it’ll figure it out.
One other observation, remember that your agent is infinitely patient. So prompts like “build an interactive design doc with videos of each game mechanic in the style of Factorio dev diaries” can make reviewing changes easier. The general idea, all the small QoL dev tools that you don’t have time for, you can just spawn a side agent to build; if they are orthogonal to your main thread you can just progress them in the background.
One thing I think game dev has not (AFAIK) invested as much in is observability. There’s a lot of perf instrumentation available in debug builds, but things like measuring DPS, health, etc as an exported metric time series I have not seen before. I think agents will benefit from this disproportionately more than humans, eg for inspecting progression curves and balance.
In my case, the most valuable prompt I made was, "please figure out how to run the game headlessly, so I can use my PC while you muck around". It did, and that gave it ability to run multiple instances in parallel, which it now uses autonomously whenever it needs to confirm assumptions or validate changes.
AI can definitely do all aspects of game development now, but this advice seems to mostly apply to small indie titles or experiments.
For example, the Thing approach is reasonable for a small game, but it's a dead end for a performance budget or layered subsystems. In a reasonably sized 3D game, iterating and copying 30 subsystems of 1000's of Things is impossible to do in frame time, the only fix is a total rewrite of literally everyThing. That's why there's ECS, SOA, etc. which needs a different kind of harness.
Also, art completely dominates the production cycle of modern games, which (even if AI generated) needs its own category of harness not mentioned here. And AI can be very good at optimizing, but samply won't diagnose your overdraw, and GPU needs its own ablation and attribution.
For the time being there's no panacea and we still need "game developers", though the bar for prototypes (and certain genres) is lowered.
Kyle seems smart and I enjoy some ideas on his podcast and blog. But I do think his many strong opinions about how games should be developed are reflective of a lack of experience shipping stuff with an actual playerbase
It's conceptually interesting but I don't know it is instructive beyond simple projects
"Thing" style systems are very common in AAA. I link to the interview with the Dreams (Media Molecule) team where they describe a system very much like this. ECS is also not mutually exclusive here.
Dreams did use a standard ECS [1] and despite being a first-party title it's not widely considered to be a AAA game (based on size of the team and budget compared to typical AAA games). There might be some AAA studio that eschews the approach, but it's very common for speed and efficiency, especially on consoles.
That said, I'm glad you shared your thoughts and experience. It's helpful to see what people try.
[1]: https://youtu.be/mFBmoCv5EcQ?t=1982
I wrote an automated testing system for my game engine to take screenshots and simulate input for automated testing and then I realized how good claude was at using it to make games that I wrote a guide about it in my engine documentation:
https://vectarineengine.com/guides/working-with-agents/
I started coding because of gamedev, seeing this and potentially having some agents take care of the coding part is a blessing. I doubt this works as advertised but imagine iterating on stuff with a couple prompts and you can alt tab back into blender or libresprite. Very cool, lets put economics and employment aside
Good planning is needed. All planning should be done without resorting to artificial intelligence, or the game should be fully explained to the AI and the plan should be handled by it, and that plan should be adhered to. Whichever you prefer...
A lot of the points the author made about game dev with AI are things that I notice in my experience as well. That is why me and a friend started to work on https://folly.gg an AI game maker that internalizes several of these learnings.
That looks really amazing, happy to test it!
Thanks! We should soon have something ready to share
>> “LLMs are Bad At Games”
At making them? Maybe.
At already made ones? Well, I guess it depends.
Case study: a 1997 PC game I played as a kid, getting it to run on modern hardware, and in progress of making it look like it looked in my head.
Claude Code got the first part done in 30 minutes, and in process set up some basic RE environment. Then, iterating over various aspects, it gradually decompiled most of it, then - on my request, being annoyed with "computer use" plays taking over my PC - extended the shimmed DirectX DLL to run it headlessly (using "Private Desktop" feature of modern Windows, too, which I didn't even know existed), and this gave it the ability to run several game instances in parallel. As for playing, it quickly mapped relevant memory addresses and game logic scripts, and uses a combination of hand-written scenario files, patches to level data and memhacks, to do whatever it needs to be done.
All throughout, with some nudging from me, it produced a stupid amount of helper tools to give me insight into how the game is built, allowing me to verify its work and direct it better.
So I can't say I agree with the general gist, given that Claude is now writing me full level guides, complete with decent screenshots of important moments, all zero-shot.
TL;DR: just let LLMs instrument your game and figure it out on its own.
This is very cool and on a lower level (more in the trenches) compared to what I did earlier in the year (i did a small writeup and built some skills [1]).
Because I am so-and-so pixel artist, the biggest unlock for me has been in rapidly iterating with graphics assets and sprites, and it's actually helped me become a better artist and animator (I built my own little tool for this [2]). The rest Codex or Claude Code seem to handle incredibly well (plus I have 30 years of programming behind me).
[1] https://github.com/acatovic/gothicvania-codex-demo
[2] https://github.com/acatovic/ai-game-studio
I was able to get a decent FPS out of around 40k lines (excluding tooling). Tooling consisted mostly of level editing and asset conversion which I tried to keep out of the main code-base.
> Any time I tried to use an LLM for a game-y thing, it would fall over. Maybe this is my own bias. I’ve been a game programmer for nearly 15 years, I think I know how things work. I can sniff out “bad” game code a mile away. But when it comes to Svelte web-apps, I’m decidedly less well versed and am inclined to think that whatever code the LLM produces is “good”.
It feels like the discovery of a specific form of gell-mann amnesia. I know when working with an agent through areas where I have domain expertise I catch bad assumptions, decisions, etc. But then, unfortunately, have to trust it much more where I have minimal expertise.
i usually tell claude to autism optimize on low frame rate areas. i made eden emulator from crashing, to like 2 fps, to 30-20 fps on botw on a pixel 10
the harness is basically adb + some profiling changes and the ability for the model to dump frames
I was a game developer for many years, at large scale (MMO) and at small scale (indie).
With the advent of AI, I've been _trying_ to use AI to accelerate game development and have come to a few conclusions.
1. AI models want to make everything deterministic. This sounds like a truly sound way to write a verifiable program. Games are not verifiable simulators except in the niche of ...simulators. Even in those cases, the vast infrastructure devoted to this leads to a lot of churn, bugs (AI forcing things to align with the verifier), and rigidity.
2. Making a game != Fun. This one is obvious but needs to be stated. Anyone on earth right now can say "make me doom" or "make me a super mario clone" and Opus/Astra will dutifully comply and make something generic and bland. Once the novelty of "oh wow it actually built it" wears off, you're left with a mediocre clone, lacking depth, that no customer would want hoisted upon them.
3. Content and novelty are the hard parts. AI models always create the mediocre middle. There's real work (and interesting work) involved in both inventing novel gameplay systems which LLMs will never stumble upon despite infinite 'brainstorming prompts'. But, AI is 'OK' at taking your novel idea and proposing directions -- that you can then strike down viciously until something interesting emerges.
On the content side, this has always been a truism for an independent developer. AI art tools aren't quite there yet. There's image-to-3D and there's Mixamo for animation but we're not there yet. Nearly though! But again, will every game look like a bland generic AI generated image with bland AI generated models?
4. AI models are crap at building re-usable large-scale architectures. Even building with Opus 5.5 and Astra they will happy design themselves into a corner. Yes, they can _also_ design themselves out of that corner at speed - with a lot of pain and code churn and mess. I've found it vastly better to iterate slowly, using your experience (if you have it) to structure the core architecture and systems the way you want (AI writing the code) -- and then build upon that solid base -- taking special care to reject updates that butcher your architecture. I think this applies to most coding projects actually.
5. Game dev currently surfaces very clear differences in model capabilities with Opus 5.5 leading the pack (in this domain) and Fable 5.1 and Astra/GPT-6.1 Sol following a decent distance behind. Part of this is wrong usage of the tool. If you say "make a game" -- Opus will outperform the others by a large margin -- in making a generic "game" that was undefined (a paragraph of text is not a defined game). In these cases, the model has filled in all the gaps in undefined areas with average 'what probably looks good' content. You're left with something devoid of creativity. This is the problem with the myriad three.js tech demos.
If you instead have a clear understanding of what you're building, models (nearly all SOTA) will get you there cheaper by building what you've asked without speculation. I don't believe you should hand off the one human worthwhile trait, creativity, to the AI -- so "Opus build a game" is indeed the wrong way.
6. It seems hard (and pointless) to collaborate with other human developers when AI coding on smaller/indie projects. Each AI model is trying to "solve the whole thing". The speed also makes it hard to stop at arbitrary boundaries and promotes a rushed feeling or conversely a sluggish feeling (AI did all the stuff, now I'm waiting to integrate with a friend/collaborator). This is probably easily solvable but has thus far felt weird when I've collaborated.
7. The return of custom engines? While models do great with Godot and Unreal, this is the chance to build custom engines like the golden years of the 2000s. OK, this one is a bit of nostalgia but I miss the world of dozen of game engines each with their own unique look and feel. Otherwise you get XBOX 360 era where every "realistic" character looks like a Gears of War meathead. Every adventure game has the same mechanics, you're hooking something, you're scooting under something, you're scooting between walls or things, you're on collapsing things that require either button sequences or hitting your 'hook' (every adventuring has some hook of infinite rope of course). OK, this entire bullet is just a rant about samey-ness. LLMs should unlock our human creativity and allow experimentation outside of that cost imposed same-ness.
All things said, it's _clear_ that the acceleration is here if you know what you want. You can go from concept to prototype in a few hours. You then have to be disciplined enough to step back and rebuild that thing (with AI) correctly and towards a useful objective that you've thought up. I'm looking forward to went content creation catches up. Or perhaps that's a sad day when creativity vanishes.
I pretty much agree with everything he said.
I've been building virtual worlds, games and game engines for 25 years, and the last year has been amazing. Last December was the start of a revolution, and in the ten months since, the models have just kept getting better.
These days I can sic Opus 5.5 on ten issues from my todo list, go to bed, and wake up to them fixed. It's always faster than I would have been, but speed isn't what impresses me. It holds every issue in mind at once and connects them in ways I never did.
It has real limits. It's great at connecting what's already there, but it doesn't invent anything. It's weak on visual detail, and consistency is a foreign word to it. You have to keep steering it. Do that well and it will blow you away.
Whenever I have tokens to spare, I point it at architecture reviews, code reviews and security reviews. It keeps the codebase tight.
Over the last year it has written 250k lines of code for me, it has generated all of the icons for the game, it has written retargeters to take Maximo animations and put them on my model. Damn.
Pleasant reminder that building good architecture for agents just ends up mirroring time-tested software engineering practices.
[flagged]
[flagged]
[flagged]
"LLMs are Bad At Games"
Oh no they're not. I built dozens of small games for the web and five games in Swift and they're spectacular, getting better since day one. Not like Call of Duty but just fun and bug-free enough to play them every day
did you build games before the advent of llms?
keyword here is "small" maybe?
Just like writing, the biggest threat to game development isn't the LLMs themselves, but a failure to disclose LLM usage. Humans want to read things humans wrote, and humans want to play what humans made.
Humanity is at a crossroads: Should we judge creative work by its authorship or by its merits?
Is something beautiful worth less if it was made by a probabilistic machine?
Yes, and I don’t think this should be contentious. It’s the difference between talking to a friend, seeing their gears turn as they consider what you say, perhaps even changing them forever, and an LLM instantly provide a response that is cold and indifferent to who you are.
A human directing an LLM is often times no different than a human directing another human.
And the reality is you are setting yourself up for the most disappointing future you can imagine if your biggest concern is "failure to disclose LLM usage". Nearly everything you touch in every facet of your life going forward is going to have LLM usage to some degree. Some small, some very large. But you aren't going to be able to avoid it.
I'm not even advocating for anything -I'm just saying it's happening if we aren't there already.
A similar comparison would the consumption of meat. Factory farming causes a tremendous amount of suffering. Most people aren't privy to that suffering, and we can go on with our lives pretending that it doesn't exist. The invisibility of it doesn't mean that it doesn't matter.
> But you aren't going to be able to avoid it.
However small, there will always be a subset of creators with artistic integrity.
Fortunately, they will also be the ones making the most interesting and meaningful art.
And it's certainly good for keeping my backlog manageable.