Thought for The Day
I don’t think I'm really writing a book about how to write games in the context of .Net. I think I'm writing is a book about how to write .Net code in the context of games. As I look over my revised chapter list, I realize that this book could be useful to people without an interest in developing games.
The fundamental idea in my book is that most 3D games use an immediate-mode render loop. The idea is that a game will try to update the entire world and render it as quickly as possible, always trying to use 100% of the system's processor and peripheral resources. The unique challenge for developers with a managed background will be to break away from traditional notions of up-front performance costs and realizing that many actions will incur a deferred cost.
My book will not teach you to write a game engine from ground up. It’s not going to teach you the fundamentals of 3D, or how to implement twenty different kinds of collision detection. These are topics that have been researched and debated and written about with a much deeper insight than I could bring to the table.
To put it bluntly, I’m writing about what I know, rather than pretending at being the last word in game programming. I’m writing about the things that makes managed an attractive option for games: code savings, code generation, maintainability, and so on. But it’s still different than other managed books out there. My book will pay attention to the details that make this book different from a traditional book on game development: managed usage.
I’m taking a risk here. With a few notable exceptions, most “programming 3D games” style books take the reader through an exhaustive series of steps that define all of the game’s architecture and subsystems. I think my book will be more like a “game physics” or a “game AI” book in that I’m adding a tool to the reader’s development repertoire.
Yes, this is an advanced book. I wouldn’t expect you to be able to jump right into a book like this without having a good knowledge of C/C++/C# programming and some pre-existing knowledge of how 3D engines are created. I don’t really expect anyone to take my example source and base a retail game from it, but I definitely think there will be parts everyone could re-use.
I hope my book can maintain focus and not stray into complex subject matter that is covered better elsewhere.