In this chapter, we have explored many different ways to create a game object. We have seen the problems with using monolithic objects or large inheritance trees. We now know that neither of those approaches scale when creating a large game. They both suffer from the problem of giant bloated classes and dependencies in our code.

We have also seen the flexibility that using the Component Object Model can bring to our games. It lets programmers focus on writing new code, while allowing designers to use that code to create new object types, even at runtime. Since we can now define objects completely in a file, we can create a tool that will let our designer, or even players, make completely new objects, or possibly a new game.

We also briefly touched on the performance issues related to using the Component Object Model. While these can be a problem, it is much better to focus on algorithmic optimizations then very low-level CPU instruction optimizations. We will revisit these problems in later chapters.

For now, let's move on to a design pattern that can help us implement one of the big core engines of our game, as well as a small but important type of component. In the next chapter, we will discover how the State pattern can help decouple our code and can give us a great way to implement artificial intelligence in our game.