:date: 2023-05-26 15:13 :tags:
You know what would be really interesting? Being God. You know, the omniscient, omnipotent one religions talk about. You might think there is only (zero or) one of those but it turns out that you can in fact be The God of your own universe. I am of course talking about a universe simulated in a computer. (Some philosophers hypothesize that our universe may plausibly be explained as a computer simulation.)
In the past you could write an elaborate novel to very crudely approximate a world building god. For the last half a century or so, computer science has been steadily chipping away at the disbelief one would need to suspend in order to properly inhabit these synthetic worlds. Today you can drop into a vivid three dimensional world, move around with six degrees of freedom in realtime, and more of the salient information one would expect from real reality is present than not. I suspect that being able to bend reality itself to one's whims will prove to be important for the future of our species.
So what about this book then? Well, Game Engine Architecture by Jason Gregory is essentially a conceptual guide to making your own universe from scratch. What do people care about perceiving in their reality? What can be presented for their perception by a computer? How would one organize a computer system to do this ambitious thing? This is the high level description of what this book is about.
If you have the feeling that "reality" is a pretty big topic (literally encompassing everything) then you'll understand why it took me about a year to read this massive book's 985 pages cover to cover. But it was very worth it for me.
Even if you're not going to design your own game engine from scratch, this book will help you understand the design decisions that may seem quite bizarre when trying to tackle commercial game engines. For me personally I was amazed at how helpful this book was for my Blender work. It turns out that Blender's job is to simulate alternate realities in much the same way as a classic game engine (Blender even had a game engine project which is now UPBGE). This book really helped to paint a full picture of the deeper fundamentals inherent in any kind of serious reality simulator, including Blender.
For example, I had been doing a lot of advanced rigging and this book covered the general concept of rigging very well. That may not sound especially helpful since it didn't cover my specific Blender rigging challenges, but to read about the challenges that all rigging systems must overcome and how they are generally designed helped me appreciate where Blender's quirks were quirky and where they were just industry standard — the industry being any of movies, games, computer science, psychology, etc. The book really digs into the fundamentals and assumes you want to properly understand things.
For example, in Blender rigging (and most other systems) there is a concept of "bones" (where an animated character has a rig which is like a poseable skeleton, and the exterior form more or less follows it). Well, I've muddled along posing my bones and trying to make sense out of Blender's baroque feature set related to them but I never stopped to deeply think about what exactly are bones? What are they mathematically? How are they stored? What is really going on? If that kind of thing is something you think you can handle, then this book is very good and it will make the rest of your experience with these topics much easier. If that's not the kind of thing you can imagine dealing with, well, keep on muddling. I'm going to say that if you want to be a professional world builder, the competition is strong and you'll want to be able to tolerate the kind of deep understanding this book can provide.
I personally also found the sections on vector math very interesting. In 2001 I wrote a vector math library for my rendering engine and after reading this book, I want to go back and rewrite it! Years ago Blender made me face the reality of quaternions (the omission of which was a major blunder of my engineering education); this book did a very good job of presenting them properly.
That said, this book is not the best place to learn about quaternions — today this is the best resource to learn about quaternions. This is a somewhat old book; I was reading the second edition published in 2014. I'm sure a lot has changed in game engine architecture since then. But the fundamentals are still the fundamentals and a sign of the quality of the book is that it wasn't too laden with cruft that was only relevant in 2012. Sure, there was a little more discussion of the PlayStation3 dev ecosystem than I'll ever really care about, but since I'm not going to be a PS3 dev it was kind of interesting to retroactively learn some of the things that made that system tick.
There was a very thorough discussion (100+ page chapters!) of topics like animation, collision, physics, world scripting, data architecture, time, rendering, and audio. It was like the most detailed treatment of these topics without going into specifics.
Reading this book solidified my impression that game programmers are
generally about twice as strong as ordinary programmers. I was
very interested to read about CUDA from a game developer's perspective
(remember, all that AI magic you're hearing about now came from tech
developed for game simulations long ago). But this book was written
very early in the history of fancy GPU computing and it also had a
fascinating coverage of normal Intel CPU optimizations (see
/proc/cpuinfo on Linux). Game programmers actually put this arcane
stuff to good use!
My only criticism of this book is not something that I can fault the
author for. He's doing normal nerd stuff when he awkwardly slips into
his old native tongue of blackboard math. Ug. I grew up a native
computer code speaker and speaking blackboard math was always a
foreign language to me. A superfluous pointless dead foreign language
that has no place in a post 1980 computer book. On page 763 he invents
a new blackboard math operator. (For convolution — confusingly
Great, just what we need. Why not also name the book "Ludorum
Machinarum Structura"? Had he instead used computer code, not only
would the concepts be just as clear, but we could take them for a spin
without having to suffer the pointless exercise of translating them.
An annoyance I had with the book is that he kept bringing up the games he worked on (The Last Of Us, Drake's Deception). Ok, great, I'd love to play through those and see what he's talking about in action. But unfortunately his games were the dreaded Sony exclusives which will die of bit rot while other games live on (on Steam).
That said, this is a terrific book. In all those technical pages, I found only two minor typos (746 and 829). Anyone who is serious about simulation, game development, and even high performance computing in general would have a lot to learn from game programmers and this book is a great place to find that.