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

231–236 of 236 posts

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

#231

Post by theshrike79 »

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.

Data is the lifeblood of mobile gaming, everything is data-driven.

Everything is measured and analysed and optimised for engagement and monetisation.

When you have 200 people making a game, "luck" or "art" doesn't factor in at all. You test, get data, and make decisions based on the data, not feelings.

Solo devs can still make artsy games and stumble upon success.

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

#232

Post by KronisLV »

bccdee wrote: post #230
KronisLV wrote: post #217

Earlier quoted context omitted.

> 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. Sounds very much like the description of a big ball of mud. An interesting gamedev video I saw recently basically boiled down to: "Build systems, not games." It was aim…

> Sounds very much like the description of a big ball of mud. I mean, yeah, kinda. For any given object in the game world, it's funnest for that object to be able to interact with as many other objects as possible in as many ways as possible. A game object's handles for interaction need to be globally available and can't impose many invariants—especially if you don't want level designers to have to be constantly re-a…

> So game design is naturally a highly-coupled, incohesive problem space that is poorly suited to unit testing.

Poorly suited? Perhaps, but so are certain web system architectures as well, neither is impossible to test.

I think Factorio is an example that it can be done if you care about it... it's just that most studios shipping games don't.

https://www.factorio.com/blog/post/fff-438

https://www.factorio.com/blog/post/fff-366

Of course, in their case it can actually be justified, because the game itself is very dependent on the logic working correctly, rather than your typical FPS game slop that just needs to look good.

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

#234

Post by bccdee »

KronisLV wrote: post #232
bccdee wrote: post #230

Earlier quoted context omitted.

> Sounds very much like the description of a big ball of mud. I mean, yeah, kinda. For any given object in the game world, it's funnest for that object to be able to interact with as many other objects as possible in as many ways as possible. A game object's handles for interaction need to be globally available and can't impose many invariants—especially if you don't want level designers to have to be constantly re-a…

> So game design is naturally a highly-coupled, incohesive problem space that is poorly suited to unit testing. Poorly suited? Perhaps, but so are certain web system architectures as well, neither is impossible to test. I think Factorio is an example that it can be done if you care about it... it's just that most studios shipping games don't. https://www.factorio.com/blog/post/fff-438 https://www.factorio.com/blog/po…

Yeah I suspect Factorio's "complex game logic + simple(ish) 2d engine + minimal team structure" situation meant that the usual tradeoffs didn't apply. It's really cool that they pulled it off, though—I can't imagine it was easy, even then.

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

#235

Post by snovv_crash »

peterashford wrote: post #152
snovv_crash wrote: post #147

Earlier quoted context omitted.

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.

Oh that's crap. I've been a software engineer for over 30 years. I love tests - I preach testing at my current place of work. I've also worked in games for about a decade. Testing in games is... not useless, but very much less useful than it is in general software engineering.

I have no experience in the gamedev industry. But based on the number of bugs I see in games, plus the size and quantity of post-release patches, maybe your perspective here is because you're not trying to hit a level of reliability at launch that would justify having more tests?

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

#236

Post by peterashford »

snovv_crash wrote: post #235
peterashford wrote: post #152

Earlier quoted context omitted.

Oh that's crap. I've been a software engineer for over 30 years. I love tests - I preach testing at my current place of work. I've also worked in games for about a decade. Testing in games is... not useless, but very much less useful than it is in general software engineering.

I have no experience in the gamedev industry. But based on the number of bugs I see in games, plus the size and quantity of post-release patches, maybe your perspective here is because you're not trying to hit a level of reliability at launch that would justify having more tests?

I think that's indicative of not having enough QA. QA IS effective in the context of games for discovering bugs.
Post reply on HN