No problem MP.
I should clarify that the concepts explained in those books are fairly abstract, and are skewed toward engineering robust, maintainable business software, development tools and APIs.
Games fit in there somewhere as well, but usually a game requires performance to be slightly more important. You just have to draw the distinction and how to apply it.
I'll use an example I've seen around here...
Say you're making a game about submarines, but you're hung up on what technology to use.
Domain design would make you take a step back, and tell you to define what your sub does, can't do and how it interacts with other objects (the ocean, mines, enemy subs, etc.) without any regard to how it will be displayed. It will exist as an imaginary simulation model.
In essense, under this discipline, your game shouldn't care what engine is doing the rendering, and in fact, you should be able to swap out Blitz for Torque for XNA for Render Engine of the Week X by utilizing Interfaces (or "Providers" if you're a microsoft employee) to the render pipeline. A lot of people use place holder graphics when designing games. This idea takes things a step further and suggests "why not use a place-holder engine as well?"
An interesting side effect is that it forces you to concentrate on the game itself rather than getting too worked up over how you're going to present the graphics (which are really the presentation layer).
Once one's happy with the design and engine, THEN can begin to make the code more performant.
I should clarify that the concepts explained in those books are fairly abstract, and are skewed toward engineering robust, maintainable business software, development tools and APIs.
Games fit in there somewhere as well, but usually a game requires performance to be slightly more important. You just have to draw the distinction and how to apply it.
I'll use an example I've seen around here...
Say you're making a game about submarines, but you're hung up on what technology to use.
Domain design would make you take a step back, and tell you to define what your sub does, can't do and how it interacts with other objects (the ocean, mines, enemy subs, etc.) without any regard to how it will be displayed. It will exist as an imaginary simulation model.
In essense, under this discipline, your game shouldn't care what engine is doing the rendering, and in fact, you should be able to swap out Blitz for Torque for XNA for Render Engine of the Week X by utilizing Interfaces (or "Providers" if you're a microsoft employee) to the render pipeline. A lot of people use place holder graphics when designing games. This idea takes things a step further and suggests "why not use a place-holder engine as well?"
An interesting side effect is that it forces you to concentrate on the game itself rather than getting too worked up over how you're going to present the graphics (which are really the presentation layer).
Once one's happy with the design and engine, THEN can begin to make the code more performant.