3 ms·

The book is a well-written and charismatic collection of the author's ideas andunderstanding of programming in general mostly from an OOP angle, which was all t

The book is a well-written and charismatic collection of the author's ideas andunderstanding of programming in general mostly from an OOP angle, which was all the rage everywhere during 2000s. He also likes his compilers a lot and it shows. And yes, Game Engine Architecture is definitely a much better reference to the core engine building business. But games and gamedev these days is not about that as well. Most of the technical problems are solved by the big engine trio. So all devs do is game rules and logic scripting...

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

crq-yml 3y ago

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.