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

221–230 of 236 posts

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

#221

Post by WA »

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…

You are absolutely right! The tic-tac-toe game we‘ve been working on is a total blast and simulated players 1-1000 enjoy it very much! I think we should release it soon.

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

#222

Post by kenoath69 »

rustystump wrote: post #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 lu…

I agree, turning a simple idea into a polished game takes like a year. Most of it isn't even in the core idea but surrounding polish, menus, extra features, etc. Source I did it. Also I'm just saying the stack from this post is insane. It would probably one shot the task in p5js or C/raylib

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

#223

Post by jplusequalt »

uncircle wrote: post #128
rustystump wrote: post #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 lu…

> 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. I disagree. Sure, it's hard, but it's much harder to come up with novel and fun gameplay ideas. Once you have the fun idea, it's just a matter of splitting the problem in bite-…

>but it's much harder to come up with novel and fun gameplay ideas

I'm going to give an analogy to fiction writing. You ever notice how seemingly everyone has an idea for a story, but shockingly few of them ever execute on their ideas? Why is that?

Well, it's because the ideation stage is the easiest fucking part of writing a book! Sitting down to turn that idea into reality is a process that takes months/years. It requires a lot of concentrated effort, and a willingness to deal with the fact that your writing skills (probably) suck.

It's the same with video games. Probably more so, because the medium is much less restrictive than fiction writing.

Also, quick tangent on the topic of "novel" gameplay ideas--if you listen to successful creatives, some common advice they give is that focusing on being original is a noob trap. Ideas are cheap in the arts, and most things have already been done. It's the execution that matters, which ties back in to my point above.

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

#224

Post by [deleted] »

nkrisc wrote: post #180
davepeck wrote: post #99

Earlier quoted context omitted.

Ive never once successfully gotten a usable sprite sheet out of ChatGPT. The concept seems foreign to it and no matter how hard I try to steer it it’ll find a way to do something hopeless (inconsistent frame sizes; incoherent animations; no sense of consistent pixel sizes or what distinguishes (say) 8-bit from 16-bit era sprites; it’ll draw graph paper in the background for some reason; etc etc.). If anyone has a set…

Have you tried drawing?

[deleted]

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

#226

Post by whoknowsidont »

hcnews wrote: post #186
whoknowsidont wrote: post #113

Earlier quoted context omitted.

> have never worked on games and it will take me quite a while (even months) to write a "basic" game. You're contradicting yourself. I promise it wouldn't take you months, unless you're just a really bad developer.

What is the contradiction? I am guessing it will take me a non-significant effort to learn game mechanics and code them etc.

You've never worked on games yet you are exceedingly confident about your estimation or the difficulty involved.

It's not that difficult to get a base level game up and running; ESPECIALLY with modern tooling.

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

#227

Post by whoknowsidont »

hcnews wrote: post #187
whoknowsidont wrote: post #132

Earlier quoted context omitted.

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.

Maybe you are a games developer and are overlooking the fact that people have to first learn the basic apis/models/etc. of graphical systems, engines, etc. before using them. Not sure how you are saying that it wouldn't take a few weeks to code even a simple production game like chess or more complicated but still simple Jump king etc. Just think of the speciality in which you aren't an expert, javascript/storage/net…

I've dabbled and continue to dabble in areas where I know nothing about. And in this case, there's nothing super special about making a game.

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

#228

Post by shortrounddev2 »

Jensson wrote: post #218
shortrounddev2 wrote: post #24

Earlier quoted context omitted.

Many people do and then sell nothing

Wargroove copied almost everything from advance wars and put it in a fantasy setting, yet it sold much more than most indie games. Copying most values and mechanics from another game wont make a massive hit but it doesn't sell nothing, people who like the mechanics a lot will buy it to play with them some more in a new game.

If you copy a nintendo-platform game which hasnt gotten any love in a long time, put effort into it, and sell it on PC, then yes, you can sell a lot. Harvest Moon hasn't had a good game in over a decade, which is why Stardew Valley was so successful. Similarly, Pokemon has been neglected for generations and there have been a few successful games in the genre, like coromon.

But if you mean copying an already successful PC game with AI Slop assets and putting absolutely no thought into what makes the game good, then you probably should work in a field you actually care about instead

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

#230

Post by bccdee »

KronisLV wrote: post #217
peterashford wrote: post #150

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

> 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-architecting the engine code to punch new holes for themselves in the API. Thus, a lot of the logic in a given level tends to live inside the callback hooks of level objects, and tends to depend on the state of the rest of the level for correctness.

Modularity is a property of high cohesion and low coupling, which are themselves only possible when you can pin down your design and hide information behind abstraction boundaries. But games are a flexible and dynamic enough field that engines have to basically let designers do whatever they want, whenever they want in order for the engine to be able to build arbitrary games. So game design is naturally a highly-coupled, incohesive problem space that is poorly suited to unit testing.

Post reply on HN