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.
> 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?
How is AI supposed to simulate a player, and why should it be able to determine what real people would find engaging?
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.
> 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.
But we did? We've come a long way from the limited XBLA catalog. It didn't happen overnight, but doubtless we wouldn't have the volume of games we have today without Unity, Godot, Gamemaker, Renpy, RPG Maker...
My litmus test for generative AI: generate a complete spritesheet for a 2D pixel art action game, e.g. only for the battle tank or main hero movements. No success so far.
This holds in other areas as well, and to me at least the conclusion follows from the evidence: there is seemingly a lot of potential in agent coding, a few tasks are just crushed/solved (quick webapp demos, other library stitching in the small) but for real software in the large? It's not there yet in either the way the models are tuned or our collective expertise in using them.
And this isn't surprising: git-style revision control hit the scene almost 20 years ago, it was like 5 years until it was totally dialed in anywhere, another 5 before elite companies had it totally figured out, and its been slowely diffusing since, today its pretty figured out. And this is harder to use right than git.
I think it would go faster actually if every product release, every OSS tool, every god-damned blog post wasn't hell bent on saying "its done, its solved, old way cooked, new world arrived".
We're figuring it out and it takes time. That's OK.
If it was done, then we'd be drowning in great software. We're not, we're breaking even, which is impressive for a big new thing 1-2 years in.
> coding part of game development was never really the bottleneck
Doesn't look exactly that to me. The author built a server, studied React, built a frontend, made the card game work.
Then, with most bits needed for a card game already in place, he asked Claude to alter the existing code to implement a different card game. Understandably, it took much shorter. But it would also take much shorter if a human engineer did the same.
This is not true in my experience. Cranking out code is obviously the bottleneck, unless you have the luxury of working on a very narrow problem. The author describes a multi-modal project that does not afford this luxury.
As a much lower bar, I'd love it if more of the LLMs used for coding were actually multimodal, accepting images of games as part of the context. In general, LLMs are far better at generating web apps than they are at pure 2D or 3D games that use graphical APIs. There's far less training data, and there's no way to test anywhere close to what you can do with testing on a DOM. In an interactive game, with physics, animations and game logic, the AI just falls on its face because of the complexity.
> 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.
This is not true at all. I have never worked on games and it will take me quite a while (even months) to write a "basic" game. While I know a lot of good practices about software development and decade+ of FAANG experience, I don't know the intricacies or even the basics of game development.
I recently experienced this for a different usecase. As an experienced backend developer, I wanted to automate some javascript/browser stuff. I tried on my own for 2-3 days and had couple of prototypes but nothing actually worked. I spent 2 hours with an AI and I had a working solution. We even iterated together quickly and solved some runtime issues and the solution is working for me seamlessly now.
So, I definitely see value of AI even for coding for experienced developers like myself.
> neither can tell you if your game is actually fun
I think this is the core insight. An AI will not be able to experience a game (or anything else for that matter) remotely in the same way that a human can experience it. It might be able to guess, based on human rankings of other similar games. But AI will never be able to actually have fun playing your game.
This concept will define the workforce that comes out of this AI boom. Maybe an AI can write a document or code like a human, only based on past samples of similar behavior, but it won't be able to synthesize exactly what it means to be a human. The human element will still need to be traded on. Your value as a human cannot be replaced, you might just have to think differently about that value.
> 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.
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.
LLMs have the same value proposition as no-code or low-code tools, and they also have the same failure cases. With pre-AI no-code tools, they also lowered walls but they didn't remove the barriers. The experience was a lot like we're seeing from the "vibe coders", like this post here:
"what's the point of vibecoding if at the end of the day I still have to pay a dev to look at the code anyway... I can't vibe my way through debugging, I can't ship anything that actually matters." [1]
That was the experience a lot of people had using no/low code tools, where you could make progress, but as soon as you hit a problem you are done, because overcoming it will require skills the no/low code don't teach or really support.
LLMs are only different because the interface is more accessible. But all the same problems are still there. AI is not a panacea.
AI doing playtests is an idea I've been thinking about too. The question I can't quite answer is: how do you know the AI play-tester can predict what users find fun? How well does it represent the different kinds of users?
Depends on the game but absolutely we run thousand iterations of a game, but for balance. Which mechanics keep player engaged you need to get feedback from players
Is that the takeaway? When they say, "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", that doesn't really make it sound like a good heads-up comparison from which we could then say, "the coding part was not the most significant part of the problem".
I mean, the entire article is problematic as proof of anything. For starters, they didn't go through a design process for a game at all, they copied existing games. Then there are all these weird technical rabbit holes they went down that really weren't anywhere near "simplest path to MVP".
I just don't think there is anything to glean from this article. Like most posts about individual experiences with AI, it's functionally equivalent to, "I had a weird dream last night".
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.
That’s what a lot of people are missing about AI. You can do an exhaustive search which is effectively AGI. You already solved for a “solution” it’s simply a matter of searching for it. We are pretty close.
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.
Not only that but it was also their first game, meaning they faced a ton of unknown unknowns which are no longer there. If they were starting to program a card game today without LLMs they would still be able to apply all the knowledge and insights they gained from the previous experience; it would take significantly less than three months.
You don’t even need to clone it. I’ve re-created months long projects from scratch and next time around it takes me around 1/3 of the time of the last, ballpark.
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.
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.
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.
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.
> 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.
I disagree. Sure, it's hard, but it's much harder to come up with novel and fun gameplay ideas. Once you have the fun idea, it's just a matter of splitting the problem in bite-sized chunks and iterating.
There is no methodology when you are faced with the dreaded blank page problem and need to come up with something out of nothing. Maybe going for a walk helps. Maybe taking a heroic dose of drugs. Maybe trying a few different things and see what sticks. It's a problem that has existed for millennia in all creative endeavours; whereas coding is "just" engineering.
I've been learning game dev the past month, had to learn a ton of maths to do anything, which was still easier than the question "what kind of game do I want to make?" which is still, to this day, unanswered. No 3Blue1Brown video is gonna help here, unlike learning how to do vector maths and what the hell is a quaternion.
I largely agree with your point, but interestingly I’ve always found the ideas and blue sky thinking game design part the hardest personally. I can code nearly any game mechanic at this point, but struggle with the writing/creativity part of game development. If you find that easy, you should consider yourself rather blessed, it doesn’t come naturally to us all.
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
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 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.
Maybe that’s how we are supposed to work with current LLMs. Having a template or an example we understand is a big advantage. It can prevent LLM from many pitfalls, and more importantly we can easily review the output.
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.
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 part of this that always confuses me is like nobody's aware gamejams exist, this has been a thing long before the LLM craze and people have been producing decent games on very limited timespans already, but people are forgetting how insanely high the bar is now, LLMs do not even remotely begin to fix the problem of your competition being incredibly stiff.
Just look at something like ludum dare and all the top entries (out of thousands of games submitted) are all usually quite polished given the timespan.
As a Steam-based game developer, I am starting to use AI more and more in new projects for asset generation (images and text) as well as some help with code. Here are some of my ideas for why we haven't yet seen a huge increase in steam game releases due to AI:
1: Even with AI, it's a lot of work to make a full game. When most people think "I have a cool game idea", they're usually imagining something polished and non-trivial, possibly 3d. You could make a short text adventure in a few days with AI, or a very simplistic 2d game, but anything more ambitious (like 3d) is going to take a lot more effort.
2: Releasing on steam requires you to pay $100. I imagine this is a substantial deterrent for "3-day projects", unless you think it'll sell $100 worth.
3: There's more to game development than creating assets and writing code. The author of the article recreated an existing game, which sidesteps one of the most difficult parts of gamedev: design. Creating a compelling game is surprisingly difficult. Granted, you don't need a compelling game in order to release on steam, but I myself have made many prototypes over the years which I've abandoned because the idea just wasn't as interesting as I thought it would be.
4: I've made a few prototypes with AI assets, and one issue I frequently run into with image generation is: it still takes a fair amount of work to generate the same character in different poses, facial expressions, outfits, etc.
5: There is still considerable prejudice against using AI to make game assets. I think some people (myself included) are hesitant to release a game with lots of AI generated assets at the current moment, for fear of public backlash. Eventually that will calm down and it will become more socially acceptable to use AI to generate game assets.
I am bullish about AI improvement over the next decade, and I think we'll gradually see all of these issues resolve themselves as AI improves. But at the present moment, it's not quite as easy as the article makes it seem.
I've been "able" to make likely decent games for a number of years now. Code and 3D I could potentially have covered. That's no longer what scares me.
Having a good and semi unique idea, is a rare. If I had a great game mechanic idea, the rest would be trivial.
Say you do get a good game loop together that you feel will be successful. You will also now need to loop in art teams for artistic direction, music, character design, etc. A good game loop isnt enough, it needs to be presented in an equally interesting and unique way.
Finally, there is the risk. There is a massive time investment in making games, and you are catering to an audience that is not only accustomed to pirating but finds it morally righteous to steal your work. This is why app developers prefer to make iOS apps. The customers are accustomed to paying and have little interest in pirating.
post-launch and even before that, your job becomes paying and convincing streamers to play your game constantly in the HOPE people start to notice it.
All of this stress and work to hopefully just make an ok amount of money. I have so many excellent games in my steam library by indie devs that gave up after one or two very successful games. And I doubt it's because everything was going so well.
This is because LLMs are not good enough. Seriously, the bottle neck is still code, art, sound, etc.
There are a bunch of games made using heavy gen ai but it is usually for art and dialogue. Most players can tell quickly and drop the game. Games are fundamentally creative things and most interesting art work was not done in 5s with a prompt.
I think the reason is because you have to pay a non-negligible amount of money per game you publish, and most don't expect to make that back. In my case, making money wasn't my goal, as I explain in the article.
I’m sorry but the difficult part of making games isn’t the coding, it is making something that is appealing and enjoyable to play. An LLM isn’t going to help with that at all. How is it going to know if something is fun? That’s the real work.
Also the idea that a dev who could making a game in 24 hour would create something professional and polished in 3 days is a joke. The answer to “where are all the games” is simple: LLMs don’t actually make a huge impact on making a real game.
If they're like me, they finish something and then sit on it for a variety of anxiety inducing reasons. I've got a state chart library I'm sitting on that I'm quite hesitant to share...
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?
I'm curious about the necessity of introducing the 'backend' concept when making a game like this. Why bother wrapping a Go backend in WASM when you can implement it directly in JavaScript?
Dang it. And here I was thinking I was a genius for working on a game written in Go and served via wasm (mainly for saving on serving costs). Well I guess il put a positive spin on it and consider it vindication:)
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!
in this case, no. it's a client game and performance isn't at all critical, so the state and loop could be trivially handled by a regular js function. if at some point a server architecture was desired, it would be trivial to host that function on node.
my take: as a backend developer he was fixated with the idea of having a server no matter what (if your only tool is a hammer, everything looks like a nail), and as go was his main language he just went with that. then he figured out it didn't really have a point, but instead of just translating that simple logic to js he overengineered the whole thing and overcomplicated his design and build process by transpiling to wasm.
there are some bugs, though. i just won a couple of matches at escoba (very nice little game, i hadn't played this for ... decades!) and the game state wasn't properly reset for the next. that's probably the llm ...
The front end is still react. But I'd be curious to know if LLM's are less prone to errors generating code for strongly typed languages over others like Javascript.
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.
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.
Well said. And I’m sure there were people back in the day that said anyone coding in c instead of assembly didn’t truely understand the machine code and this could one day bite them in the ass.
AI is a tool and it’s clearer than ever to me now that the tool’s best job is abstracting tedious implementation details away from the developer, in much the same way that I never have to bother with manual memory management in my programs written in modern languages the way I once used to with c. We no longer need to deal with segfaults, so why not also no longer having to deal with tracking down documentation or examples to implement simple blocks of code.
Given that the slop factories are being propped up by governments around the world, and and pretty much the reason why the stock market is inflated to the point that it is right now, probably won't happen.
We as a species are going to have to collectively decide it's not acceptable.
The only reason I can think of is some sort of virtue signaling, like to promote one self. But even then why not spending ~6 months and super polish the game that would make you look like a rockstar? Eventually using ai in the process to learn where it can be useful... otherwise i don't understand
starchild3001|6 months ago
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.
zahlman|6 months ago
How is AI supposed to simulate a player, and why should it be able to determine what real people would find engaging?
marqueewinq|6 months ago
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.
kaiokendev|6 months ago
But we did? We've come a long way from the limited XBLA catalog. It didn't happen overnight, but doubtless we wouldn't have the volume of games we have today without Unity, Godot, Gamemaker, Renpy, RPG Maker...
zerr|6 months ago
raincole|6 months ago
We definitely saw an explosion of good indie games by around early half of 2010s. Whether it had anything to do with Unity is another moot point.
benreesman|6 months ago
And this isn't surprising: git-style revision control hit the scene almost 20 years ago, it was like 5 years until it was totally dialed in anywhere, another 5 before elite companies had it totally figured out, and its been slowely diffusing since, today its pretty figured out. And this is harder to use right than git.
I think it would go faster actually if every product release, every OSS tool, every god-damned blog post wasn't hell bent on saying "its done, its solved, old way cooked, new world arrived".
We're figuring it out and it takes time. That's OK.
If it was done, then we'd be drowning in great software. We're not, we're breaking even, which is impressive for a big new thing 1-2 years in.
pjmlp|6 months ago
nine_k|6 months ago
Doesn't look exactly that to me. The author built a server, studied React, built a frontend, made the card game work.
Then, with most bits needed for a card game already in place, he asked Claude to alter the existing code to implement a different card game. Understandably, it took much shorter. But it would also take much shorter if a human engineer did the same.
ants_everywhere|6 months ago
It can do this. From Atari games to StarCraft this has been a thing since before LLMs.
> surfacing which mechanics keep simulated players engaged
This it's unclear how to operationalize. Among other things, not all games appeal to all people.
nahnahno|6 months ago
danjl|6 months ago
hcnews|6 months ago
This is not true at all. I have never worked on games and it will take me quite a while (even months) to write a "basic" game. While I know a lot of good practices about software development and decade+ of FAANG experience, I don't know the intricacies or even the basics of game development.
I recently experienced this for a different usecase. As an experienced backend developer, I wanted to automate some javascript/browser stuff. I tried on my own for 2-3 days and had couple of prototypes but nothing actually worked. I spent 2 hours with an AI and I had a working solution. We even iterated together quickly and solved some runtime issues and the solution is working for me seamlessly now.
So, I definitely see value of AI even for coding for experienced developers like myself.
taftster|6 months ago
I think this is the core insight. An AI will not be able to experience a game (or anything else for that matter) remotely in the same way that a human can experience it. It might be able to guess, based on human rankings of other similar games. But AI will never be able to actually have fun playing your game.
This concept will define the workforce that comes out of this AI boom. Maybe an AI can write a document or code like a human, only based on past samples of similar behavior, but it won't be able to synthesize exactly what it means to be a human. The human element will still need to be traded on. Your value as a human cannot be replaced, you might just have to think differently about that value.
Cthulhu_|6 months ago
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.
miki123211|6 months ago
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.
ModernMech|6 months ago
LLMs are only different because the interface is more accessible. But all the same problems are still there. AI is not a panacea.
[1] https://www.reddit.com/r/ProgrammerHumor/comments/1mudy12/th...
unknown|6 months ago
[deleted]
potatoman22|6 months ago
chrz|6 months ago
nikolayasdf123|6 months ago
more like, more than 5 seconds.
moron4hire|6 months ago
I mean, the entire article is problematic as proof of anything. For starters, they didn't go through a design process for a game at all, they copied existing games. Then there are all these weird technical rabbit holes they went down that really weren't anywhere near "simplest path to MVP".
I just don't think there is anything to glean from this article. Like most posts about individual experiences with AI, it's functionally equivalent to, "I had a weird dream last night".
WA|6 months ago
lvl155|6 months ago
danjl|6 months ago
AIPedant|6 months ago
latexr|6 months ago
riazrizvi|6 months ago
sneak|6 months ago
[deleted]
fxtentacle|6 months ago
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.
zahlman|6 months ago
"Communication" within your own head is often also surprisingly difficult.
quantumHazer|6 months ago
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.
guywithahat|6 months ago
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
rustystump|6 months ago
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.
uncircle|6 months ago
I disagree. Sure, it's hard, but it's much harder to come up with novel and fun gameplay ideas. Once you have the fun idea, it's just a matter of splitting the problem in bite-sized chunks and iterating.
There is no methodology when you are faced with the dreaded blank page problem and need to come up with something out of nothing. Maybe going for a walk helps. Maybe taking a heroic dose of drugs. Maybe trying a few different things and see what sticks. It's a problem that has existed for millennia in all creative endeavours; whereas coding is "just" engineering.
I've been learning game dev the past month, had to learn a ton of maths to do anything, which was still easier than the question "what kind of game do I want to make?" which is still, to this day, unanswered. No 3Blue1Brown video is gonna help here, unlike learning how to do vector maths and what the hell is a quaternion.
jama211|6 months ago
DecoySalamander|6 months ago
kenoath69|6 months ago
Keyframe|6 months ago
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.
rsanek|6 months ago
singpolyma3|6 months ago
spicyusername|6 months ago
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.
sbinnee|6 months ago
jongjong|6 months ago
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.
deadbabe|6 months ago
Profan|6 months ago
Just look at something like ludum dare and all the top entries (out of thousands of games submitted) are all usually quite polished given the timespan.
sheepolog|6 months ago
1: Even with AI, it's a lot of work to make a full game. When most people think "I have a cool game idea", they're usually imagining something polished and non-trivial, possibly 3d. You could make a short text adventure in a few days with AI, or a very simplistic 2d game, but anything more ambitious (like 3d) is going to take a lot more effort.
2: Releasing on steam requires you to pay $100. I imagine this is a substantial deterrent for "3-day projects", unless you think it'll sell $100 worth.
3: There's more to game development than creating assets and writing code. The author of the article recreated an existing game, which sidesteps one of the most difficult parts of gamedev: design. Creating a compelling game is surprisingly difficult. Granted, you don't need a compelling game in order to release on steam, but I myself have made many prototypes over the years which I've abandoned because the idea just wasn't as interesting as I thought it would be.
4: I've made a few prototypes with AI assets, and one issue I frequently run into with image generation is: it still takes a fair amount of work to generate the same character in different poses, facial expressions, outfits, etc.
5: There is still considerable prejudice against using AI to make game assets. I think some people (myself included) are hesitant to release a game with lots of AI generated assets at the current moment, for fear of public backlash. Eventually that will calm down and it will become more socially acceptable to use AI to generate game assets.
I am bullish about AI improvement over the next decade, and I think we'll gradually see all of these issues resolve themselves as AI improves. But at the present moment, it's not quite as easy as the article makes it seem.
TechSquidTV|6 months ago
Having a good and semi unique idea, is a rare. If I had a great game mechanic idea, the rest would be trivial.
Say you do get a good game loop together that you feel will be successful. You will also now need to loop in art teams for artistic direction, music, character design, etc. A good game loop isnt enough, it needs to be presented in an equally interesting and unique way.
Finally, there is the risk. There is a massive time investment in making games, and you are catering to an audience that is not only accustomed to pirating but finds it morally righteous to steal your work. This is why app developers prefer to make iOS apps. The customers are accustomed to paying and have little interest in pirating.
post-launch and even before that, your job becomes paying and convincing streamers to play your game constantly in the HOPE people start to notice it.
All of this stress and work to hopefully just make an ok amount of money. I have so many excellent games in my steam library by indie devs that gave up after one or two very successful games. And I doubt it's because everything was going so well.
jayd16|6 months ago
hiAndrewQuinn|6 months ago
famouswaffles|6 months ago
https://steamdb.info/stats/releases/
zerr|6 months ago
Watching LLM generating the code doesn't help with producing the dopamine.
rustystump|6 months ago
There are a bunch of games made using heavy gen ai but it is usually for art and dialogue. Most players can tell quickly and drop the game. Games are fundamentally creative things and most interesting art work was not done in 5s with a prompt.
macleginn|6 months ago
qnleigh|6 months ago
Ekaros|6 months ago
All of these take time and many of them are iterative processes where you might not even know if it fits or is right before multiple tries.
maloga|6 months ago
mattbuilds|6 months ago
Also the idea that a dev who could making a game in 24 hour would create something professional and polished in 3 days is a joke. The answer to “where are all the games” is simple: LLMs don’t actually make a huge impact on making a real game.
all2|6 months ago
shortrounddev2|6 months ago
jama211|6 months ago
p0w3n3d|6 months ago
novoreorx|6 months ago
flashgordon|6 months ago
bitbasher|6 months ago
I eventually left Go and went to Rust for better WASM support... seems to get me a lot further!
empressplay|6 months ago
MangoToupe|6 months ago
kousthub|6 months ago
znort_|6 months ago
my take: as a backend developer he was fixated with the idea of having a server no matter what (if your only tool is a hammer, everything looks like a nail), and as go was his main language he just went with that. then he figured out it didn't really have a point, but instead of just translating that simple logic to js he overengineered the whole thing and overcomplicated his design and build process by transpiling to wasm.
there are some bugs, though. i just won a couple of matches at escoba (very nice little game, i hadn't played this for ... decades!) and the game state wasn't properly reset for the next. that's probably the llm ...
garbagepatch|6 months ago
duongital|6 months ago
zakki|6 months ago
afroboy|6 months ago
estimator7292|6 months ago
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.
jama211|6 months ago
AI is a tool and it’s clearer than ever to me now that the tool’s best job is abstracting tedious implementation details away from the developer, in much the same way that I never have to bother with manual memory management in my programs written in modern languages the way I once used to with c. We no longer need to deal with segfaults, so why not also no longer having to deal with tracking down documentation or examples to implement simple blocks of code.
ozgrakkurt|6 months ago
DrThomasAger|6 months ago
Halian|6 months ago
platevoltage|6 months ago
We as a species are going to have to collectively decide it's not acceptable.
bgwalter|6 months ago
[deleted]
youtubeuser|6 months ago
hollowturtle|6 months ago
[deleted]
epolanski|6 months ago
Because if you have nothing, let me remind you that talk is cheap.
jama211|6 months ago
hollowturtle|6 months ago
reactordev|6 months ago
Other than that. Loved the article and I love making games (haven’t shipped one in a while, I should)
reactordev|6 months ago
It’s literally a one-liner of go to create an http server, http.FileServer that points to a directory.
You shouldn’t have to use npx when the tool at hand is perfectly capable.