Just finished reading: Game Engine Architecture

I just finished reading Game Engine Architecture by Jason Gregory.

It was an interesting read for me as an experienced coding developer. The book covers issues generic to any game engines, including consoles (i.e., PS3, XBox 360), issues specific to the hardware design such as endianness, differences of game engines across different types of games, and how a game team or game designer needs to think about engineering their own games. It also covers some of the basics of what every team and individual needs to have and use as part of their personal software development process (version control and how that affects configuration control, including coding techniques to use during development and debugging).

I particularly found the diagram of runtime engine architecture of interest, as it gave a visual to the conceptual issues of how to chunk game specific functions and engineer solutions to common game problems.

I also was somewhat relieved to find some of the tools I've been exploring for my own development were referenced and noteworthy. It also confirmed my concern that content creation is going to be the biggest issue in terms of creating a product.

Other useful tidbits for me were discussions on the core master control routine that calls and controls all the other game functions, discussions on resource metadata and model and art databases separate from or as part of the game itself, how to flag those resources in-game during play-testing or debugging via a suggestion of a debug drawing API, how to think about subroutines called out from the master control routines as it relates to multi-threaded or multi-processor programming, a lot of math related to 3d surfaces and objects (that has caused me to go and chip some of the rust off of my math skills), and finally, most interesting to me because of how it might affect game play of some of my ideas of how I want a space game to work, discussion on collision, in-game physics, and how that relates to the in game 3d models and bounding surfaces of those 3d models.

I've also noticed that I have difficulty in scanning through code samples and reading about pointers. Luckily, I've kept at it and found a few basic examples to help me muddle through understanding how the semantics of writing them in code (dereferencing) was confusing me - not the concept of pointers! Thanks to Bart K. and Free Gamer as well as a fun trip through high simplification at Learning C++ Pointers for REAL Dummies!

My Spoon Is Too Big!

How do you eat an elephant? As the saying goes, "One bite at at time".

As a "new" developer, it is mighty tempting to bite off more than one can chew. When we are new to a discipline as complex as modern computer programming, it can be hard just to figure out where to start. We don't know how much we can eat or how much we can stomach in one sitting!

I've saw a development posting for someone asking how to make a text-based navigation, similar to what was used in the classic Zork or Adventure text-based games: "go north", "east", "up", "climb", etc. This computing "problem" has been solved many years ago, but learning how to reason out a specific design, the specific way to code, takes some understanding and learning.

I too have been trying to get through as much material and reading as much as possible in hopes to speed up the "eating of the elephant". I have some awareness of the large amount of work ahead of me. But some days after setting and finishing my reading goals, reading the responses spooned out from other developers, I can't help thinking that perhaps it isn't only a matter of simply keep chewing but instead I don't think they same way as they do (perhaps I am a banana)!