Doom 3 was not only great fun to play, but for the time, was an absolute marvel to look at. Truth is, the Xbox version still holds up visually to some of the better games from the last generation. This is coming solely from a video game player. But Kotaku had a developer come in and write a piece about Doom 3’s source code, and the stuff was apparently a thing of beauty (especially when compared to some other games).
When I was asked to write this article, I used it as an excuse to read more source code from other games, and to read about programming standards. After days of research I was confused by my own tweet that started this whole thing: what would “nice looking”—or “beautiful”, for that matter—actually mean when referring to source code? I asked some programmer friends what they thought that meant. Their answers were obvious, but still worth stating:
- Code should be locally coherent and single-functioned: One function should do exactly one thing. It should be clear about what it’s doing.
- Local code should explain, or at least hint at the overall system design.
- Code should be self-documenting. Comments should be avoided whenever possible. Comments duplicate work when both writing and reading code. If you need to comment something to make it understandable it should probably be rewritten.
He then goes on to explain what makes the code so remarkable, and talks about it in comparison to the game he made DYAD. Makes for one helluva read and makes you appreciate the medium even more.
While some of us may just be gamers and are only able to appreciate the games on a surface level (because we don’t fully understand what goes on inside) this gives us some insight into the gaming world that we don’t normally get. Doom 4 was recently announced officially. Wonder how amazing that source code is going to be.
[Story and image via Kotaku]