Live data from Hacker News

Making games in Go: 3 months without LLMs vs. 3 days with LLMs

marianogappa.github.io

121–130 of 236 posts

Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs

#121

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…

> 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

Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs

#122
post #9

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: 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. 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..

Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs

#123
post #64

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…

> 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?

Make the same engagement metric as people do; try to break it

Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs

#124

Earlier quoted context omitted.

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…

>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 explosi…

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.

Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs

#125
post #64

Earlier quoted context omitted.

> 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…

> 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.

Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs

#126

Earlier quoted context omitted.

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…

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.

Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs

#127

I was happily reading along loving all the go until the last part. npx http-server 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.

    go run http.go

You shouldn’t have to use npx when the tool at hand is perfectly capable.

Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs

#128

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 lu…

> 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.

Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs

#129

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…

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.

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)

Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs

#130

Earlier quoted context omitted.

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 nu…

> 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.
Post reply on HN