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

191–200 of 236 posts

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

#191

Post by 9rx »

mac-mc wrote: post #130
cherryteastain wrote: post #118

Earlier quoted context omitted.

> How would you unit test an enemy that spawns, moves towards the player, and attacks? You can easily write a 'simulation' version of your event loop and dependency inject that. Once time can be simulated, any deterministic interaction can be unit tested.

Others would quibble that those are integration tests, "UI" tests, or other higher-level tests, etc.

Which is all the same as what unit test was originally defined as.

You're right that "unit test" has taken on another, rather bizarre definition in the intervening years that doesn't reflect any kind of tests anyone actually writes in the real world, save where they are trying to write "unit tests" specifically to please the bizarre definition, but anyone concerned about definitional purity enough to quibble about it will use the original definition anyway...

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

#192

Post by sbinnee »

spicyusername wrote: post #184

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. Definitely still incredible by 2019 standards. Absolutely no doubt. But by LLM standards, feeding it the entire working codebase of a simple, similar, game you wrote by hand as context is basically doing all the work yourself still.

Maybe that’s how we are supposed to work with current LLMs. Having a template or an example we understand is a big advantage. It can prevent LLM from many pitfalls, and more importantly we can easily review the output.

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

#193

Post by poslathian »

benreesman wrote: post #144
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…

This true - and git was not a moving target. AI core tech has certainly slowed down but still moving fast enough to make hard won lessons worthless and investing in learning them questionable.

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

#195

Post by guywithahat »

I played around with making games in go for a while and found limited benefits. Go routines, while great, have too much latency to meaningfully parallelized simple tasks between the in-game ticks per second (~60hz). Along the same lines, channels end up having too many allocations/frees and read/writes to be useful at such a normal ticks per second (TPS).

The result is you can't use the best features of go, and even the 2D engine I used (ebiten) didn't use go routines or channels anywhere in the engine. I like the idea of making games in Go, but the language's best features don't shine well, and I struggle to imagine it ever taking off beyond a hobby game language.

https://thomashansen.xyz/blog/ebiten-and-go.html

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

#196

Post by coderenegade »

pton_xd wrote: post #115
greesil wrote: post #84

Earlier quoted context omitted.

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.

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

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.

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

#197

Post by mlyle »

georgeecollins wrote: post #148
uncircle wrote: post #125

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

Yah. I think an AI playtester that could go "hey... this itch that lots of players seem to have doesn't get scratched often in your main gameplay loop" or "there's a valley 1/3rd of the way into the game where progression slows way down" or "that third boss is way too hard".

AI/fuzzers can't get far enough in games, yet, without a lot of help. But I think that's because we don't have models really well suited for them.

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

#198

Post by sandspar »

zerr wrote: post #36
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…

My litmus test for generative AI: generate a complete spritesheet for a 2D pixel art action game, e.g. only for the battle tank or main hero movements. No success so far.

Maybe AI games can use AI-first art styles. If I ask a camera to create an André Derain painting then it will fail. But that's my fault for misunderstanding the medium.

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

#199

Post by jama211 »

maloga wrote: post #68
hollowturtle wrote: post #58

Earlier quoted context omitted.

The only reason I can think of is some sort of virtue signaling, like to promote one self. But even then why not spending ~6 months and super polish the game that would make you look like a rockstar? Eventually using ai in the process to learn where it can be useful... otherwise i don't understand

No need to think or guess. You can just bite the bullet and actually read the article. I explained why I built it.

Don’t worry about the haters OP, the rest of us loved your article and the games look cool

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

#200

Post by jama211 »

rustystump wrote: post #166
jama211 wrote: post #91

Earlier quoted context omitted.

I largely agree with your point, but interestingly I’ve always found the ideas and blue sky thinking game design part the hardest personally. I can code nearly any game mechanic at this point, but struggle with the writing/creativity part of game development. If you find that easy, you should consider yourself rather blessed, it doesn’t come naturally to us all.

People build up too great of expectations when the topic of “creativity” comes in. Nothing is new under the sun. Also, i press “x” to doubt you can build any game mechanic not because i have no doubt you are a talented engineer but because the domain is really that vast. Multiplayer netcode is a prime example and why I used an idea which had a multiplayer component that was realtime. Ideas are cheap. Making them real…

Hah. Obviously there’s probably something I can’t make but I mean it’s by far not the bottleneck for me. And funny you should say, because my last job was actually building peer to peer multiplayer netcode with fully deterministic rollback for a video game. It was hard and took years but we did it.

I think you keep saying “ideas are easy” (for you) and insisting therefore they’re easy for everyone else. They’re really not, good ideas anyway.

Post reply on HN