The TetrisGame class also holds all game components in the Components property derived from the game class. You can add any class that is derived from the GameComponent class to this list and it will automatically be called when your game is started and when it is updated. It will not be called when you draw your game because the GameComponent does not have a Draw method. You can, however, implement your own drawing methods or just use the DrawableGameComponent class, which does have a Draw method. XNA does not have a direct Draw support for the game components; you have to call it yourself to make sure all components are called in the correct order. Because of this and for several other reasons (forcing you to use this model with almost no advantages, makes unit tests harder, your own game classes might be more effective or specific, and so on), you will not use many game components later in this book. It is generally a nice idea, but you can live without it because you have to create game components yourself anyway and you have to call Draw for them yourself too. Just for the Update method, it does not make much sense to use them.
As I mentioned in Chapter 1 the basic idea is to have users collaborate and share their game components to allow others to use parts of their game engine. For example, a frame counter component or even a fullblown 3D landscape rendering engine could be implemented as a game component, but just because someone does not use a game component does not mean it is harder to copy over. For example, if you have a complicated game component like a landscape rendering module, it will probably involve some other classes too and use its own rendering engine, which might not work out of the box in your engine if you just copy one file over. Either way, plugging in external code often requires quite a bit of refactoring until it is usable in your own game engine. In beta 1 of the XNA Framework a graphical designer was available in XNA Game Studio Express for the game components and you could easily drag and drop components into your game class or even into other game components to add features to your game without writing a single line of code. Because this feature was very complicated, buggy, and did not work on the Xbox 360, it was abandoned in the beta 2 release of the XNA Framework.
It is not a sure thing that game components will not be used, and maybe it does not matter to most programmers that the designer is missing and you have to call the Draw methods yourself. Then a lot of game components might be available and it would be useful to know all the basics about them. In the case of the Tetris game a few components come to mind:
The grid itself with all the colored blocks and the current falling block
The scoreboard with the current level, score, highscore, and number of lines you destroyed
The next block type box for the game
More simple things like a frame counter, handling the input, and so on
I decided to just implement the Tetris grid and the next block feature as game components; all the code is just way too simple for implementing several new classes just for them. If you will reuse the scoreboard, for example, you could always put it in a game component, but I cannot think of any other game I would like to write that uses that scoreboard.
Take a closer look at the Game class and the components that were added to it (see Figure 4-2).
The gray arrows indicate that these methods are called automatically through the fact that TetrisGrid and NextBlock were added to the Components list of the Game class. In TetrisGame.Draw the Draw method of TetrisGrid is called, which again calls the NextBlock.Draw method. TetrisGame itself holds just an instance of TetrisGrid. The NextBlock instance is only used inside of the TetrisGrid class.
You can see that using the game components for these three classes forced you to think about the calling order and it made your game more organized just by the fact that you did not put everything into one big class. This is a good thing and, though you can do all this by yourself if you are an experienced programmer, it might be a good idea for beginners to anticipate the idea of the game components in XNA.