A developer who can build a game by hand in 24 hours could probably build and publish something very polished and professional on Steam within 3 days using LLMs, which leads to some kind of software Fermi paradox: where are all the games??
The LLM started with a three month headstart, both in terms of code, using the previous game as a template, and more importantly, all of the learnings and mistakes you made in the hand-coded pass.
What I like about this post is that it highlights something a lot of devs gloss over: the coding part of game development was never really the bottleneck. A solo developer can crank out mechanics pretty quickly, with or without AI. The real grind is in all the invisible layers on top; balancing the loop, tuning difficulty, creating assets that don’t look uncanny, and building enough polish to hold someone’s attention for more than 5 minutes.
That’s why we’re not suddenly drowning in brilliant Steam releases post-LLMs. The tech has lowered one wall, but the taller walls remain. It’s like the rise of Unity in the 2010s: the engine democratized making games, but we didn’t see a proportional explosion of good game, just more attempts. LLMs are doing the same thing for code, and image models are starting to do it for art, but neither can tell you if your game is actually fun.
The interesting question to me is: what happens when AI can not only implement but also playtest -- running thousands of iterations of your loop, surfacing which mechanics keep simulated players engaged? That’s when we start moving beyond "AI as productivity hack" into "AI as collaborator in design." We’re not there yet, but this article feels like an early data point along that trajectory.
This makes me feel like games will be the last bastion to fully fall to AI.
In traditional business apps, your goal is to make your app work and look intuitive enough for a human to use. When developing a game, you have a few extra goals, it also has to be fun, rewarding and different enough from other games that came before. It feels like the former group will be much easier to judge by non-humans than the latter.
> The interesting question to me is: what happens when AI can not only implement but also playtest -- running thousands of iterations of your loop, surfacing which mechanics keep simulated players engaged?
Much the same as we do today in games and film both, something saccharine and mediocre built to appeal to a wide majority. Worse, if this process becomes streamlined and widely accessible, you're competing with a hundred other saccharine and mediocre built to a wide majority games. AI generated shovelware, it's like the shovelware of today where anything remotely popular generates dozens of cheap clones, but with AI.
Personally, i don't think the coding part of game development was not a bottleneck.
Just try to implement, for example, a hexagon-based isometric game. There are no off-the-shelf implementations -- you'll need to redo the pan / zoom / click controls yourself, you'll need to implement the pathfinding, map layers, interface state machine etc etc etc
This is still not an easy task -- to build a somehow complicated game. If you're building a platformer -- sure, that's doable. Strategy/4X/RPG? That's different.
You are absolutely right! The tic-tac-toe game we‘ve been working on is a total blast and simulated players 1-1000 enjoy it very much! I think we should release it soon.
I've been participating in these for way longer than our current breed of LLMs or GenAI or engines. Back in the day, your best option was Microsoft's XNA and C#. (Unity had not been invented yet.) Plus most art looked like hand-drawn in paint, because it was. Still, we saw plenty of enjoyable games each year. And some made it to a wider audience, like Baba is You or Braid.
The coding was never the bottleneck. I strongly believe it's the communication among team members.
I like LLMs because it helps abstract code in a way that's more directly compatible with how I think about programs.
When I read code, it gets turned into something akin to an AST, where functions and calls are more of an abstract notion of input and result.
The LLM vastly simplifies the inverse process. Instead of having to go and find the way to represent an idea in code, or digging through my memory and code archives for an example, I can instead tell the LLM to write the boilerplate to initialize WiFi or whatever. It simplifies code into Lego pieces that I can assemble into a program that's more representative of my internal conception of the problem.
I've been flying through different programming languages with LLMs. When the text and grammar can be abstracted away, I can focus on the program. I was able to do this before LLMs, but with a lot more effort. Like, sure, I don't learn a whole lot about each language as I go, but that's exactly the point. The text and semantics of any one language should be largely irrelevant to the logical flow of the program itself. The text is nothing more than a semi-standardized way of representing logic in a form that can be parsed by machines and (secondarily) by humans.
First we abstracted machine code to assembly. Then low level languages like C, then higher and higher level languages until the machine itself became utterly irrelevant. It only seems natural that we'd further abstract these languages and move closer to the goal of programming instead of coding.
I don't think we've even seen hints of how this will look in the end, but I'm certain that we'll spend less and less time writing and more time programming.
overall I'd say around two working days. I used it as a test ground first for greenfield and then Brownfield development, so nothing serious, but I found myself in a loop of ever growing details I wanted tuned, more and more features (super rotations system, das, this and that).. I'd say it's maybe 10-20% of where I'd take it as a full game, even have a webgl version functional somewhere.. but I had to stop before I started making my ultimate Tetris since I don't want to get sued nor I have (probably) money for a full license to drive it through the end. I heard they charge a pretty penny.. but I am now confident I could drive it home and that's what I took, the experience, to other software development with llm now.
the other day there was an interesting link here on HN about parametric functions. I got an itch then as well, and within an hour or two a playground: https://www.susmel.com/graphy but also, details, details, details. If you know what you wanna see it's quite enjoyable actually.
I have done a decent amount of hobby game dev including completing several games. The comments here i think show a strong lack of real game dev knowledge.
Coding is a hard part of game dev. Coming up with interesting novel mechanics or plays on known genres is rather easy but bringing them to life is hard esp the code. Multiplayer vampire survivors but with giant battletech mech customization. See, very easy. Good luck building that with an LLM.
This uses well known card games as the mechanics which is about as interesting as snake games. This is not a knock at the op. But it is clear many people here havent done much game dev from the comments.
Getting high level ideas "X but Y with Z" is easy. What's hard is actually understanding what makes X work and how to adapt it to properly incorporate Y. I've played a bunch of games that had Vampire Survivors, FTL or Factorio as their starting point, but failed to deliver a good game loop.
I agree, turning a simple idea into a polished game takes like a year. Most of it isn't even in the core idea but surrounding polish, menus, extra features, etc. Source I did it.
Also I'm just saying the stack from this post is insane. It would probably one shot the task in p5js or C/raylib
This comments shows that most of the users in this thread have not done game development.
We are judging the usefulness of a LLM in a project that is really over represented in training data (a bunch of Intro to Programming courses requires a project like this, and in southern Europe countries we have a lot of similar games like the one in the blog)
In the first year of college I reimplemented Moon Patrol in Python, I had no previous experience basically and it tooks me two/three months of work coding 3 days per week mostly.
Coding a card game is easier than that. LLMs are useful for certain things but this is not a good way to benchmark their usefulness in any type of game development coding.
It feels like all the 'low hanging fruit' ideas in the software space are basically gone, made non-viable because of too much competition. It was already somewhat the case that software industry was very competitive, even before people could code entire apps with AI... At least you could find a niche which was too small to be of interest to big VCs. Now, it's like, regardless of whether you choose a big idea or a niche, you have to compete on a global scale with either big VC or big AI...
This only leaves a few areas; niches which are both small and require very complex solutions; or software with low profit margins which have high risk of failure and short-lifespans (which is what most games are). Due to media saturation, for the former approach (complex niche), you basically have to market the solution to people door-to-door, one-by-one.
My experience of the game sector is that it's very difficult. Before you even begin coding, the definition of runaway success is basically "Attain a few million views, then watch traffic dry up completely as the game becomes completely irrelevant over 6 months." I could never get into games because knowing that you probably won't get recurring income is just too demoralizing as a starting point. Building a game like Minecraft is basically outside of the realm of possibility... Games like Minecraft, World of Warcraft are essentially 1 in a million games. You're better off just buying lottery tickets.
That said, I think the game sector seems to be more meritocratic than all other sectors of software that I'm aware of... Not sure that's saying much but I do think there is a correlation between quality and 'fun level' of the game and the short-term adoption of the game.
Most other sectors of tech are a maze of regulatory capture, network effect monopolies or the sector is fully government-controlled to begin with. It would be nice if governments would tell people "Don't do a startup in this sector because we already decided which company will control that sector." because it sucks to find out after building a solution for 1 year.
We got Claude to shim our ClayGL frontend and drop-replace it with Three.JS in a weekend. Now, there was a lot of cleanup to be sure, but it still saved a ton of work!
I cloned the backend for Truco and gave Claude a long prompt explaining the rules of Escoba and asking it to refactor the code to implement it.
Definitely still incredible by 2019 standards. Absolutely no doubt.
But by LLM standards, feeding it the entire working codebase of a simple, similar, game you wrote by hand as context is basically doing all the work yourself still.
I played around with making games in go for a while and found limited benefits. Go routines, while great, have too much latency to meaningfully parallelized simple tasks between the in-game ticks per second (~60hz). Along the same lines, channels end up having too many allocations/frees and read/writes to be useful at such a normal ticks per second (TPS).
The result is you can't use the best features of go, and even the 2D engine I used (ebiten) didn't use go routines or channels anywhere in the engine. I like the idea of making games in Go, but the language's best features don't shine well, and I struggle to imagine it ever taking off beyond a hobby game language.
To me the most complicated thing in every project is the business knowledge. It's the tribal knowledge like "do not send null in this endpoint" or what happens when a request A will be send after B was sent to C and the mercury was in conjunction with venus on an odd day of march (answer: everything would explode). And LLM are solving 20% of my work, while the other things are talking to people, inventing new tests etc. I wonder btw. why the LLM bubble created problems on developers' hiring market. Were those companies thinking that LLM will write the code on its own?
When it comes to game development, I think we should choose a single language for both the front end and back end. This would make it easier for Claude Code to understand the context and remove the need to explain different services to the LLM model.
34 comments
[ 3.7 ms ] story [ 56.6 ms ] threadThat’s why we’re not suddenly drowning in brilliant Steam releases post-LLMs. The tech has lowered one wall, but the taller walls remain. It’s like the rise of Unity in the 2010s: the engine democratized making games, but we didn’t see a proportional explosion of good game, just more attempts. LLMs are doing the same thing for code, and image models are starting to do it for art, but neither can tell you if your game is actually fun.
The interesting question to me is: what happens when AI can not only implement but also playtest -- running thousands of iterations of your loop, surfacing which mechanics keep simulated players engaged? That’s when we start moving beyond "AI as productivity hack" into "AI as collaborator in design." We’re not there yet, but this article feels like an early data point along that trajectory.
In traditional business apps, your goal is to make your app work and look intuitive enough for a human to use. When developing a game, you have a few extra goals, it also has to be fun, rewarding and different enough from other games that came before. It feels like the former group will be much easier to judge by non-humans than the latter.
Much the same as we do today in games and film both, something saccharine and mediocre built to appeal to a wide majority. Worse, if this process becomes streamlined and widely accessible, you're competing with a hundred other saccharine and mediocre built to a wide majority games. AI generated shovelware, it's like the shovelware of today where anything remotely popular generates dozens of cheap clones, but with AI.
The best games take risks and aren't min/maxed.
Just try to implement, for example, a hexagon-based isometric game. There are no off-the-shelf implementations -- you'll need to redo the pan / zoom / click controls yourself, you'll need to implement the pathfinding, map layers, interface state machine etc etc etc
This is still not an easy task -- to build a somehow complicated game. If you're building a platformer -- sure, that's doable. Strategy/4X/RPG? That's different.
https://nordicgamejam.com/
I've been participating in these for way longer than our current breed of LLMs or GenAI or engines. Back in the day, your best option was Microsoft's XNA and C#. (Unity had not been invented yet.) Plus most art looked like hand-drawn in paint, because it was. Still, we saw plenty of enjoyable games each year. And some made it to a wider audience, like Baba is You or Braid.
The coding was never the bottleneck. I strongly believe it's the communication among team members.
When I read code, it gets turned into something akin to an AST, where functions and calls are more of an abstract notion of input and result.
The LLM vastly simplifies the inverse process. Instead of having to go and find the way to represent an idea in code, or digging through my memory and code archives for an example, I can instead tell the LLM to write the boilerplate to initialize WiFi or whatever. It simplifies code into Lego pieces that I can assemble into a program that's more representative of my internal conception of the problem.
I've been flying through different programming languages with LLMs. When the text and grammar can be abstracted away, I can focus on the program. I was able to do this before LLMs, but with a lot more effort. Like, sure, I don't learn a whole lot about each language as I go, but that's exactly the point. The text and semantics of any one language should be largely irrelevant to the logical flow of the program itself. The text is nothing more than a semi-standardized way of representing logic in a form that can be parsed by machines and (secondarily) by humans.
First we abstracted machine code to assembly. Then low level languages like C, then higher and higher level languages until the machine itself became utterly irrelevant. It only seems natural that we'd further abstract these languages and move closer to the goal of programming instead of coding.
I don't think we've even seen hints of how this will look in the end, but I'm certain that we'll spend less and less time writing and more time programming.
overall I'd say around two working days. I used it as a test ground first for greenfield and then Brownfield development, so nothing serious, but I found myself in a loop of ever growing details I wanted tuned, more and more features (super rotations system, das, this and that).. I'd say it's maybe 10-20% of where I'd take it as a full game, even have a webgl version functional somewhere.. but I had to stop before I started making my ultimate Tetris since I don't want to get sued nor I have (probably) money for a full license to drive it through the end. I heard they charge a pretty penny.. but I am now confident I could drive it home and that's what I took, the experience, to other software development with llm now.
the other day there was an interesting link here on HN about parametric functions. I got an itch then as well, and within an hour or two a playground: https://www.susmel.com/graphy but also, details, details, details. If you know what you wanna see it's quite enjoyable actually.
Coding is a hard part of game dev. Coming up with interesting novel mechanics or plays on known genres is rather easy but bringing them to life is hard esp the code. Multiplayer vampire survivors but with giant battletech mech customization. See, very easy. Good luck building that with an LLM.
This uses well known card games as the mechanics which is about as interesting as snake games. This is not a knock at the op. But it is clear many people here havent done much game dev from the comments.
Other than that. Loved the article and I love making games (haven’t shipped one in a while, I should)
We are judging the usefulness of a LLM in a project that is really over represented in training data (a bunch of Intro to Programming courses requires a project like this, and in southern Europe countries we have a lot of similar games like the one in the blog)
In the first year of college I reimplemented Moon Patrol in Python, I had no previous experience basically and it tooks me two/three months of work coding 3 days per week mostly.
Coding a card game is easier than that. LLMs are useful for certain things but this is not a good way to benchmark their usefulness in any type of game development coding.
This only leaves a few areas; niches which are both small and require very complex solutions; or software with low profit margins which have high risk of failure and short-lifespans (which is what most games are). Due to media saturation, for the former approach (complex niche), you basically have to market the solution to people door-to-door, one-by-one.
My experience of the game sector is that it's very difficult. Before you even begin coding, the definition of runaway success is basically "Attain a few million views, then watch traffic dry up completely as the game becomes completely irrelevant over 6 months." I could never get into games because knowing that you probably won't get recurring income is just too demoralizing as a starting point. Building a game like Minecraft is basically outside of the realm of possibility... Games like Minecraft, World of Warcraft are essentially 1 in a million games. You're better off just buying lottery tickets.
That said, I think the game sector seems to be more meritocratic than all other sectors of software that I'm aware of... Not sure that's saying much but I do think there is a correlation between quality and 'fun level' of the game and the short-term adoption of the game.
Most other sectors of tech are a maze of regulatory capture, network effect monopolies or the sector is fully government-controlled to begin with. It would be nice if governments would tell people "Don't do a startup in this sector because we already decided which company will control that sector." because it sucks to find out after building a solution for 1 year.
But by LLM standards, feeding it the entire working codebase of a simple, similar, game you wrote by hand as context is basically doing all the work yourself still.
The result is you can't use the best features of go, and even the 2D engine I used (ebiten) didn't use go routines or channels anywhere in the engine. I like the idea of making games in Go, but the language's best features don't shine well, and I struggle to imagine it ever taking off beyond a hobby game language.
https://thomashansen.xyz/blog/ebiten-and-go.html