This chapter takes a closer look at the Input class that was used so many times now. Then it discusses the ways to implement a good graphical user interface (GUI) for XNA Shooter. Handling the user input is very simple in XNA because thanks to the Input namespace, you can easily get the mouse, keyboard, and gamepad states with just three lines of code:
mouseState = Mouse.GetState(); keyboardState = Keyboard.GetState(); gamePadState = GamePad.GetState(PlayerIndex.One);
If you don’t have the XNA Input namespace added to the file you are currently working on, go with the text cursor over Mouse, Keyboard, or GamePad and press Ctrl+., which automatically adds the following line to your using directives:
Now you can use these states and check if the gamepad is connected at all, if the space key is pressed on your keyboard, or where the mouse position is currently. This is exactly what you did in the first and second chapter when you wrote your first XNA game.
The more complex your games become, the more often you will have to repeat the same code over and over again. Like the classes in the graphics engine you often do not add more functionality, but instead you make the existing functionality easier to use. For example, the Texture class was used to store the XNA texture, the texture size, whether or not it has alpha, and it also contains many useful methods to render the texture directly on the screen with the help of the SpriteHelper class.
All this is possible with the standard XNA Framework too, but you will have to write more code. If you just want to put one single texture on the screen it would not make sense to write all these helper classes, but if you write many projects and use hundreds of textures you will probably thank yourself for all the helper classes you wrote earlier. Only by simplifying the texture, shaders, and materials is it possible to write complex graphics code in a few lines of code, as you can see in the unit tests of the graphics classes.
The same logic applies to the Input class too. The advantages are not that obvious, but you will notice after a while that writing new UI (user interface) code for your custom buttons or menu controls gets much easier thanks to the many helper classes including the Input class.
Just writing a helper class is kind of boring, and you already know how to use this Input class because you already used it so many times. To get something useful done for your next game, XNA Shooter, you will also program all the UI classes and see the menu logic for the more advanced games shown in this book. The idea here is to reuse the existing Rocket Commander XNA game screen classes for newer projects. Some classes have to be removed and you might need a new class here and there, but the overall program logic is pretty much the same.
The game itself shows the user interface (ammunition, health, points, and so on) in the Mission class just like Rocket Commander did. For more complex games, like the racing game in the next part of this book, the game logic and the UI rendering code is separated into more classes. Like for unit testing you should always make sure that writing your game code is as simple as possible, but not simpler. It does not make sense to write 30 helper classes if all you want to do is to output “Hello World” on the screen.
Game UI and especially menu UI is a big topic for games. There was a time a few years back when almost every game had very complex menu animations or even 3D graphics, but it was very hard to use. You should try to keep things simple, not only for you as the programmer, but also for the user. You learn about a good menu design at the end of this chapter.