Comment by qwerpy
5 hours ago
I browsed through a few random files in that repo. There are high-quality code comments everywhere I looked. AI is the perfect tool to do this sort of thing. Can you imagine a human sitting down and documenting a million lines of decompiled code from a dev team 20 years ago?
Boggles my mind that there is hate for AI in retro-gaming. It's all about making existing things work. If it works and plays well, who cares if Claude did it in an afternoon or some human who spent a year of his life. In fact, I'd rather have Claude do it. Humans will get bored, get involved in community drama, disappear, etc. Unfortunate for the humans who are seeing their life's contribution to the scene made obsolete by a few kilowatt-hours in a datacenter, but good for the rest of us.
the comments are really not high-quality. There's a lot of words in places where only a few would be much clearer.
This isn't to say it's impossible to guide good context-aware commenting style from.an AI, but there would be much terser/usable comments on all of the weapons source for example.
The biggest problem with this stuff is, as usual, that the people guiding the AI don't know what "good" decomps etc look like IMO. AI tool usage tends to reflect ones own tastes and understanding.
Are the comments wrong or just not concise?
I looked at https://github.com/adonis-singh/re4/blob/master/src/wep/objM...
Can't really decipher what line 21 is saying so I concede there could be some slop in there. But the comments on lines 27-30 seem to be informative and give some context that the code doesn't have.
Granted, I'm not an expert on RE4's source code, but the comments look helpful enough.
I didn't say they were wrong, I said they were not high-quality.
Every company works in their own way, but I highly doubt the original source would have a big paragraph at the top instead of a more "structured" comment. Or maybe even nothing at all!
Here's a "counterexample": the pistol code for half life 2[0]. Comments are pretty sparse because it's all relatively self explanatory. The comments that are present are to point out things that are not so.
You end up with something that's easy to work with and where you're not trying to read a paragraph of text that enumerates a bunch of properties of the code in the file in no particular order.
Some things are important context for the whole file. Some things are important context for a fragment of code. Some things ... are simply not that important to note.
[0]: https://github.com/ValveSoftware/source-sdk-2013/blob/master...