5 ms·

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,

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.

djmips 3y ago
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!
flohofwoe 3y ago
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.
- dietrichepp 3y ago
  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.
eddyfromtheblok 3y ago
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.
- flohofwoe 3y ago
  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.
  - FartyMcFarter 3y ago
    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 https://www.youtube.com/watch?v=4gNYTqn3qRc [2] https://news.ycombinator.com/item?id=20410166 https://news.ycombinator.com/item?id=20410166 [3] https://arstechnica.com/gaming/2021/03/how-to-beat-paper-mario-really-fast-by-playing-ocarina-of-time/ https://arstechnica.com/gaming/2021/03/how-to-beat-paper-mar...
    - joachimma 3y ago
      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.
      - FartyMcFarter 3y ago
        Typically you'd put the checks only in debug builds.
audunw 3y ago
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.

djmips 3y ago

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!

flohofwoe 3y ago

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.

dietrichepp 3y ago
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.

eddyfromtheblok 3y ago

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.

flohofwoe 3y ago
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.
- FartyMcFarter 3y ago
  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 https://www.youtube.com/watch?v=4gNYTqn3qRc [2] https://news.ycombinator.com/item?id=20410166 https://news.ycombinator.com/item?id=20410166 [3] https://arstechnica.com/gaming/2021/03/how-to-beat-paper-mario-really-fast-by-playing-ocarina-of-time/ https://arstechnica.com/gaming/2021/03/how-to-beat-paper-mar...
  - joachimma 3y ago
    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.
    - FartyMcFarter 3y ago
      Typically you'd put the checks only in debug builds.

audunw 3y ago

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.