←back to thread

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

(marianogappa.github.io)
358 points maloga | 1 comments | 24 Aug 25 15:01 UTC | HN request time: 0s | 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 #
zahlman ◴[24 Aug 25 18:45 UTC] No.45006612[source]▶
> 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?

replies(6): >>45006727 #>>45006729 #>>45006732 #>>45007524 #>>45009348 #>>45011331 #
AlienRobot ◴[24 Aug 25 19:01 UTC] No.45006729[source]▶
Game developers will try anything before they actually write automated tests for their games.
replies(4): >>45006869 #>>45007969 #>>45008182 #>>45008219 #
nine_k ◴[24 Aug 25 19:19 UTC] No.45006869[source]▶
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.)
replies(2): >>45006914 #>>45007912 #
greesil ◴[24 Aug 25 19:24 UTC] No.45006914[source]▶
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.
replies(2): >>45007341 #>>45009355 #
pton_xd ◴[24 Aug 25 20:10 UTC] No.45007341[source]▶
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.

replies(3): >>45007420 #>>45007480 #>>45010084 #
1. coderenegade ◴[25 Aug 25 04:03 UTC] No.45010084{6}[source]▶
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.