The things that interest me about working in the game industry, I’ve realized, aren’t the things they write books about. They write books about math and APIs and tools. If you want to know how to handle collision between a sphere and an ABB, you can look that up. Or if you want to know all about the latest version of DirectX, you can buy a big paperback with a CD tucked into it, and it’ll tell you everything you need to know. Or if you want to know how to use 3D Studio Max, you can get a dozen books on that. But reading every book on 3D Studio Max won’t make you an artist, and reading every game development book out there won’t make you a software engineer.
There aren’t any books that’ll tell you the best way to structure your object hierarchy. There aren’t any books that’ll tell you whether physics and rendering should share one representation of an object. There aren’t books to tell you the best way to map a script call to an object, or how to keep track of object state in a networked game or the myriad of other tasks that pull an engine in a million different directions, and, if you aren’t careful, pull it quite to pieces.
I really wish that there were such a book, because I know the answers to very few of those questions. Many more answers are out there, of course, passed along in the folk wisdom of the game development community. Some show up in Game Developer magazine. Some are discussed on the GD Algorithms list or SWEng-GameDev. Some people share their answers at the Game Developers Conference.
GameArchitect is my place to share my answers. It’s also my place to share my questions, since I have many more of those. But mostly, it’s my place to share the things in between, thoughts on their way to becoming answers. It’s here to give me a reason to write things down and think things out, lest I forget them. And if anything I write helps out some other struggling game programmer somewhere, that’s wonderful too.