UI System

Overview

The widget UI system acts as a layer on top of Unity's immediate mode UI system. It was originally written as a UI wrapper on top of Flixel's widget API back when the client was written in Flash. Flixel had no mechanism for hierarchical layout or message routing and a very limited set of widgets. When the game client was ported to Unity, I didn't want to completely restructure the UI code into Unity's immediate mode paradigm, as that would have been a substantial change. Instead, I wrapped the immediate mode API inside the widget classes I ported to Unity and preserved the overall structure of the UI code.

Widget

Each UI element that can be rendered is a "Widget". Each widget is derived from the base Widget class. All widgets have the following properties:

• Parent WidgetGroup - The WidgetGroup has this widget as a child
• Dimensions - Width and Height of the widget
• Visibility - Whether the widget will get rendered or not
• Local Position - Position relative to the parent widget group
• World Position - Position relative to the root widget group (Derived value)

The following basic widget types exist:

• ButtonWidget - Simple variable sized button widget with label
• CheckBoxWidget - Simple check box without no label
• ImageWidget - Simple scaled image
• LabelWidget - Simple label with adjustable font and alignment
• ScrollListWidget - Simple scrolling list pane with component widget factory
• TileGridWidget - Regular grid of tiles rendered as textures
• TextEntryWidget - Simple text entry with adjustable font and alignment

In addition to these common widget there are specialized custom widgets used for special game object. Some examples included:

• CharacterWidget - Renders an animated player sprite with label
• MobWidget - Renders an animated enemy AI sprite with label
• VisionConeWidget - Renders textured vision cone arc of the AI

WidgetGroup

Widget groups serve two main purposes. The first is define a display hierarchy. A block of UI can be shown, hidden, or moved simply by adjusting the parent WidgetGroup. The second function is routing UI events emitted by widgets. By default, any events emitted by the widget are forwarded to the parent widget group. The messages continue getting forwarded up the chain until the event encounters a widget group with a widget event listener attached.

WidgetEvent

Widgets can emit the following events:

• buttonClick - A button widget receives a press and release
• checkboxToggle - A checkbox widget changes toggle state
• listSelectionChanged - A list box changed which item it had selected
• textInputReturn - A text input box had the return key pressed while in focus
• textInputTab - A text input box had the tab key pressed while in focus

WidgetEventDispatcher

In addition to the common UI events you might also want notification of input system events (keyboard/mouse). This is handeled by the WidgetEventDispatcher. Simply create an instance of this and attach to the root widget group in your view class. The GameWorldView class uses this to drive the custom mouse over cursors in the main game view. The current list of widget events emitted by the dispatcher are:

• mouseClick - The mouse is pressed and released (WidgetEventDispatcher only)
• mouseDrag - The mouse is being pressed while moving (WidgetEventDispatcher only)
• mouseMove - The mouse is being moved (WidgetEventDispatcher only)
• mouseUp - The mouse is released (WidgetEventDispatcher only)
• mouseDown - The mouse is pressed (WidgetEventDispatcher only)
• mouseOver - The mouse cursor entered a widget (WidgetEventDispatcher only)
• mouseOut - The mouse cursor exited a widget (WidgetEventDispatcher only)
• mouseWheel - The mouse wheel scrolled (WidgetEventDispatcher only)

Model-View-Controller

All of the game UI states are arranged into Model-View-Controller classes. A View class is used to setup the layout for the screen, expose UI state mutators, and route UI events to the Controller class. The Model class is used to maintain state about the current screen and manage async requests to the server. When async requests are complete we route data back to the controller. Finally the Controller class manages the main logic for the UI screen, transforms UI events from the View into requests for the Model, and sends data from the Model into the View for display. Controller classes are derived from the GameState class, which gets registered with the GameManager. When the Controller decides to transition to another game state a request is made to the game manager to load the new game state, which unloads the current state.

Game Screens

Here's a brief description of the game screens/game states that exist at present. Each entry listed has a set of MVC classes associated with it:

• CreateAccount - Used to create a new player account. Linked from the LoginScreen.
• CreateCharacter - Used to create a new character for the current game. Linked from the SelectCharacterScreen.
• CreateGame - Used to create a new game. Linked from the SelectGameScreen.
• GameWorld - The main game screen where the game is actually played. Linked to the SelectGameScreen.
  • ChatWindow - Child window that manages the connection to IRC.
  • ContextOverlay - Child UI that drives the mouse cursor changes and entity selection on the tile grid
• Login - Use to log into a player session. This is the first screen you see on load up.
• SelectCharacter - Used to select from a list of existing characters. Linked from the SelectGameScreen.
• SelectGame - Used to select from a list of existing games. Linked from the LoginScreen