Hacker News Reader

Comment by pengaru | Hacker News Reader

I never scrutinized the id software source, but man have I seen some horrifying game source. The bar is extremely low.

What's surprised me is that successful, fun to play, and stable enough games have been shipped with such absolute unmitigated disasters behind the curtain.

It makes me question sometimes all the effort(and time) I put into preventing the chaos, when such carelessly bodged together garbage can be perfectly profitable.

View on HN

It's nice when you can have both but I have yet to see a game review that mentions how clean the source code is!

That's usually because the high level gameplay code needs to be incrementally tweaked over months or years based on very subjective feedback like "this doesn't feel quite right, can you maybe try...".

You can start with a great plan, but no plan survives gameplay- and balance-tweaking for very long.

Ideally the lower layers are much more structured though, usually those need to be maintained over a longer time and across games.

You can see places in the Q2 code where it has been incrementally tweaked a bunch. The player movement code got a bunch of changes, and you can see blocks of it that are commented out or have #if 0. There are some comments explaining the thought process, but it’s not very clear.

That garbage code brought about the speed run culture, highlighted by charity events like Awesome Games Done Quick. The speed runner and their crew on stage will explain the latest level skips, wall clipping to avoid tedious areas, enemy weaknesses and exploits, and frame perfect input strings needed to accomplish those. And some will perform speed runs blindfolded with only the audio cues to work with.

That hardly has to do with code quality, but instead that some edge-case "features" were not anticipated by the game designers, programmers and QA team, but "discovered" later by speedrunners.

Sometimes it is about code quality. Defensively written, well-documented and well-tested code would not be as likely to suffer from such bugs.

It's not just subtle floating-point errors either, but also outright wrong maths that appears to work (see [1] for an example), memory leaks [2], buffer overflows [3] etc.

[1] https://www.youtube.com/watch?v=4gNYTqn3qRc

[2] https://news.ycombinator.com/item?id=20410166

[3] https://arstechnica.com/gaming/2021/03/how-to-beat-paper-mar...

I think they made the right trade-off, back in the 90s on hardware that could barely run the game, sticking extra defensive checks to make sure you have not accidentally clipped through the geometry, or simpler ones like making sure you are not running too fast, seems excessive.

They weren't coding for some NASA space probe and they knew it.

Typically you'd put the checks only in debug builds.

The id software source code gets increasingly cleaner for each game I think. I've read the Doom source code and Quake II's. I remember Quake II being very clean and elegant. Doom is not quite there. It's fairly well organized, the functions are generally short and concise, but it's a mess of global variables.

Reply on news.ycombinator.com