Live data from Hacker News

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

marianogappa.github.io

81–90 of 236 posts

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

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

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

#82
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 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.)

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

#83

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…

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.

[1] https://www.reddit.com/r/ProgrammerHumor/comments/1mudy12/th...

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

#84
post #82

Earlier quoted context omitted.

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.

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

#85
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!

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.

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

#86
post #65

Earlier quoted context omitted.

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

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

#87
post #2

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

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.

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

#88

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…

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

I think "proportional" is the key word here..

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

#89
post #26

Earlier quoted context omitted.

I don’t get these arguments. Just because LLM learned the entire internet does not mean it can’t 10x a developer. Were all standing on shoulders of giants - LLM or no LLM. LLM gives you extra pair of ladders. That are wobbly for sure. But ladders still. Using LLM invalidates nothing and the 10x stories are totally plausible. The plagiarization argument is to me moot - most of us are plagiarizing previous work, weathe…

That wasn't the argument at all. If I wrote a card game in 3 months, then cloned the repository and used that as a base to implement a different card game, it would be significantly faster with or without LLMs. The argument is that it's not really an apples-to-apples comparison. "I wrote a game in 3 months and then used an LLM in 3 days to fork it and make some changes" is not the same thing as "I spent 3 months doin…

Exactly true. I've had the experience of implementing a programming language in two different languages. The first time it took half a year. The second time it was done in a month, because it was really only a matter of translating all of the code from one c-style imperative language to another, and swapping out the important library code and function calls.

Maybe AI can take that process from a month down to 3 days, and that's great and all, a 10x improvement! But you don't go from 6 months to 3 days without doing the 6 months first.

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

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

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.

Post reply on HN