Making games in Go: 3 months without LLMs vs. 3 days with LLMs
211–220 of 236 posts
Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs
#212What 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.…
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
#213Earlier 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…
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
#214Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs
#215I 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…
Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs
#216Earlier 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.
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
#217Earlier 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…
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
#218Earlier quoted context omitted.
Why not just copy the mechanics of an existing fun game?
Many people do and then sell nothing
Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs
#219Re: Making games in Go: 3 months without LLMs vs. 3 days with LLMs
#220Earlier 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…
Edit : oh yeah. A quick google search proved it : https://marvelsnapzone.com/bots/