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.
> Game companies already collect heaps of data about players, which mechanics they interact with, which mechanics they don't, retention, play time, etc.
Yes, that's how games like Concord get made. Very successful approach to create art based on data about what's popular and focus groups.
I think you are saying data is no substitute for vision in design. Completely agree! At Playdom (Disney) they tried to build a game once from the ground up based on A/B testing. Do you know what that game was? No you don't because it was never released and terrible.
I think what the previous comment meant was that there is data on how player play, and that tends to be varied but more predictable.
Yah. I think an AI playtester that could go "hey... this itch that lots of players seem to have doesn't get scratched often in your main gameplay loop" or "there's a valley 1/3rd of the way into the game where progression slows way down" or "that third boss is way too hard".
AI/fuzzers can't get far enough in games, yet, without a lot of help. But I think that's because we don't have models really well suited for them.
Data is the lifeblood of mobile gaming, everything is data-driven.
Everything is measured and analysed and optimised for engagement and monetisation.
When you have 200 people making a game, "luck" or "art" doesn't factor in at all. You test, get data, and make decisions based on the data, not feelings.
Solo devs can still make artsy games and stumble upon success.
I think it was a sarcastic example - in other words, all the data and metrics and trend-chasing in the world is not a replacement for human vision, creativity, and risk-taking.
Was Concord made the way it was because of data? I got the impression that the designers were chasing misguided trends with the art direction, and on top of that the game part was just mediocre.
I can't say for sure (never played it or followed it much, because it's not my type of game) but the impression I had is that it was a cookie-cutter attempt to be just another live service online shooter in the vein of Valorant, Overwatch, Apex Legends, etc etc. And people saw no need to play this new one when those games already exist.
Compare that to Helldivers 2 (online-only live service game, same platforms and publisher) which had a lot of personality (the heavy Starship Troopers movie vibe) and some unique gameplay elements like the strategems.
To add, Concord had been in development for eight years at that point, had multiple leadership and direction changes, and then the studio was aquired by Sony because they wanted more big live service games and this game ticked all the boxes and was nearly done. So more money was pumped into it.
And sometimes it works; Apex Legends came out of nowhere and became one of the big live service titles. Fortnite did a battle royale mode out of nowhere and became huge.
Yeah there's no way Microsoft isn't already using all their aggregate metrics (trillions of data points I'm sure) from their first-party studios and making a "What good looks like" training set..
Whether that set is actually useful is a separate issue but someone is trying this over there for sure.
We did that on a game I worked on over ten years ago. It was a mobile game and we knew that it was very important to player retention (and interest in multiplayer) to have the first multiplayer interaction be "fun". So we would simulate the first person you played against as though they were another human. Based on play data of other humans. Because you only played them once you didn't think you were playing a bot.
Where we used AI (machine learning, not LLM) was in terms trying to figure out what kind of human you would want to play with. We also used machine learning to try figure out what cohort of players you were in so we could tweak engagement.
Where LLMs could really shine, in my opinion: Gamers love to play people, not AI (now). People are unpredictable, they communicate, they play well but in ways a human could (like they don't have superhuman reflexes or speed). You can play all kinds of games against AI (StarCraft, Civilization, training of all kinds of FPS) but it isn't fun for long because you see the robotic patterns. However, an LLM might be able to mix it up like humans, talk to you, and you could probably make it have imperfect reaction time, coordination, etc. That would really help a lot of games that have lulls in human player activity, or too much toxicity.
I would be shocked if some games aren't doing this now. It seems like it still be hard to make a bot seem human, and it probably only works if you sprinkle it in.
Humans prefer humans over bots in multiplayer. Even if you dumb down LLM-powered-bots, there's no sense of accomplishment on beating a bot that can be dialed up-or-down. And the social aspect... maybe some amount of gamers want to talk to bots instead of humans in a pvp match. Curious on the numbers there.
Ah yes, the huge game companies, definitely outfits I would associate with producing fun games I haven't seen before and not churning out Existing Franchise N+1 every year with barely perceptible differences and higher prices each iteration.
When you tweak game mechanics several times every day, keeping the tests useful is a large task. Basics can be tested. Map integrity can be tested. Most "normal UX" is hard to test, and even main functional tests tend to drift. (Source: a short involvement in actual gamedev recently.)
One can still write unit tests. I have been told from a couple different game devs that it's more because of release deadlines, and the cost of a bug is usually pretty small.
There are some game systems that lend themselves to unit testing, like say map generation to ensure that the expected landmarks are placed reasonably, or rooms are connected, or whatever. But most game interactions are just not easily "unit testable" since they happen across frames (eg over time). How would you unit test an enemy that spawns, moves towards the player, and attacks?
I'm sure you could conjure up any number of ways to do that, but they won't be trivial, and maintaining those tests while you iterate will only slow you down. And what's the point? Even if the unit-move-and-attack test passes, it's not going to tell you if it looks good, or if it's fun.
Ultimately you just have to play the game, constantly, to make sure the interactions are fun and working as you expect.
It would depend on how things are architected, but you could definitely test the components of your example in isolation (e.g. spawn test, get the movement vector in response to an enemy within a certain proximity, test that the state is set to attacking, whatever that looks like). I don't disagree that it's a hard problem. I run into similar issues with systems that use ML as some part of their core, and I've never come up with a satisfying solution. My strategy these days is to test the things that it makes sense to test, and accept that for some things (especially dynamic behavior of the system) you just have to use it and test it that way.
> How would you unit test an enemy that spawns, moves towards the player, and attacks?
You can easily write a 'simulation' version of your event loop and dependency inject that. Once time can be simulated, any deterministic interaction can be unit tested.
Which is all the same as what unit test was originally defined as.
You're right that "unit test" has taken on another, rather bizarre definition in the intervening years that doesn't reflect any kind of tests anyone actually writes in the real world, save where they are trying to write "unit tests" specifically to please the bizarre definition, but anyone concerned about definitional purity enough to quibble about it will use the original definition anyway...
I've heard the same excuses from ML engineers before introducing tests there, embedded engineers, robotics engineers, systems engineers, everyone has a reason.
The real reason? It's because writing tests is a different skill and they don't actually know how to do it.
Oh that's crap. I've been a software engineer for over 30 years. I love tests - I preach testing at my current place of work. I've also worked in games for about a decade. Testing in games is... not useless, but very much less useful than it is in general software engineering.
The problem with tests for games is that a lot of game code is in constant flux. A test suite introduces a not insignificant amount of rigidity to your codebase. Pivot a few concepts and you have dozens of tests to fix - or just invalidate entirely.
Very basic stuff that won't ever change can be tested - like whether the renderer is working properly - but that's never where the difficulty in game dev lies and its the stuff usually handled by a third party - library or engine.
> The problem with tests for games is that a lot of game code is in constant flux. A test suite introduces a not insignificant amount of rigidity to your codebase. Pivot a few concepts and you have dozens of tests to fix - or just invalidate entirely.
Sounds very much like the description of a big ball of mud.
An interesting gamedev video I saw recently basically boiled down to: "Build systems, not games." It was aimed at indie devs to help with the issue of always chasing new projects and making code that's modular enough to be able to reuse it.
But taking a step back, that very much feels like it should apply to entire games, where you should have boundaries between the components and so that the scope of any such pivot is managed well enough not to tank your velocity.
Other than that, it'd be just the regular growing pains of TDD or even just needing to manage good test coverage - saying that tests will eventually need changes isn't the best argument against them in webdev, nor should it be anywhere else.
> Sounds very much like the description of a big ball of mud.
I mean, yeah, kinda.
For any given object in the game world, it's funnest for that object to be able to interact with as many other objects as possible in as many ways as possible. A game object's handles for interaction need to be globally available and can't impose many invariants—especially if you don't want level designers to have to be constantly re-architecting the engine code to punch new holes for themselves in the API. Thus, a lot of the logic in a given level tends to live inside the callback hooks of level objects, and tends to depend on the state of the rest of the level for correctness.
Modularity is a property of high cohesion and low coupling, which are themselves only possible when you can pin down your design and hide information behind abstraction boundaries. But games are a flexible and dynamic enough field that engines have to basically let designers do whatever they want, whenever they want in order for the engine to be able to build arbitrary games. So game design is naturally a highly-coupled, incohesive problem space that is poorly suited to unit testing.
Of course, in their case it can actually be justified, because the game itself is very dependent on the logic working correctly, rather than your typical FPS game slop that just needs to look good.
Yeah I suspect Factorio's "complex game logic + simple(ish) 2d engine + minimal team structure" situation meant that the usual tradeoffs didn't apply. It's really cool that they pulled it off, though—I can't imagine it was easy, even then.
As a counter example I found this video essay about fixing a factorio bug fascinating. My main takeaway, I need better introspection hooks. I am not really programmer and I never really thought automated testing of user interactive parts was possible.
> 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.
Sure they do -- but once you introduce at least one custom component (i.e. hexagon map), it's actually not straightforward, how to integrate it with the rest of the controls.
I can't say whether it's me who's stupid, or it's just not very easy to make good UI in game engines. I don't say that's not doable of course -- i'm just saying one would need to invest quite a bit of time to work out how to do this.
> 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.
You also still have the same amount of time you had 40 years ago. There are definitely more games available, and I would argue the proportion of high quality games has also increased massively, but since you're still limited by the number of games you can play in any given year, you'll never feel that increase.
Why would the proportion of high quality games increase? The number yes, but I expect not the proportion. Lowering the entry barrier means more people who have spent less time honing their skills can release something that's lacking in polish, narrative design, fun mechanics and balance. Among new entrants, they should number more than those already able to make a fun game. Not a value judgement, just an observation.
Think of the negative reputation the Unity engine gained among gamers, even though a lot of excellent games and even performant games (DSP) have been made with it.
More competitors does also raise the bar required for novelty, so it is possible that standards are also rising in parallel.
We had shovelware games 25+ years ago (and probably 40 years ago, though I suspect the lack of microcomputers limited that). There were bargain-bin selections (literally bins full of CDs) that cost a few bucks and were utterly shite. I suspect the target audience was tech-unaware relatives who would be "little Johnny likes video games, I'll get him one of these...". Most of them were bad takes on popular games of the time.
Unity + Steam just makes this process a bit easier and more streamlined. I think the new thing is that as well as the dickwads who are trying to rip people off, there are well-intentioned newbie or indie developers releasing their unpolished attempts. These folks couldn't publish their work in the old days, because making CDs costs money, while now they can.
Looking at shareware days and games like Jazz Jackrabbit with team of 2-3 devs also. I don't know if Unity would have been necessary. Ofc, after 20 years there is lot more processing power and lot less memory constraints. But still, I am not sure if such engines fundamentally changed anything.
It'd be quite difficult to deploy the processing power and other resources without an engine.
A 90s PC can't do a complex 3d engine because it lacks the grunt. A 2020s game dev can't do a complex 3d engine themselves because they don't know how to do complex 3d.
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.
Like a full sprite sheet, one sprite at a time or a sprite animation loop?
Each one would require a different kind of model and model technique to make, so I wouldn't be surprised that ChatGPT has issues with it. A sprite animation loop would be better done by a potentially specialized video-oriented model, for example, and the current image and video models are barely trained on that kind of video data.
that might be possible by asking it to create an 3d model with animations (based on a template) and then capture the sprites. but then again, not sure if building it would be worthwhile because 1) openai might add that as a native product (like what happened with .ppt generation) or 2) the capability to do so might be 6 months away
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
I don't think the post you replied to says otherwise, but Unity meant there was now a path with professional grade tools without spending a fortune. It definitely did create a new wave of indie games, some of them amazing.
> 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 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.
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.
I mean it's a simple fact that the baseline for creating a game, roughly using the average developer experience/capability, is not months. Making a _good_ game might take months, it often takes years.
And that's the part AI is not going to be able to help you with.
Making a good boardgame, with zero need for programming, excluding artwork, is months or years of work. I would expect that much at a minimum for a (good) simple digital game, unless it is just going to sell on graphics and marketing alone (or luck).
Maybe you are a games developer and are overlooking the fact that people have to first learn the basic apis/models/etc. of graphical systems, engines, etc. before using them. Not sure how you are saying that it wouldn't take a few weeks to code even a simple production game like chess or more complicated but still simple Jump king etc.
Just think of the speciality in which you aren't an expert, javascript/storage/networking ...
> 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.
> 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.
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.
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..
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.
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.
Hah. Obviously there’s probably something I can’t make but I mean it’s by far not the bottleneck for me. And funny you should say, because my last job was actually building peer to peer multiplayer netcode with fully deterministic rollback for a video game. It was hard and took years but we did it.
I think you keep saying “ideas are easy” (for you) and insisting therefore they’re easy for everyone else. They’re really not, good ideas anyway.
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.
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?
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.
> are all usually quite polished given the timespan
The open secret is that they might not start coding or building assets until the start time, but they have spent a lot of time thinking about the ideas before then (even when the "theme" isn't known before hand people tend to make ideas fit theme with tweaks), which just speaks to the "code is not the bottleneck" thesis.
Game jams typically require games to adhere to a theme that is only known the day of, and the best entries will make a game specifically around that, not just adapt some pre-existing idea to it.
The themes are so open ended it’s very easy to adapt most game ideas. Games that win tend to be the most fun to play not necessarily the ones that fit the theme the best.
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.
> 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.
This is mostly from artists themselves. Most people are ok with even fully generated content if it's fun and interesting. Anyway, solo developer cannot afford even single artist, musician, writer.
That's where LLM helps. I recently tried GPT5 for story telling. Gave it a single image (in a bar, women, man, and a gun) and asked for a short story. Then asked for the next part 6 times. Every time at the end for illustration. The result was consistent and readable. Images generated had even similar faces. Remember, that was a problem with earlier models. I'm sure this will be used fill Amazon's bookshelves.
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.
>Still seems to be roughly following the pre-AI trajectory though.
Not really. The jump from 2023 to 2024 is bigger than the jump from 2019-2022 in raw numbers and 2020-2022 in %. So the jump of 3 to 4 years happened in a single year.
But as of August 2025, we are on pace to see fewer games in 2025 than in 2024.
Also the jump in 2024 is only around 10-15% more games than we would have expected from the previous trend. Assuming all of that is directly down to AI, I wouldn’t call that an explosion.
From what I’ve seen, most of the growth was in NSFW shovelware and was just people noticing a business opportunity. This also explains why the number it takes in 2025 isn’t showing similar growth.
>Also the jump in 2024 is only around 10-15% more games than we would have expected from the previous trend. Assuming all of that is directly down to AI, I wouldn’t call that an explosion.
How many games do you imagine can be released per day even with the help of current Sota LLMs ? Nevermind the fact that you have to pay $100 to distribute your game on Steam. You're not making a game you'd pay $100 to distribute in 3 days, LLM help or not.
>How many games do you imagine can be released per day even with the help of current Sota LLMs ?
Given the number of people who want to make games—if code is the bottleneck, and LLMs can really make you hugely more productive, I’d expect to see an actual explosion.
My experience is that neither of those assumptions are true though.
Games dev at my alma mater was split into two courses, bachelor of science (which focused on the technical side) and bachelor of arts which focused on 3d modelling, animation, concept art, etc.
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.
You may as well buy a shooter game starter pack or whatever that can save you >1year of coding, no llm needed.
Code is not a hard part.
Making mechanics fun and good assets is what is hard and takes forever.
Sure you can use llm to write a generic game, but its easier to find same game on github and just use that code, why would you write it again with llm.
If it's identical, you made a clone. If it's evenly slightly different, the design needs to be rethought. In a good game, the mechanics, assets, and game loop harmonize. Change one piece, and the balance shifts.
Wargroove copied almost everything from advance wars and put it in a fantasy setting, yet it sold much more than most indie games. Copying most values and mechanics from another game wont make a massive hit but it doesn't sell nothing, people who like the mechanics a lot will buy it to play with them some more in a new game.
If you copy a nintendo-platform game which hasnt gotten any love in a long time, put effort into it, and sell it on PC, then yes, you can sell a lot. Harvest Moon hasn't had a good game in over a decade, which is why Stardew Valley was so successful. Similarly, Pokemon has been neglected for generations and there have been a few successful games in the genre, like coromon.
But if you mean copying an already successful PC game with AI Slop assets and putting absolutely no thought into what makes the game good, then you probably should work in a field you actually care about instead
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.
This is almost on the money. Making something fun often requires coding, art, sound etc to bring the fun out. So in fact coding is the difficult part, along with all the other stuff needed for something to be fun. Imo tooling like ue blueprints and visual scripting is in the coding bucket.
I’m not saying coding is easy, but when it comes to games it is the easy part. Lots of people can code, very few can make something actually fun. Knowing how to code (or how to use an engine/blueprints/visual scripting) is just the start. It’s like making films. Everyone can record some videos on their phone, but it takes much more than that to make something people want to watch.
That analogy is more accurate for LLM vibe coding than real programming which i think proves my point. Not everyone can code. Actually code. Ideas are bountiful compared to the required skill to bring them into reality.
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...
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.
From experience: A static type system is MUCH better for agents than dynamic. I've done a few projects both ways - the agent is just much, much better with the static system because it sees compile errors right away, and also has access to better static analysis tools. I don't know how much the types themselves help the LLM, it's better context but more tokens, but the agent seeing errors is just a huge difference.
It's also much easier for you as a developer to digest the code if you need to refactor because you got lazy and accepted some slop.
In my experience, a massive YES. At least with agenetic models that have an iteration loop, and in languages like Rust where the type system is strong enough to prevent categories of bugs.
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.
Why write 27 lines of Go (not one line) when you can do
python -m http.server
And still it is a silly argument because using npx is still less effort than having to write those 27 lines when zero will do. Sure, you dislike Javascript, do whatever you want. No need for pointless pedantry.
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.
> Game companies already collect heaps of data about players, which mechanics they interact with, which mechanics they don't, retention, play time, etc.
Yes, that's how games like Concord get made. Very successful approach to create art based on data about what's popular and focus groups.
I think you are saying data is no substitute for vision in design. Completely agree! At Playdom (Disney) they tried to build a game once from the ground up based on A/B testing. Do you know what that game was? No you don't because it was never released and terrible.
I think what the previous comment meant was that there is data on how player play, and that tends to be varied but more predictable.
Yah. I think an AI playtester that could go "hey... this itch that lots of players seem to have doesn't get scratched often in your main gameplay loop" or "there's a valley 1/3rd of the way into the game where progression slows way down" or "that third boss is way too hard".
AI/fuzzers can't get far enough in games, yet, without a lot of help. But I think that's because we don't have models really well suited for them.
Data is the lifeblood of mobile gaming, everything is data-driven.
Everything is measured and analysed and optimised for engagement and monetisation.
When you have 200 people making a game, "luck" or "art" doesn't factor in at all. You test, get data, and make decisions based on the data, not feelings.
Solo devs can still make artsy games and stumble upon success.
Isn't Concord massively unpopular? I'd think that's a terrible example
Edit: yup, it shut down nearly a year ago
I think it was a sarcastic example - in other words, all the data and metrics and trend-chasing in the world is not a replacement for human vision, creativity, and risk-taking.
Was Concord made the way it was because of data? I got the impression that the designers were chasing misguided trends with the art direction, and on top of that the game part was just mediocre.
I can't say for sure (never played it or followed it much, because it's not my type of game) but the impression I had is that it was a cookie-cutter attempt to be just another live service online shooter in the vein of Valorant, Overwatch, Apex Legends, etc etc. And people saw no need to play this new one when those games already exist.
Compare that to Helldivers 2 (online-only live service game, same platforms and publisher) which had a lot of personality (the heavy Starship Troopers movie vibe) and some unique gameplay elements like the strategems.
To add, Concord had been in development for eight years at that point, had multiple leadership and direction changes, and then the studio was aquired by Sony because they wanted more big live service games and this game ticked all the boxes and was nearly done. So more money was pumped into it.
And sometimes it works; Apex Legends came out of nowhere and became one of the big live service titles. Fortnite did a battle royale mode out of nowhere and became huge.
Yeah there's no way Microsoft isn't already using all their aggregate metrics (trillions of data points I'm sure) from their first-party studios and making a "What good looks like" training set..
Whether that set is actually useful is a separate issue but someone is trying this over there for sure.
We did that on a game I worked on over ten years ago. It was a mobile game and we knew that it was very important to player retention (and interest in multiplayer) to have the first multiplayer interaction be "fun". So we would simulate the first person you played against as though they were another human. Based on play data of other humans. Because you only played them once you didn't think you were playing a bot.
Where we used AI (machine learning, not LLM) was in terms trying to figure out what kind of human you would want to play with. We also used machine learning to try figure out what cohort of players you were in so we could tweak engagement.
Where LLMs could really shine, in my opinion: Gamers love to play people, not AI (now). People are unpredictable, they communicate, they play well but in ways a human could (like they don't have superhuman reflexes or speed). You can play all kinds of games against AI (StarCraft, Civilization, training of all kinds of FPS) but it isn't fun for long because you see the robotic patterns. However, an LLM might be able to mix it up like humans, talk to you, and you could probably make it have imperfect reaction time, coordination, etc. That would really help a lot of games that have lulls in human player activity, or too much toxicity.
I would be shocked if some games aren't doing this now. It seems like it still be hard to make a bot seem human, and it probably only works if you sprinkle it in.
Humans prefer humans over bots in multiplayer. Even if you dumb down LLM-powered-bots, there's no sense of accomplishment on beating a bot that can be dialed up-or-down. And the social aspect... maybe some amount of gamers want to talk to bots instead of humans in a pvp match. Curious on the numbers there.
Could never prove it, but would bet money that Marvel Snap for example is doing it right now.
Edit : oh yeah. A quick google search proved it : https://marvelsnapzone.com/bots/
Ah yes, the huge game companies, definitely outfits I would associate with producing fun games I haven't seen before and not churning out Existing Franchise N+1 every year with barely perceptible differences and higher prices each iteration.
Maybe "fun" isn't the right word, "engaging" or "addicting" is probably what they use internally.
Game developers will try anything before they actually write automated tests for their games.
When you tweak game mechanics several times every day, keeping the tests useful is a large task. Basics can be tested. Map integrity can be tested. Most "normal UX" is hard to test, and even main functional tests tend to drift. (Source: a short involvement in actual gamedev recently.)
One can still write unit tests. I have been told from a couple different game devs that it's more because of release deadlines, and the cost of a bug is usually pretty small.
There are some game systems that lend themselves to unit testing, like say map generation to ensure that the expected landmarks are placed reasonably, or rooms are connected, or whatever. But most game interactions are just not easily "unit testable" since they happen across frames (eg over time). How would you unit test an enemy that spawns, moves towards the player, and attacks?
I'm sure you could conjure up any number of ways to do that, but they won't be trivial, and maintaining those tests while you iterate will only slow you down. And what's the point? Even if the unit-move-and-attack test passes, it's not going to tell you if it looks good, or if it's fun.
Ultimately you just have to play the game, constantly, to make sure the interactions are fun and working as you expect.
It would depend on how things are architected, but you could definitely test the components of your example in isolation (e.g. spawn test, get the movement vector in response to an enemy within a certain proximity, test that the state is set to attacking, whatever that looks like). I don't disagree that it's a hard problem. I run into similar issues with systems that use ML as some part of their core, and I've never come up with a satisfying solution. My strategy these days is to test the things that it makes sense to test, and accept that for some things (especially dynamic behavior of the system) you just have to use it and test it that way.
> How would you unit test an enemy that spawns, moves towards the player, and attacks?
You use a second enemy that spawns, moves towards the "enemy", and attacks.
> How would you unit test an enemy that spawns, moves towards the player, and attacks?
You can easily write a 'simulation' version of your event loop and dependency inject that. Once time can be simulated, any deterministic interaction can be unit tested.
Others would quibble that those are integration tests, "UI" tests, or other higher-level tests, etc.
Which is all the same as what unit test was originally defined as.
You're right that "unit test" has taken on another, rather bizarre definition in the intervening years that doesn't reflect any kind of tests anyone actually writes in the real world, save where they are trying to write "unit tests" specifically to please the bizarre definition, but anyone concerned about definitional purity enough to quibble about it will use the original definition anyway...
A lot of games aren't deterministic within a scope of reasonable test coverage.
Set the same seed for the test?
> and the cost of a bug is usually pretty small.
Like letting speed runners skip half your game. :)
I've heard the same excuses from ML engineers before introducing tests there, embedded engineers, robotics engineers, systems engineers, everyone has a reason.
The real reason? It's because writing tests is a different skill and they don't actually know how to do it.
Oh that's crap. I've been a software engineer for over 30 years. I love tests - I preach testing at my current place of work. I've also worked in games for about a decade. Testing in games is... not useless, but very much less useful than it is in general software engineering.
The problem with tests for games is that a lot of game code is in constant flux. A test suite introduces a not insignificant amount of rigidity to your codebase. Pivot a few concepts and you have dozens of tests to fix - or just invalidate entirely. Very basic stuff that won't ever change can be tested - like whether the renderer is working properly - but that's never where the difficulty in game dev lies and its the stuff usually handled by a third party - library or engine.
> The problem with tests for games is that a lot of game code is in constant flux. A test suite introduces a not insignificant amount of rigidity to your codebase. Pivot a few concepts and you have dozens of tests to fix - or just invalidate entirely.
Sounds very much like the description of a big ball of mud.
An interesting gamedev video I saw recently basically boiled down to: "Build systems, not games." It was aimed at indie devs to help with the issue of always chasing new projects and making code that's modular enough to be able to reuse it.
But taking a step back, that very much feels like it should apply to entire games, where you should have boundaries between the components and so that the scope of any such pivot is managed well enough not to tank your velocity.
Other than that, it'd be just the regular growing pains of TDD or even just needing to manage good test coverage - saying that tests will eventually need changes isn't the best argument against them in webdev, nor should it be anywhere else.
> Sounds very much like the description of a big ball of mud.
I mean, yeah, kinda.
For any given object in the game world, it's funnest for that object to be able to interact with as many other objects as possible in as many ways as possible. A game object's handles for interaction need to be globally available and can't impose many invariants—especially if you don't want level designers to have to be constantly re-architecting the engine code to punch new holes for themselves in the API. Thus, a lot of the logic in a given level tends to live inside the callback hooks of level objects, and tends to depend on the state of the rest of the level for correctness.
Modularity is a property of high cohesion and low coupling, which are themselves only possible when you can pin down your design and hide information behind abstraction boundaries. But games are a flexible and dynamic enough field that engines have to basically let designers do whatever they want, whenever they want in order for the engine to be able to build arbitrary games. So game design is naturally a highly-coupled, incohesive problem space that is poorly suited to unit testing.
> So game design is naturally a highly-coupled, incohesive problem space that is poorly suited to unit testing.
Poorly suited? Perhaps, but so are certain web system architectures as well, neither is impossible to test.
I think Factorio is an example that it can be done if you care about it... it's just that most studios shipping games don't.
https://www.factorio.com/blog/post/fff-438
https://www.factorio.com/blog/post/fff-366
Of course, in their case it can actually be justified, because the game itself is very dependent on the logic working correctly, rather than your typical FPS game slop that just needs to look good.
Yeah I suspect Factorio's "complex game logic + simple(ish) 2d engine + minimal team structure" situation meant that the usual tradeoffs didn't apply. It's really cool that they pulled it off, though—I can't imagine it was easy, even then.
As a counter example I found this video essay about fixing a factorio bug fascinating. My main takeaway, I need better introspection hooks. I am not really programmer and I never really thought automated testing of user interactive parts was possible.
https://www.youtube.com/watch?v=AmliviVGX8Q (kovarex - Factorio lets fix video #1)
League of Legends does a lot of automated testing for their gameplay logic https://technology.riotgames.com/news/automated-testing-leag...
> 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.
because it has millions of examples of that in its training data?
Make the same engagement metric as people do; try to break it
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.
Sure they do -- but once you introduce at least one custom component (i.e. hexagon map), it's actually not straightforward, how to integrate it with the rest of the controls.
I can't say whether it's me who's stupid, or it's just not very easy to make good UI in game engines. I don't say that's not doable of course -- i'm just saying one would need to invest quite a bit of time to work out how to do this.
> 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.
https://steamdb.info/stats/releases/?tagid=492
You also still have the same amount of time you had 40 years ago. There are definitely more games available, and I would argue the proportion of high quality games has also increased massively, but since you're still limited by the number of games you can play in any given year, you'll never feel that increase.
Why would the proportion of high quality games increase? The number yes, but I expect not the proportion. Lowering the entry barrier means more people who have spent less time honing their skills can release something that's lacking in polish, narrative design, fun mechanics and balance. Among new entrants, they should number more than those already able to make a fun game. Not a value judgement, just an observation.
Think of the negative reputation the Unity engine gained among gamers, even though a lot of excellent games and even performant games (DSP) have been made with it.
More competitors does also raise the bar required for novelty, so it is possible that standards are also rising in parallel.
We had shovelware games 25+ years ago (and probably 40 years ago, though I suspect the lack of microcomputers limited that). There were bargain-bin selections (literally bins full of CDs) that cost a few bucks and were utterly shite. I suspect the target audience was tech-unaware relatives who would be "little Johnny likes video games, I'll get him one of these...". Most of them were bad takes on popular games of the time.
Unity + Steam just makes this process a bit easier and more streamlined. I think the new thing is that as well as the dickwads who are trying to rip people off, there are well-intentioned newbie or indie developers releasing their unpolished attempts. These folks couldn't publish their work in the old days, because making CDs costs money, while now they can.
Since it led to more games, it led to more bad AND good games.
I don’t think we would’ve seen a Hollow Knight without Unity, built by a team of 2-3 devs.
Looking at shareware days and games like Jazz Jackrabbit with team of 2-3 devs also. I don't know if Unity would have been necessary. Ofc, after 20 years there is lot more processing power and lot less memory constraints. But still, I am not sure if such engines fundamentally changed anything.
It'd be quite difficult to deploy the processing power and other resources without an engine.
A 90s PC can't do a complex 3d engine because it lacks the grunt. A 2020s game dev can't do a complex 3d engine themselves because they don't know how to do complex 3d.
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.
I think "proportional" is the key word here..
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.
Like a full sprite sheet, one sprite at a time or a sprite animation loop?
Each one would require a different kind of model and model technique to make, so I wouldn't be surprised that ChatGPT has issues with it. A sprite animation loop would be better done by a potentially specialized video-oriented model, for example, and the current image and video models are barely trained on that kind of video data.
that might be possible by asking it to create an 3d model with animations (based on a template) and then capture the sprites. but then again, not sure if building it would be worthwhile because 1) openai might add that as a native product (like what happened with .ppt generation) or 2) the capability to do so might be 6 months away
Have you tried drawing?
According to all the lazy articles I've read here lately you just need to threaten to beat it up lmao...
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.
Mind sharing what you have tried? Have you considered training a diffusion model on pixel art, and then conditioning it on a 3D model?
Agreed, I got an LLM to build me a Super Mario Bros game with 0 code and it's playable after 2 prompts but I'm stuck with the spritesheet as well.
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.
Yeah I tried to get a spritesheet generated. Absolute rubbish.
> we didn’t see a proportional explosion of good game
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.
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
I don't think the post you replied to says otherwise, but Unity meant there was now a path with professional grade tools without spending a fortune. It definitely did create a new wave of indie games, some of them amazing.
Correct, but it's really hard to comprehend how this is related to what I said.
And the main reason why actually making a game with interesting gameplay is more relevant than discussing what is the best language to do a game on.
> 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 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.
> what happens when AI can not only implement but also playtest -- running thousands of iterations of your loop
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.
It's been YouTube series of AI vs AI starcraft for a long time.
AI is insane. It can do like 10,000 actions per second lol
https://youtu.be/0p34y7X0VCM?si=GSAjOyRmK6kNmYdx
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.
IMO, looking at most budget spend, it's the art & content that is the bottleneck.
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.
> have never worked on games and it will take me quite a while (even months) to write a "basic" game.
You're contradicting yourself. I promise it wouldn't take you months, unless you're just a really bad developer.
What is the contradiction? I am guessing it will take me a non-significant effort to learn game mechanics and code them etc.
You've never worked on games yet you are exceedingly confident about your estimation or the difficulty involved.
It's not that difficult to get a base level game up and running; ESPECIALLY with modern tooling.
Don't be a prick in public man, it looks bad
I mean it's a simple fact that the baseline for creating a game, roughly using the average developer experience/capability, is not months. Making a _good_ game might take months, it often takes years.
And that's the part AI is not going to be able to help you with.
Making a good boardgame, with zero need for programming, excluding artwork, is months or years of work. I would expect that much at a minimum for a (good) simple digital game, unless it is just going to sell on graphics and marketing alone (or luck).
Maybe you are a games developer and are overlooking the fact that people have to first learn the basic apis/models/etc. of graphical systems, engines, etc. before using them. Not sure how you are saying that it wouldn't take a few weeks to code even a simple production game like chess or more complicated but still simple Jump king etc.
Just think of the speciality in which you aren't an expert, javascript/storage/networking ...
I've dabbled and continue to dabble in areas where I know nothing about. And in this case, there's nothing super special about making a game.
> 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.
The best games take risks and aren't min/maxed.
> 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.
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:
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.
[1] https://www.reddit.com/r/ProgrammerHumor/comments/1mudy12/th...
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
> hold someone’s attention for more than 5 minutes.
more like, more than 5 seconds.
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.
Yeah, I figured this was clickbait but my jaw still dropped a bit when I saw this:
How long would it take the human dev to refactor the code themselves? I think it's plausible that it would be longer than 3 days, but maybe not!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..
>As an LLM hater
I thought this was the start of a joke or something, I guess if you use LLMs you are a "LLM lover" then.
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.
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.
cough how about 24 hours?
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.
> I strongly believe it's the communication among team members.
"Communication" within your own head is often also surprisingly difficult.
A healthy amount of my work is writing code, trying it out, and deleting it. This is something that the LLMs seem quite far from being able to do.
It can automate a third of that at least. That seems useful!
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.
https://thomashansen.xyz/blog/ebiten-and-go.html
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.
Hah. Obviously there’s probably something I can’t make but I mean it’s by far not the bottleneck for me. And funny you should say, because my last job was actually building peer to peer multiplayer netcode with fully deterministic rollback for a video game. It was hard and took years but we did it.
I think you keep saying “ideas are easy” (for you) and insisting therefore they’re easy for everyone else. They’re really not, good ideas anyway.
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
It took me few days on and off to do this with llm: https://www.susmel.com/stacky/
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.
nice tetris reimplementaion! jfyi on firefox + m4 max MBP, this pegs a core at 100% utilization and really spins up the fans
yeah, I'm aware of firefox issues. In next iteration with WebGL it's gone though. So, so far a note that it works best in Chrome/ium.
If you want an all client side game... Why do you write it as though it has a "backend"? Why use different tech for "backend" vs the whole app?
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.
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?
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.
> are all usually quite polished given the timespan
The open secret is that they might not start coding or building assets until the start time, but they have spent a lot of time thinking about the ideas before then (even when the "theme" isn't known before hand people tend to make ideas fit theme with tweaks), which just speaks to the "code is not the bottleneck" thesis.
For one datapoint, I've participated in many gamejams and I've never ever spent any time beforehand thinking about ideas.
How many big game jams have you won/placed very highly in though?
Game jams typically require games to adhere to a theme that is only known the day of, and the best entries will make a game specifically around that, not just adapt some pre-existing idea to it.
The themes are so open ended it’s very easy to adapt most game ideas. Games that win tend to be the most fun to play not necessarily the ones that fit the theme the best.
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.
> 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.
This is mostly from artists themselves. Most people are ok with even fully generated content if it's fun and interesting. Anyway, solo developer cannot afford even single artist, musician, writer.
That's where LLM helps. I recently tried GPT5 for story telling. Gave it a single image (in a bar, women, man, and a gun) and asked for a short story. Then asked for the next part 6 times. Every time at the end for illustration. The result was consistent and readable. Images generated had even similar faces. Remember, that was a problem with earlier models. I'm sure this will be used fill Amazon's bookshelves.
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.
I highly recommend making a game and then reviewing your comment.
This is like asking "where are all the very polished and professional LLM books."
About 50 games are released on Steam every day. How much higher are you suggesting this number should go?
I'm not going to say this is all LLMs but Steam game releases have exploded.
https://steamdb.info/stats/releases/
Still seems to be roughly following the pre-AI trajectory though.
Which is really easy to argue it's more down to Unity + successors making game dev accessible as it starts in 2015.
No huge spike since Claude code got released or anything like that.
>Still seems to be roughly following the pre-AI trajectory though.
Not really. The jump from 2023 to 2024 is bigger than the jump from 2019-2022 in raw numbers and 2020-2022 in %. So the jump of 3 to 4 years happened in a single year.
But as of August 2025, we are on pace to see fewer games in 2025 than in 2024.
Also the jump in 2024 is only around 10-15% more games than we would have expected from the previous trend. Assuming all of that is directly down to AI, I wouldn’t call that an explosion.
From what I’ve seen, most of the growth was in NSFW shovelware and was just people noticing a business opportunity. This also explains why the number it takes in 2025 isn’t showing similar growth.
>But as of August 2025, we are on pace to see fewer games in 2025 than in 2024.
No we're not. Use Wayback machine or whatever and this year is 1k+ ahead at the same date.
https://web.archive.org/web/20240822090931/https://steamdb.i...
>Also the jump in 2024 is only around 10-15% more games than we would have expected from the previous trend. Assuming all of that is directly down to AI, I wouldn’t call that an explosion.
How many games do you imagine can be released per day even with the help of current Sota LLMs ? Nevermind the fact that you have to pay $100 to distribute your game on Steam. You're not making a game you'd pay $100 to distribute in 3 days, LLM help or not.
But fair, exploded is probably overstating it.
There must be a huge push end of year.
>How many games do you imagine can be released per day even with the help of current Sota LLMs ?
Given the number of people who want to make games—if code is the bottleneck, and LLMs can really make you hugely more productive, I’d expect to see an actual explosion.
My experience is that neither of those assumptions are true though.
>Given the number of people who want to make games—if code is the bottleneck
Game development is not a zero sum game. There can be multiple bottlenecks or difficult hurdles.
>and LLMs can really make you hugely more productive, I’d expect to see an actual explosion.
Well growth was double the previous year. Maybe you might not call that an explosion, it's still a very noticeable uptick.
It is possible that LLMs boost productivity by 2x-10x and there’s another bottleneck that limited the growth to a few thousand games.
I think it’s much more likely that LLMs don’t actually boost productivity all that much.
Delegating all the fun of making games to LLMs and leaving only the boring part for yourself puts you in the infinite procrastination mode.
Watching LLM generating the code doesn't help with producing the dopamine.
Some people think the fun part is the requirements and gameplay, and code is the boring part.
Games dev at my alma mater was split into two courses, bachelor of science (which focused on the technical side) and bachelor of arts which focused on 3d modelling, animation, concept art, etc.
Both groups wanted to make games.
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.
LLMs can't help much with assets?
This.
You may as well buy a shooter game starter pack or whatever that can save you >1year of coding, no llm needed.
Code is not a hard part.
Making mechanics fun and good assets is what is hard and takes forever.
Sure you can use llm to write a generic game, but its easier to find same game on github and just use that code, why would you write it again with llm.
Why not just copy the mechanics of an existing fun game?
If it's identical, you made a clone. If it's evenly slightly different, the design needs to be rethought. In a good game, the mechanics, assets, and game loop harmonize. Change one piece, and the balance shifts.
Many people do and then sell nothing
Wargroove copied almost everything from advance wars and put it in a fantasy setting, yet it sold much more than most indie games. Copying most values and mechanics from another game wont make a massive hit but it doesn't sell nothing, people who like the mechanics a lot will buy it to play with them some more in a new game.
If you copy a nintendo-platform game which hasnt gotten any love in a long time, put effort into it, and sell it on PC, then yes, you can sell a lot. Harvest Moon hasn't had a good game in over a decade, which is why Stardew Valley was so successful. Similarly, Pokemon has been neglected for generations and there have been a few successful games in the genre, like coromon.
But if you mean copying an already successful PC game with AI Slop assets and putting absolutely no thought into what makes the game good, then you probably should work in a field you actually care about instead
But image generation and cloning a visual artist’s style is one of AI’s apparent strengths.
So it’s interesting to think about what the gaps are between fulfilling a single prompt and completing a project.
AI generated assets look like dogshit
Incidentally so do many cheap games.
This is a great analogy. There's a wider Fermi paradox here regarding business productivity. Where's the 10x economic output?
in the stock market?
That misses huge parts of games. Actual content. Could be story, could be levels, could be features, could be item design, could be balance.
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.
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.
Easy! Ask the LLM to play the game and if it’s not fun to try again. just like when you ask it to compile the code and if it fails to try again
…Joking…. For now
This is almost on the money. Making something fun often requires coding, art, sound etc to bring the fun out. So in fact coding is the difficult part, along with all the other stuff needed for something to be fun. Imo tooling like ue blueprints and visual scripting is in the coding bucket.
I’m not saying coding is easy, but when it comes to games it is the easy part. Lots of people can code, very few can make something actually fun. Knowing how to code (or how to use an engine/blueprints/visual scripting) is just the start. It’s like making films. Everyone can record some videos on their phone, but it takes much more than that to make something people want to watch.
That analogy is more accurate for LLM vibe coding than real programming which i think proves my point. Not everyone can code. Actually code. Ideas are bountiful compared to the required skill to bring them into reality.
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...
Share it!
Yes, these LLM’s need feeding.
Given that it's human directed AI slop, they'll be feeding on themselves.
Code is not the hard part of making a game
Creativity is the hard bit yo
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:)
Go's WASM binaries are huge. You can get far with tinygo, but that means you can't use anything that relies on CGO.
I eventually left Go and went to Rust for better WASM support... seems to get me a lot further!
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 wonder when it will sink in that greenfield projects are the worst possible project to benchmark agentic coding competency
Asking for information - Is Go/wasm doing something here which React/JavaScript cannot?
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 ...
Nah, whatever bug you're referring to is my fault, haha, don't blame the LLM. But in between game state bugs are very unlikely, haha: https://github.com/marianogappa/escoba-de-15/blob/main/src/A...
I can't imagine state surviving a location reload with nothing on local storage and no server.
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.
From experience: A static type system is MUCH better for agents than dynamic. I've done a few projects both ways - the agent is just much, much better with the static system because it sees compile errors right away, and also has access to better static analysis tools. I don't know how much the types themselves help the LLM, it's better context but more tokens, but the agent seeing errors is just a huge difference.
It's also much easier for you as a developer to digest the code if you need to refactor because you got lazy and accepted some slop.
In my experience, a massive YES. At least with agenetic models that have an iteration loop, and in languages like Rust where the type system is strong enough to prevent categories of bugs.
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.
on Escoba when I clicked info, I can't close the info window and I have to refresh the page. Would be helpful if there is How to Play in English.
Then where is GTA6?
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.
Newsflash! A dev that doesn’t know what they are doing uses LLM to generate slop, and the slop seems better than doing it manually
Now, it's all about ideas.
AI slop must be abolished.
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.
I was happily reading along loving all the go until the last part.
No. Just use go.Other than that. Loved the article and I love making games (haven’t shipped one in a while, I should)
https://gist.github.com/paulmach/7271283
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.Why write 27 lines of Go (not one line) when you can do
And still it is a silly argument because using npx is still less effort than having to write those 27 lines when zero will do. Sure, you dislike Javascript, do whatever you want. No need for pointless pedantry.10 lines of that are comments, 4 of which are flags that aren’t required, nor is the 2 lines of white space and log lines.
The guy goes through all this trouble with Golang, WASM, tinygo, just to field goal it on the 3 yard line.