2.3. A RCHITECTURAL D ESIGN I Example approach for game screen management

In lecture exploration of answers to frequently asked student questions

Exploration of an example game screen manager

The front-end to most games will feature a series of navigatable screens (e.g. configuration, high- score, etc.). Additionally, whilst being played, many games will permit other screens (e.g. options screen) to sometimes appear on top of the main game screen. Also, the different levels, etc. within a game can also be viewed as a set of screens. It is desirable to have some means of easily controlling the management (adding, removing, displaying, etc.) of screens.

The following draws upon the Game State Management XNA tutorial Game Engine loop { ScreenManager.Update () ScreenManager.Draw() } Game Screen Update { Update objects() } Draw { Draw objects() } Screen Manager Update () { Update screens } Draw() { Consider screen rendering } The core game engine makes use of a screen manager that is responsible for updating and rendering game screens. The screen manager contains a list of screens to be managed.

Design/implementation highlights of a screen manager class

Aside: The ScreenManager is added to the Game instance as a drawable game component ScreenManager screenManager = new ScreenManager(this); Components.Add(screenManager); public class ScreenManager { List screens = new List (); Stack screensToUpdate = new Stack (); InputState input = new InputState(); SpriteBatch spriteBatch; } The ScreenManager contains a list of managed GameScreens. A stack of GameScreens to be updated is formed each update. Input (InputState) and output (SpriteBatch) setup is handled within the Screen Manager and made available to each screen.

The input state is evolved for the update tick. GameScreens are pushed onto the update stack (screens added last will be updated first) Flags are assigned initial values. public override void Update(GameTime gameTime) { input.Update(); foreach (GameScreen screen in screens) screensToUpdate.Push(screen); bool otherScreenHasFocus = !Game.IsActive; bool coveredByOtherScreen = false; // Update screens... }

while (screensToUpdate.Count > 0) { GameScreen screen = screensToUpdate.Pop(); screen.Update(gameTime, otherScreenHasFocus, coveredByOtherScreen); if (screen.ScreenState == ScreenState.TransitionOn || screen.ScreenState == ScreenState.Active) { if (!otherScreenHasFocus) { screen.HandleInput(input); otherScreenHasFocus = true; } if (!screen.IsPopup) coveredByOtherScreen = true; } } Each screen is updated in reverse add order (those added last are updated first) The flags permit context specific screen update Only the topmost ‘active’ screen is permitted to handle user input.

public override void Draw(GameTime gameTime) { foreach (GameScreen screen in screens) { if (screen.ScreenState != ScreenState.Hidden) screen.Draw(gameTime); } } All non-hidden screens are asked to draw themselves. GameScreens can be added to the manager public void AddScreen(GameScreen screen) { screen.ScreenManager = this; screens.Add(screen); } Aside: It is intended that the GameScreen instance will decide when to remove itself by calling a RemoveScreen method. Think about the usage assumptions this design decision introduces.

Design/implementation highlights of a game screen class

public enum ScreenState { TransitionOn, Active, TransitionOff, Hidden } bool isPopup = false; bool isExiting = false; bool otherScreenHasFocus; ScreenState screenState = ScreenState.TransitionOn; TimeSpan transitionOnTime = TimeSpan.Zero; TimeSpan transitionOffTime = TimeSpan.Zero; An enumerated type of the valid screen states is defined. The GameScreen holds flags defining if it is a pop-up screen (assumed persistent), or if it is currently exiting (valid over several frames), or another screen has the input focus (valid for this update only). A fade transition time for the screen appearing and disappearing is also defined.

The update firstly checks to see if the GameScreen is exiting. If not, it then checks to see if it is a covered screen If not, it finally checks to see if the screen needs to transition on and become active public virtual void Update(GameTime gameTime, bool otherScreenHasFocus, bool coveredByOtherScreen) { if (isExiting) { // Deal with exit } else if (coveredByOtherScreen) { // Deal with covered screen } else { // Check for transition on } } Why is it good to declare this as virtual? Extending classes will extend Update() to provide screen specific behaviour

If exiting, wait until the fade is complete and then remove the screen If covered, fade screen out and enter hidden state Otherwise, if screen is not already active, fade it in and make active if (isExiting) { screenState = ScreenState.TransitionOff; if (!UpdateTransition(gameTime, transitionOffTime, 1)) ScreenManager.RemoveScreen(this); } else if (coveredByOtherScreen) { if (UpdateTransition(gameTime, transitionOffTime, 1)) screenState = ScreenState.TransitionOff; else screenState = ScreenState.Hidden; } The UpdateTransition method fades the screen in / out, returning true whilst doing this and false when finished else { if (UpdateTransition(gameTime, transitionOnTime, -1)) screenState = ScreenState.TransitionOn; else screenState = ScreenState.Active; }

public virtual void Draw(GameTime gameTime) { } The Draw method is declared virtual, with no inheritable implementation – i.e. it’s up to each game screen how it will be drawn To explore this tutorial in greater depth, see the Game State Management tutorial from:

To do: Submit Project Development Report with details of game idea, team, development language Complete setup of development environment (XNA / Java) and play about with some tutorials, etc. Today we explored: An example implemen-tation of a game screen manager