I agree. It's a historical document of how 2000's-era game developers were grappling with making much, much larger codebases than before, and, because everyone

I agree. It's a historical document of how 2000's-era game developers were grappling with making much, much larger codebases than before, and, because everyone in undergraduate CS was learning from a "Java school", it addresses them specifically. The concepts in it that I still find useful aren't really OO at all, they are just data structures and algorithms: stacks, buffers, formalized ways of handling state. The engines are useful, but mostly on the front of getting a lot of I/O problems out of the way and doing some stuff to bundle and automate common assets and rendering methods. If you deeply care about any specific part of your game you end up writing your own thing that works around the engine instead. In that respect I dispute the parent's idea that adding some compiler tech is useless - it's one of the essential methods of tools development. It just does not have to be very sophisticated to get the job done - Cave Story, for example, just has a little token reader for the "T-Script" cutscene scripts. That is the right size of tooling for a lot of games. The basic rule of thumb to apply is that in-house tech only needs to be good enough to express what you already designed in a paper document, or to parse some spreadsheet data. The external documents will be more flexible for revisions than any slick UI you could build, and the type time of coding it is a minor detail relative to the design time. That assumption only changes on some relatively vast scales.