Creating Flexibility with the Component Object Model

In the last chapter, we saw how the Singleton pattern can help us solve the problem of creating and using the big core engines of our game. The engine code is designed to work with any game, meaning there is nothing gameplay-specific about it. So as the game design evolves, we don't need to worry about changes in game design breaking our engine. The goal when writing code for a graphics or physics engine is to make it as reusable or game-agnostic as possible. This means that when you are done making the current game, you should be able to use the code in the next game with very little or no change. The way to do this is to separate the engine code from anything related to the specific game.

Game objects, on the other hand, are completely specific to our game. If the game changes, all our object types will need to change as well. If we are making a platformer and suddenly change to making a Space Shooter, our graphics and physics engine code probably doesn't need to change. However, every single game object and behavior will change. While this may be the most extreme example, the fact is that our game objects are likely to change a lot. So let's look at how we can use patterns to solve this small, but very important, piece of our game.