←back to thread

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

(marianogappa.github.io)
358 points maloga | 3 comments | 24 Aug 25 15:01 UTC | HN request time: 0.001s | source
Show context
starchild3001 ◴[24 Aug 25 17:30 UTC] No.45006027[source]▶
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.

replies(23): >>45006060 #>>45006124 #>>45006239 #>>45006264 #>>45006330 #>>45006386 #>>45006582 #>>45006612 #>>45006690 #>>45006907 #>>45007151 #>>45007178 #>>45007468 #>>45007700 #>>45007758 #>>45007865 #>>45008591 #>>45008752 #>>45010557 #>>45011390 #>>45011766 #>>45012437 #>>45013825 #
1. marqueewinq ◴[25 Aug 25 10:45 UTC] No.45012437[source]▶
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.

replies(1): >>45012487 #
2. 0points ◴[25 Aug 25 10:55 UTC] No.45012487[source]▶
> 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.

replies(1): >>45012514 #
3. marqueewinq ◴[25 Aug 25 11:01 UTC] No.45012514[source]▶
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.