Game components-game

Game

You have used the game class in the previous chapters, but apart from calling the run method from the program class to start the game and unit test, and using the initialize, update, and draw methods, those chapters do not talk about basic design. Okay, if you just create some simple games, you really don't need to know everything else, but when the game grows bigger and has more features, you may want to consider the overview of classes and the design of classes in the game.

Game usually holds the Graphics Device and Content Manager in the graphicsdevicemanager instance. You only have to create a game instance from the program class and call the run method to get everything started. Unlike the old years of managed DirectX or OpenGL, you do not have to manage your own windows, create your own game loops, and process window messages. XNa does everything for you, because in this way, your game may even run on an Xbox 360 platform without form classes or Windows events available.

It is still possible to access the game window through the window attribute of the game class. This is often used to set the title of the form, change the form size (if the user is allowed), call InterOP for underlying Windows processing, and so on. All of these methods do nothing on the Xbox 360 platform. There is no form, no form title, and of course the form size cannot be changed. As you can see in the previous game, you use the window. Title attribute to set some simple text for the title bar and display the current level and score for the user. The reason you did this is that there is no font support in xNa; to render the text on the screen, you have to create a bitmap and then render every letter. In the next game, you will need this feature even for tetris games, so it takes several minutes to introduce the texturefont class.

It is also worth mentioning that, as in the following example, setting the optimal resolution in the game constructor is feasible by setting image attributes, in this example, Tetris uses the 1024*768 resolution in full screen mode.

Graphics. preferredbackbufferwidth = 1024; graphics. preferredbackbufferheight = 768; graphics. isfullscreen = true;
 

It is not guaranteed that the game will actually run in this mode in the future. For example, if 1024*768 is set for a system that only supports 1600*1200, only the maximum supported resolution will be used.

You already know that the update and draw methods are called by every frame, but there is no overload of the game class itself. How can you combine these new game components? It is time to take a look at the game categories and components of the Russian box clone game (see Figure 4-1 ).

Figure 4-1

The first thing you need to pay attention to is that you now have three game classes, not just one in the previous game example. The reason for doing so is to make the winner game category concise. The basegame class holds graphics manager and Content Manager with graphics device, and stores the width and height of the current resolution you are using in the game. The update and draw methods also process new input, sound, and texturefont classes to avoid updating them in the main game class. Then the tetrisgame class is used to load all the images from the content pipeline and initialize all the genie and game components. We will learn about it later.

Finally, the testgame class inherits from the tetrisgame class to facilitate access to all textures, Sprite, and game components, and starts unit tests only in debug mode. The functions of the testgame class are very similar to those of the previous chapters, but this time it is organized in a good way and separated from your main game class. The tetrisgame class uses several unit tests to ensure that each part of the game is as planned.