Live data from Hacker News

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

marianogappa.github.io

211–220 of 236 posts

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

#212

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…

Personally, i don't think the coding part of game development was not a bottleneck. Just try to implement, for example, a hexagon-based isometric game. There are no off-the-shelf implementations -- you'll need to redo the pan / zoom / click controls yourself, you'll need to implement the pathfinding, map layers, interface state machine etc etc etc This is still not an easy task -- to build a somehow complicated game.…

> Just try to implement, for example, a hexagon-based isometric game. There are no off-the-shelf implementations -- you'll need to redo the pan / zoom / click controls yourself, you'll need to implement the pathfinding, map layers, interface state machine etc etc etc

Sure there's off the shelf implementations.

Off the top of my head I would suggest starting with evaluating godot 4.

They have isometric view, pathfinding, and all of the rest you are mentioning.

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

#213

Earlier quoted context omitted.

Personally, i don't think the coding part of game development was not a bottleneck. Just try to implement, for example, a hexagon-based isometric game. There are no off-the-shelf implementations -- you'll need to redo the pan / zoom / click controls yourself, you'll need to implement the pathfinding, map layers, interface state machine etc etc etc This is still not an easy task -- to build a somehow complicated game.…

> Just try to implement, for example, a hexagon-based isometric game. There are no off-the-shelf implementations -- you'll need to redo the pan / zoom / click controls yourself, you'll need to implement the pathfinding, map layers, interface state machine etc etc etc Sure there's off the shelf implementations. Off the top of my head I would suggest starting with evaluating godot 4. They have isometric view, pathfindi…

Sure they do -- but once you introduce at least one custom component (i.e. hexagon map), it's actually not straightforward, how to integrate it with the rest of the controls.

I can't say whether it's me who's stupid, or it's just not very easy to make good UI in game engines. I don't say that's not doable of course -- i'm just saying one would need to invest quite a bit of time to work out how to do this.

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

#215

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…

Getting high level ideas "X but Y with Z" is easy. What's hard is actually understanding what makes X work and how to adapt it to properly incorporate Y. I've played a bunch of games that had Vampire Survivors, FTL or Factorio as their starting point, but failed to deliver a good game loop.

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

#216
post #141

Earlier quoted context omitted.

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.

It'd be quite difficult to deploy the processing power and other resources without an engine.

A 90s PC can't do a complex 3d engine because it lacks the grunt. A 2020s game dev can't do a complex 3d engine themselves because they don't know how to do complex 3d.

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

#217

Earlier quoted context omitted.

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…

> 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 aimed at indie devs to help with the issue of always chasing new projects and making code that's modular enough to be able to reuse it.

But taking a step back, that very much feels like it should apply to entire games, where you should have boundaries between the components and so that the scope of any such pivot is managed well enough not to tank your velocity.

Other than that, it'd be just the regular growing pains of TDD or even just needing to manage good test coverage - saying that tests will eventually need changes isn't the best argument against them in webdev, nor should it be anywhere else.

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

#218

Earlier quoted context omitted.

Why not just copy the mechanics of an existing fun game?

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.

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

#220

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…

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

Could never prove it, but would bet money that Marvel Snap for example is doing it right now.

Edit : oh yeah. A quick google search proved it : https://marvelsnapzone.com/bots/

Post reply on HN