Hacker News Reader

That's not true though. Bad code will manifest in a lot of ways. Affecting players and how they perceive the game. See Cyberpunk 2077, the art is pretty good, but the game is extremely buggy. I stopped playing because of that

Sure, I don't disagree with bugs being problematic. As your example indicates though, games that came out well before LLM coding was a thing still could have buggy code. My point is that the actual behavior of the game's code is what players care about, not the code itself. The code is a process rather than the output, and players care about the output rather than the process used to produce it. Art assets are the output the player looks at directly, so it's not crazy that they might care more about it.

> the visual difference is directly exposed to the player. A sixth finger on a hand is an issue in the way that as line of dead code isn't.

But a line of buggy code will be substantially more impactful than a poorly drawn model. An extra finger on a model doesn’t cause your save to be corrupted or a quest to hard lock.

Buggy code, yes, but that's not what I said. Players never look at the code directly, only the end product, whereas they do look directly at the assets. My point is that the scrutiny likely is (and should be, IMO) on the direct player experience, and that ends up meaning that the code itself being sloppy is only indirectly relevant, compared to the assets that they see directly. The comparable output of the code is the behavior, which is possible to scrutinize more directly in most cases.

But the comparison to code isn’t dead code (that would be akin to what? Idk, maybe excess triangles in a mesh that didn’t need them).

But I disagree with your premise, players ABSOLUTELY look at the output of both the code and the visual art. The code is the thing putting it on screen. It doesn’t matter how many fingers a model has, if your engine incorrectly renders it.

The scrutiny here, and the pushback against it, is actually not even about the result, it’s about the process. Even if the AI art was perfect and could not be distinguished from human art, a large fraction of people would oppose it simply because it was generated by an AI.

A standard mind you that very few hold the code to.

> But I disagree with your premise, players ABSOLUTELY look at the output of both the code and the visual art. The code is the thing putting it on screen. It doesn’t matter how many fingers a model has, if your engine incorrectly renders it.

That sounds identical to what I was saying; the output is what matters to players, not the process.

> The scrutiny here, and the pushback against it, is actually not even about the result, it’s about the process. Even if the AI art was perfect and could not be distinguished from human art, a large fraction of people would oppose it simply because it was generated by an AI.

Yes, and that's what the entire second paragraph (which is much larger) in my first comment in this thread was talking about.

> The difference is that game code isn't something that the player sees or needs to care about

I don't think that's true, I could mention a few examples, the cliché of the Unreal Engine hair style or lights and on the other side of the spectrum, the custom made engine which made TinyGlade what it is.

Game development iterates with what's brought from the coding side.

My point is that the code only affects the experience indirectly because they interact with the output of it rather than looking at it directly. The assets aren't as much of a process as the output themselves.

I'd say the same about the assets then personally? They just interact with the output (3d mesh) and not with the process (modeling).

I'm still not seeing how these are comparable. As a developer, I can come up with the exact details of the behavior I think players should experience and manually write code for it, or someone with no development skills can come up with the exact details they want players to experience independent of the code and have an LLM do it.

For art assets, I would not be able to express the exact details of what it should look like up front to the LLM; I'd either need to implement it manually, or I'd need to let the LLM decide the details of the actual user-facing experience rather than just the implementation of the experience I've defined myself (and manually tested to ensure it's identical). That seems like a fundamental difference in terms of code and art assets; the actual user-facing experience of the output of code is further downstream of the way it's produced than the user-facing experience of the output of art assets.