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?
Game companies already collect heaps of data about players, which mechanics they interact with, which mechanics they don't, retention, play time, etc.
I don't think it's much of a stretch to take this data over multiple games, versions, and genres, and train a model to take in a set of mechanics, stats, or even video and audio to rate the different aspects of a game prototype.
I wouldn't even be surprised if I heard this is already being done somewhere.
> How is AI supposed to simulate a player, and why should it be able to determine what real people would find engaging?
Games have goals, and players are prone to 'optimising the fun out of games', by doing some save strategy over and over again to reach that goal, even if it's not fun. Think eg grinding in an RPG, instead of facing tough battles with strategy and wits and the risk of failure.
Even if AIs are terrible at determining what's engaging, you can probably at least use them to relatively quickly find ways that you accidentally opened that let players get in the way of their own fun.
I've heard several talks about how some companies make AI systems that are designed to play as similar to human players as possible. This has been crucial for them in order to play-test levels in order to balance the game.
And note, this is not AI as in asking an LLM what to do, this is more classical machine learning and deep learning.
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.
> 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
Sure there's off the shelf implementations.
Off the top of my head I would suggest starting with evaluating godot 4.
They have isometric view, pathfinding, and all of the rest you are mentioning.
> 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...
> we didn’t see a proportional explosion of good game, just more attempts.
I'm not sure the 2 of you are disagreeing. We definitely saw an explosion of indie games. In 2010, there were less than 10 indie games released on steam per month. By 2022, there were ~500/mo, and today there's ~750/mo (I expect that the 250/mo jump around 2022 can likely be attributed to LLMs).
What's hard to say is if this increase significantly increased the number of good games. Mostly because "good" is highly subjective, but also, I think something else happens. I've been playing games for the better part of 40 years, and what I noticed, is that in that time, the number of must play games each year has largely gone unchanged, despite the industry being orders of magnitude larger than it was 40 years ago. But that is also tricky, because 2 things happen every year, our standards get higher, and our preferences get more refined.
As someone reaching 50 years old, we always had such indies, we used to call them bedroom coders, and distributions came in tapes, floppies in magazine covers, shareware CD-ROM and DVD-ROMs.
Maybe it only got visible to the consoles generation around the time of XBLA arcade, and even that was already predated by PS Yaroze and PS2Linux efforts.
Before Unity, we had SDL, Ogre3D, SFML,... but naturally all of those require more coding skills than engines designed with UI workflows in mind.
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.
Ive never once successfully gotten a usable sprite sheet out of ChatGPT. The concept seems foreign to it and no matter how hard I try to steer it it’ll find a way to do something hopeless (inconsistent frame sizes; incoherent animations; no sense of consistent pixel sizes or what distinguishes (say) 8-bit from 16-bit era sprites; it’ll draw graph paper in the background for some reason; etc etc.). If anyone has a set of magic prompts for this, I’d love to learn about it. But my suspicion is that it’s just fundamentally the wrong tool for the job — you probably need a purpose-built model.
Unless you're using a model that was built for pixel art, you will never get a usable piece of pixel art out of a model using a diffusion based image generator because it does not understand what a pixel is. You'll always get pixels bleeding into the others, shitty outlines, and nonsensical AA. They simply do not understand the medium.
I've seen people make finetunes for character turnarounds, there's probably one for 2D pixel art in particular, or perhaps combining such a finetune with a pixel art finetune would work.
It looks like retrodiffusion.ai in particular has something close.
Maybe AI games can use AI-first art styles. If I ask a camera to create an André Derain painting then it will fail. But that's my fault for misunderstanding the medium.
A bunch of ideas that had been tabled because of the difficulty of implementation were released once the difficulty of making a 3D world was somehow alleviated by Unity.
Maybe something else is currently holding back another bunch of good ideas in gaming. Once another threshold gets lowered, we will see another wave of good games enabled by by that, and a return to the average rate of creation again.
I think change in curation model especially with Steam had lot to do with it. Opening marketplace for more products will allow more of them to be sold.
even indie games are painstackingly hard to develop, don't make the mistake of associating indie with easy, rather harder i'd say if you go solo or with a few others in a very high risk job
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.
This true - and git was not a moving target. AI core tech has certainly slowed down but still moving fast enough to make hard won lessons worthless and investing in learning them questionable.
> 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.
Unless you're also writing your own graphics and game engine from scratch, if you're making a truly novel and balanced game, then it should not be possible to crank out code with AI. When working in engines, the bulk of the work is usually in gameplay programming so the fact that its code is so predictable should be concerning (unless the programming is effectively in natural language). Not spending most of your time testing introduced mechanics, re-balancing and iterating should be triggering alarm bells. If you're working on an RPG, narrative design, reactivity and writing will eat up most of your time.
In the case you're working as part of team large enough to have dedicated programmers, the majority of the roles will usually be in content creation, design and QA.
And it’s absolutely true in my experience, coding was never the bottleneck (modulo advanced shader programming which LLMs still aren’t great at despite my best efforts)
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.
I realize this isn't the same thing as your point about images as part of training data, but just flagging it in case anyone isn't aware: Claude Code lets you copy and paste images into terminal. I've been designing a "universal history simulator" game for use in my history classes lately, and it is really helpful to be able to make a mockup of a ui change I want and then paste it in, rather than trying to explain it verbally. Also good for debugging graphics issues.
> 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.
I don't know I feel like rewriting a backend for one card game into a backend for another wouldn't be that difficult, especially for the original dev. Once you've worked out how to represent cards and code the rules you're basically there for any card game.
Also, a refactor is by definition rewriting code without changing the behaviour. Worth knowing the difference.
As an LLM hater, I have to say, this is exactly the use case I want code generation for. If I need to figure out the problem as I develop, which is the case for new code, the model can kindly get out of my way. But if I have already written a bunch of code and I can explain the problem with the understanding that I've gained from my implementation and have the bot redo the grunt work? fine with me..
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 understand the “writers block” but once you do have a vision or idea, it is incredibly hard to bring it into reality. Much like building a product you have to cut and cut and cut due to time/skill/money constraints. I think many people get hung up on “originality” part too much.
Most of the comments lamenting the idea stage come from those who have not pushed past that. Once you do have an idea, a vision, that is when the real work begins. It is also the most difficult. For every completed game no matter how bad, there is a graveyard of thousands of incomplete projects that no one sees. People vastly underestimate the effort it takes to make a complete game.
If you do struggle with, “what kind of game”, go play games. Alot of games. Write about the games. Between the likes and didnt likes, is the kind of game only you can make.
>but it's much harder to come up with novel and fun gameplay ideas
I'm going to give an analogy to fiction writing. You ever notice how seemingly everyone has an idea for a story, but shockingly few of them ever execute on their ideas? Why is that?
Well, it's because the ideation stage is the easiest fucking part of writing a book! Sitting down to turn that idea into reality is a process that takes months/years. It requires a lot of concentrated effort, and a willingness to deal with the fact that your writing skills (probably) suck.
It's the same with video games. Probably more so, because the medium is much less restrictive than fiction writing.
Also, quick tangent on the topic of "novel" gameplay ideas--if you listen to successful creatives, some common advice they give is that focusing on being original is a noob trap. Ideas are cheap in the arts, and most things have already been done. It's the execution that matters, which ties back in to my point above.
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.
People build up too great of expectations when the topic of “creativity” comes in. Nothing is new under the sun.
Also, i press “x” to doubt you can build any game mechanic not because i have no doubt you are a talented engineer but because the domain is really that vast. Multiplayer netcode is a prime example and why I used an idea which had a multiplayer component that was realtime.
Ideas are cheap. Making them real is not. It is why engineers get paid so well.
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.
Readit News
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.
How is AI supposed to simulate a player, and why should it be able to determine what real people would find engaging?
I don't think it's much of a stretch to take this data over multiple games, versions, and genres, and train a model to take in a set of mechanics, stats, or even video and audio to rate the different aspects of a game prototype.
I wouldn't even be surprised if I heard this is already being done somewhere.
Games have goals, and players are prone to 'optimising the fun out of games', by doing some save strategy over and over again to reach that goal, even if it's not fun. Think eg grinding in an RPG, instead of facing tough battles with strategy and wits and the risk of failure.
Even if AIs are terrible at determining what's engaging, you can probably at least use them to relatively quickly find ways that you accidentally opened that let players get in the way of their own fun.
And note, this is not AI as in asking an LLM what to do, this is more classical machine learning and deep learning.
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.
Sure there's off the shelf implementations.
Off the top of my head I would suggest starting with evaluating godot 4.
They have isometric view, pathfinding, and all of the rest you are mentioning.
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...
I'm not sure the 2 of you are disagreeing. We definitely saw an explosion of indie games. In 2010, there were less than 10 indie games released on steam per month. By 2022, there were ~500/mo, and today there's ~750/mo (I expect that the 250/mo jump around 2022 can likely be attributed to LLMs).
What's hard to say is if this increase significantly increased the number of good games. Mostly because "good" is highly subjective, but also, I think something else happens. I've been playing games for the better part of 40 years, and what I noticed, is that in that time, the number of must play games each year has largely gone unchanged, despite the industry being orders of magnitude larger than it was 40 years ago. But that is also tricky, because 2 things happen every year, our standards get higher, and our preferences get more refined.
https://steamdb.info/stats/releases/?tagid=492
Maybe it only got visible to the consoles generation around the time of XBLA arcade, and even that was already predated by PS Yaroze and PS2Linux efforts.
Before Unity, we had SDL, Ogre3D, SFML,... but naturally all of those require more coding skills than engines designed with UI workflows in mind.
It looks like retrodiffusion.ai in particular has something close.
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.
Maybe something else is currently holding back another bunch of good ideas in gaming. Once another threshold gets lowered, we will see another wave of good games enabled by by that, and a return to the average rate of creation again.
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.
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.
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.
AI is insane. It can do like 10,000 actions per second lol
https://youtu.be/0p34y7X0VCM?si=GSAjOyRmK6kNmYdx
In the case you're working as part of team large enough to have dedicated programmers, the majority of the roles will usually be in content creation, design and QA.
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.
You're contradicting yourself. I promise it wouldn't take you months, unless you're just a really bad developer.
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.
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.
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 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...
Deleted Comment
more like, more than 5 seconds.
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".
Also, a refactor is by definition rewriting code without changing the behaviour. Worth knowing the difference.
Dead Comment
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.
"Communication" within your own head is often also surprisingly difficult.
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.
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
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.
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.
Most of the comments lamenting the idea stage come from those who have not pushed past that. Once you do have an idea, a vision, that is when the real work begins. It is also the most difficult. For every completed game no matter how bad, there is a graveyard of thousands of incomplete projects that no one sees. People vastly underestimate the effort it takes to make a complete game.
If you do struggle with, “what kind of game”, go play games. Alot of games. Write about the games. Between the likes and didnt likes, is the kind of game only you can make.
I'm going to give an analogy to fiction writing. You ever notice how seemingly everyone has an idea for a story, but shockingly few of them ever execute on their ideas? Why is that?
Well, it's because the ideation stage is the easiest fucking part of writing a book! Sitting down to turn that idea into reality is a process that takes months/years. It requires a lot of concentrated effort, and a willingness to deal with the fact that your writing skills (probably) suck.
It's the same with video games. Probably more so, because the medium is much less restrictive than fiction writing.
Also, quick tangent on the topic of "novel" gameplay ideas--if you listen to successful creatives, some common advice they give is that focusing on being original is a noob trap. Ideas are cheap in the arts, and most things have already been done. It's the execution that matters, which ties back in to my point above.
Also, i press “x” to doubt you can build any game mechanic not because i have no doubt you are a talented engineer but because the domain is really that vast. Multiplayer netcode is a prime example and why I used an idea which had a multiplayer component that was realtime.
Ideas are cheap. Making them real is not. It is why engineers get paid so well.
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.