Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>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).</p> <p>See also: <a href="https://gamedev.stackexchange.com/questions/6793/making-sense-of-the-game-state-manager-tutorial">Making Sense of the GSM Sample</a> on another stack exchange site, GameDev.<br> See also: The documentation (MS Word) that comes with the GSM Sample.</p> <hr> <h2>General Overview:</h2> <p>A general approach that works well and is used by the GSM sample is concept of a stack of screens.</p> <p>A screen defines what a user can currently see, for example the options screen or help screen or gameplay screen.</p> <h2>Managing the screens:</h2> <p>A manager <code>ScreenManager</code> in the case of GSM manages what screen(s) to draw and when.<br> In this way it manages the "state" of the game.</p> <p>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.</p> <p>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.</p> <h2>Managing input</h2> <p>You have a base class that all screens inherit from - <code>GameScreen</code>. This defines various methods like <code>Render</code> and <code>HandleInput</code>. The <code>ScreenManager</code> will call <code>Render</code> on a few screens (probably the top one if fully transitioned and the top 2 if mid-way through), and <code>HandleInput</code> on only the top screen.</p> <p>The <code>BaseScreen</code> could have a simple implementation of handling input common to all screens, for example, when the user presses <code>B</code> on the controller or <code>Esc</code> on the keyboard it might exit the screen. You might want to instead raise an event at this point called something like <code>BackPressed</code>. In the GSM sample they don't have an event for this, they just have an <code>OnCancel</code> virtual method and it's in the <code>MenuScreen</code> 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).</p> <p>The <code>MenuScreen</code> is a fairly good example of a more complicated basic screen, allowing the user to select items (that could raise an <code>ItemSelected</code> event, or call an <code>OnItemSelected</code> virtual method). They use a small class called <code>MenuItem</code> to manage individual menu items. The screen manages handling input (in the <code>HandleInput</code> event) to catch DPad/arrow key presses etc. to handle selecting different items.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload