Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

marianogappa.github.io

Post reply on HN
Print view View original

141–150 of 236 posts

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

#141

Post by Ekaros »

jonny_eh wrote: post #137
milesvp wrote: post #95

Earlier quoted context omitted.

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

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.

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

#142

Post by Ekaros »

raincole wrote: post #50
starchild3001 wrote: post #30

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…

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

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.

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

#143

Post by [deleted] »

zarzavat wrote: post #74
zahlman wrote: 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.

[deleted]

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

#144

Post by benreesman »

starchild3001 wrote: post #30

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

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

#145

Post by georgeecollins »

yonatan8070 wrote: post #69
zahlman wrote: 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…

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.

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

#146

Post by riazrizvi »

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

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.

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

#147

Post by snovv_crash »

nine_k wrote: post #82
AlienRobot wrote: post #70

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

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.

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

#148

Post by georgeecollins »

uncircle wrote: post #125
yonatan8070 wrote: post #69

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…

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

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

#149

Post by 3036e4 »

whoknowsidont wrote: post #132
__loam wrote: post #119

Earlier quoted context omitted.

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

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

#150

Post by peterashford »

AlienRobot wrote: post #70
zahlman wrote: 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.

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