Question

I’m hoping to develop a basic (at first) custom UI for a game I’m working on. It will be used for the game itself as well as the modding tools. I have looked at the Game State Management Sample, but it just gives a bunch of code with no real explanation as to why things are working. My learning style is such that I have to know the why before I can understand the how if I’m really going to understand something. This is why I would like to get a book rather than just download another code sample.

I can create the visual part of the UI object without any issue (the easy part) and I have an idea as to how I’ll use them (with event handlers) but I’m having a hard time connecting an event handler that is fired by either key press or by mouse click to a button on the screen in XNA.

Any suggestions for books or online tutorials / lectures would be great. Code samples, although appreciated, are not very helpful without an accompanying tutorial or book. On the other hand, tutorials or books without source code aren’t very useful to me either. Also, no ziggyware tutorials please. I loved them, but they are down 🙁

Edit:

An alternative approach I’ve thought of (but don’t like much) is when a menu pops up, it pauses the game (if needed) and displays the menu. Then, whenever the mouse is clicked it checks the coordinates of the mouse click and checks to see if they intersect with one of the menu items. It’s a possibility, but it seems like it’s too messy and I feel like I should be able to tap into the event handlers. In fact, I know I can because the Game State Management Sample used them, although I’m not clear how.

Link

using the tutorial here I was able to understand how to use events with custom controls in xna. I was helped most by part 3, where it talked about making buttons. I then saw it referenced a class in the Game State Management sample (InputState). I read through InputState again and the code that used it in part three and I feel like I understand it fairly well.

Answer 1

As I’ve said in the comments, you could probably broaden your search for GUIs in games in general. I’m not aware of any XNA specific books, so below is a quick overview of general ideas to take from the GSM sample (I don’t have it to hand so class names etc. might be a little off).

See also: Making Sense of the GSM Sample on another stack exchange site, GameDev.
See also: The documentation (MS Word) that comes with the GSM Sample.

---

General Overview:

A general approach that works well and is used by the GSM sample is concept of a stack of screens.

A screen defines what a user can currently see, for example the options screen or help screen or gameplay screen.

Managing the screens:

A manager ScreenManager in the case of GSM manages what screen(s) to draw and when.
In this way it manages the "state" of the game.

The basic state of the game is defined by a stack of screens. When the user drills into an option/menu item it might create a new screen and push it onto the stack. When the user presses back it’ll back out.

The key here is that you only render the top screen (the GSM actually renders more than just the top screen to support screen transitions i.e. fading a screen in etc.). Input is only processed by the top-most screen though.

Managing input

You have a base class that all screens inherit from – GameScreen. This defines various methods like Render and HandleInput. The ScreenManager will call Render on a few screens (probably the top one if fully transitioned and the top 2 if mid-way through), and HandleInput on only the top screen.

The BaseScreen could have a simple implementation of handling input common to all screens, for example, when the user presses B on the controller or Esc on the keyboard it might exit the screen. You might want to instead raise an event at this point called something like BackPressed. In the GSM sample they don’t have an event for this, they just have an OnCancel virtual method and it’s in the MenuScreen abstract class, not the base class. It would be up to deriving screen classes to handle this how they want, either by defaulting to exiting the current screen, or by doing something else (maybe pausing the game for example).

The MenuScreen is a fairly good example of a more complicated basic screen, allowing the user to select items (that could raise an ItemSelected event, or call an OnItemSelected virtual method). They use a small class called MenuItem to manage individual menu items. The screen manages handling input (in the HandleInput event) to catch DPad/arrow key presses etc. to handle selecting different items.