http://www.aosabook.org/en/index.html
I've read Spike and Metlslime's and LordHavoc's and well --- obviously --- Carmack's engine code. [And Tonik's and Fuh's and the ezQuake guy's and R00k's and Jozsef's and Grossman's and the QIP Quake people's and MH's and leileilol's and qbism's and frag.machines's and the Flash Quake guy's and the PSP people's and Sleepwalker's SDL stuff ...]"Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well—usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another's mistakes rather than building on one another's successes.
This book's goal is to change that. In it, the authors of twenty-five open source applications explain how their software is structured, and why."
Since I don't have anything useful to contribute to the topic of the thread, I'm going to note things I have noticed about other people's code:
1. Spike uses #ifdefs everywhere. They cannot be relied upon fully, but as far as I can tell, he uses them to mark experimental code or code that he did not fully trust at some point. FTE contains some of the greatest engine achievements, but the only one that truly boggles me: How the F did he do 24-bit color in software? Now ... the reason I wonder this ... unlike most implementations, you really cannot write that one piece at a time. Well, actually now that I think about it, I can imagine a couple of ways to phase it in but it still requires massive changes in several places simultaneously to make it happen. FTEQW has a dramatically high amount of radical feature experimentation compared to other engines.
2. Metlslime types a lot of notes into his code. He'll unwind a mystery and then document it into the notes. I suspect that the way the code is designed that he made detailed planning documents in advance because the organization of the code is too "perfect" to have evolved. His engine coding is like his mapping, there are no misaligned textures.
3. LordHavoc is a fan of delegation. He likes formulaic-ally breaking down what is really occurring and outsourcing it into several different functions and structs and arrays. And adding cvars to control the behavior. In the older days, if you look at each version of the code, you find him tackling stupid things that clearly annoyed him [10 years before most people thought of them ... like the option to die with your view angles "normal".] In the more recent versions, he tackles things that annoyed him more recently [true type font, for example]. The code is often hard to follow like complex C++ because operations have been broken down into so many functions and arrays it is difficult to picture the data flow and see the big picture. Nevertheless, the approach to handling several issues is invaluable and if lucky enough ... the comments are very good but they do not last for long from version to version. DarkPlaces is clearly influenced by Quake 3, model formats, server browser and server self-reporting technology, OpenGL rendering techniques in additions to address what LordHavoc clearly perceived as the weaknesses of Quake like memory management.
4. ezQuake peoples. The code is written by many different authors in a very structural and easy to follow way and commented well ... and clearly reviewed by several different eyeballs. Next to FTEQW, probably the most useful codebase to follow. ezQuake suffers from unbridled feature creep, probably because a great many "cool" ideas have been simultaneously implemented leading to an in-cohesive experience.
5. R00k. Comes up with a fancy idea, codes it. Worries about bugs later. This is actually the true spirit of experimentation, which is why Qrack has a lot of unusual features and also unsolved mysteries. It is the highest net experimentation engine for standard NetQuake, with hordes of invaluable ideas brought to fruition.
6. Leileilol. Coding changes from the mind of a true modder. Includes QuakeC extensions that are likely important to unique mods and have changes reflecting a great knowledge of historical tool resources.
7. MH. The most likely source of code that operates without error the first time. The code is tutorial quality in the sense that all options and conditions have been anticipated and dealt with. Usually the first release is also THE final release as a result. No stone is left uncovered when MH is done, barring advertised alpha and beta releases where you know he is fielding for unknown factors to emerge ... but he knew they would emerge.
8. Tonik. When I look at his source code, I have the feeling he is far more conservative than average as he solves functional problems and I think he loves Quakeworld but hates modern Quakeworld. Tonik has a huge laundry list of solved problems and advancements in the early days. He was clearly a proponent of reliability and operational stability, with a side goal of bringing all the feature of NetQuake into the Quakeworld domain (single player, NetQuake mod compatibility but with Quakeworld physics etc.) But his engine work doesn't focus on excessive bells and whistles like, say, ezQuake but feature-set expansion. Vwep support, Quake 3 support, removal of efrags etc. I get an old school Quakeworld feel from his code.
9. PSP Authors. The PSP engines feel heavily influenced by Quakesrc.org posts and tutorials [QuakeSrc.org was fully operationally during the development cycle of the primary historically PSP engines]. The PSP engines have a flare for optimizing use of the PSPs controls (on-screen keyboard, many ways of dealing of with the analog stick ... a mini-joystick in the form of a slightly slidable button).
10. Carmack of the 1994-1999 era, as far as I can tell --- if you view "DOS Quake" as one true Quake, it is clear he wanted it to have it "all". The engine is both a clear demonstration of "group brainstorm" as it contains high quality implementations of several experimental ideas [some of which you can imagine John Romero saying in some pizza meeting insisting the engine has gotta do this or that]. The engine has a ton of different layers of "systems" all over the place and the 3D math to back it up. The ideas of everything from physics, independent entities with properties and think functions and in the GL version --- shadows, mirrors and transparent water --- to framegroups and skin groups -- a command console and scripts and multiplatform design and the support for several different "model formats" --- even if these were brush models, alias models and sprites --- and client side particles. Historically, thinking of the difference between Doom II and Quake ... and the completeness of the network protocol (even if bugged and dialup inefficient) ... it is bit difficult to grasp the idea that all of this change was in a single generation of engine advancement --- and that it worked and was operationally bug-free. And that it runs on DOS! Or that Carmack made the GL version in just a month.