When I began working on this project, I promised to offer my thoughts on how well the book 3D Game Engine Programming has held up over the years since its publication. While I am still far from completing the engine described in the book, as I reach my next milestone, I have some general impressions to share.
I'd like to preface by saying that since I have not worked on a team creating modern game creation tools, my thoughts on this are all based on gut instinct, my limited experience using the Unity3D engine, and a few conversations with other beginning game creators.
With modern computing power, wouldn't it make sense to support more than 20 shaders?
Are there any vertex types that might be missing from these definitions the book recommends?
Over the past week or so, I've been implementing the code that will allow the engine to import (including compiling if necessary) and activate shaders, as well as adjust various Direct3D render states. Therefore, as I was working through the explanations and code samples provided in the book I found myself building in many of the authors' assumptions for things like an appropriate maximum number of shaders to support or what the earliest supported Direct3D shader version should be. And as I did so, I asked myself questions about what could possibly make more sense for more modern systems. What values should be updated? What items haven't fundamentally changed? What bad or outdated habits might I be learning by implementing this code? These are all questions that will require dedicated research and possibly some conversations with experienced game/engine creators to fully answer, but these are my current thoughts:
I think that on an architectural level, the organization of the engine classes, functions, etc. still makes sense and still offers a great deal of insight into what fundamental tasks a game engine must accomplish. Zerbst and Duvel offer valuable architecture-grade gotchas that I suspect still apply to modern engine construction. Additionally, the values of flexibility and simplicity that the book's authors espouse are certainly still applicable for many projects today.
However, where the book falls down, I think, is in the details of implementing something like a renderer. Thanks to many factors (not least of which the long lifespan of DirectX 9) the engine is still going to be functional and still has a fair amount of insight to offer. However, because the book was published in 2004, it will by nature not cover a great deal of features that are fundamental to more modern engines. A solid example that occurred to me through conversation with a friend: in all of the 3D mathematics and collision code I recently implemented, there was nothing that dealt with spherical or cylindrical coordinate math, which leads me to the conclusion that the finished product will be lacking some of the variety of useful colliders that come standard in engines like Unity3D. Also, the ZFX Engine naturally can't take advantage of tools like Shader Model 3.0 or any helpful features of modern graphics cards because they didn't exist when the book was published!
Originally, the book supported Shader Model 1.1 and up. I think it's safe to be a little more up to date, don't you?
So ultimately, I am thinking that this book provides an engine that is quite useful for learning high-level lessons like architectural patterns and the span of what a game engine must accomplish to provide certain basic features. I am hoping that the engine, when complete, will be a useful prototyping tool as well.
However, for other readers who may pick up this book, I would emphasize that the definition of a game engine provided in its pages will not be by any means complete, and they should expect to supplement their reading with additional research if they wish to build a complete and modern engine.