The MMO Kit consists of the Flash UI assets and the C++ code that communicates the server’s data using an event model that ultimately drives the client view. To demonstrate the integration of the MMO Kit with an existing client-server backend, the kit is built upon a simplistic client-server implementation where server-side simulation generates data and sends updates to the client when appropriate.

The two main parts of the C++ code are:

1. The environment (server) that provides data to the client.
   
2. The client’s communication interface with the Flash content.

In the MVC paradigm, the communication interface between the client and the content is the controller, the client’s data (initially provided by the server) is the model and the Flash elements and ActionScript widgets make up the view.

The code detailed within this document presents one optimal implementation of Scaleform, leveraging the Scaleform Direct Access API to accomplish UI updates driven entirely from native code. However, unlike the HUD and Menu Kits, the MMO Kit combines basic Direct Access API communication with a data binding framework that binds unique string representing backend data to ActionScript UIComponents. Should backend data change, the UIComponents bound to specific identifiers are automatically notified of the data change immediately and can update their views appropriately.

The C++ code consists of the following files (located in Apps/Kits/MMO/ and its subfolders).

Demo

• MMOKitDemo.cpp – Core application built on top of the standard Scaleform Player. Handles platform application implementation and initialization of the Game.
• Game.cpp – Handles the initialization of and the communication between the Client and Server.

C++ and ActionScript Communication Interface

• GameUIDataBindings.cpp – Majority of the definitions for the GameUIAdapter class. This class is responsible for the creation of binding slots for the UIComponents in the Flash content. It handles majority of runtime communication between C++ and Flash content. Also contains much of the Slot (Inventory Slot, ActionBar Slot, Equipement Slot, etc…) processing for updating, dragging, dropping, and swapping.
• GameUIAdapter.cpp – Core of the GameUIAdapter class. High level function definitions for registering slots, communicating with the client, and updating the cast bar.

Client and Server

• GameClient.cpp – Definitions for GameClient class. GameClient receives events from the server and processes them by interfacing with the GameUIAdapter which causes the server’s changes to be reflected in the UI.
• GameServer.cpp – A simple server implementation for the MMORPG. Simulates an MMO server and provides the GameClient with data to display in the UI. Handles messages from the GameClient based on the user’s interaction with the Flash UI.

Runtime Atlasing

• GameUIRuntimeAtlasing.cpp – Provides sample logic that packs a set of external images into a texture atlas as to reduce the overall number of draw calls to the GPU. For the MMO Kit, all of the individual, external images that make up the icons for items, spells, and abilities, are packed into a single texture atlas at runtime. This allows the artist to easily add new icons without creating and managing texture atlases.

The Flash content for the MMO Kit can be found in the Bin/Data/AS3/Kits/MMO/ directory. All directory paths provided in this section will be relative to this directory. A FlashDevelop project is provided, MMOKit.as3proj, which can be used for more convenient navigation and modification of the associated ActionScript codebase.

The widgets that make up the UI (eg. Paper Doll, Inventory, Action Bars) are separated into individual FLA files. Each FLA file provides the graphical layout, images, and animations for a widget. All of the ActionScript logic that makes the widget FLAs interactive is located in the com/scaleform/mmo directory. Each widget has its own ActionScript classes that are divided into sub-folders based on the associated widget.

For example, the Flash content for the Inventory widget can be found in widgets/InventoryView.fla. The AS for the Inventory is located in com/scaleform/mmo/inventory/, where InventoryView.as is the Document Class.

The primary FLA for the kit can be found in the root of this directory: MMOKit.fla. This is the first file loaded by the MMOKitDemo application at runtime. MMOKit.as serves as the entry point for all ActionScript logic in the kit and is primarily responsible for loading all widgets and initializing the ActionScript frameworks like drag and drop.

All of the ActionScript for MMOKit.fla is external to the FLA. The primary AS file is the Document Class for the FLA, com.scaleform.mmo.MMOKit, located in the com/scaleform/mmo/ directory.

The MMOKit class takes care of initialization of the following frameworks and subsystems during its configuration (configUI()), which occurs immediately following the first frame (Event.ENTER_FRAME):

• TooltipManager
• WindowManager
• DragManager
• DataBinding
• GameDataModel

The configUI() method also configures the custom Mouse cursor and loads initial widgets: the Chat Log, Window Menu, Inventory, Action Bars, Nameplates, and Cast Bar.

The MMO Kit includes a CLIK-based drag and drop framework built on two primary classes: DragManager and DragSlot.

DragSlot is the Button-based class that acts as a Button that can hold data which may or may not include an icon. The Button itself can be used to interact with the data within or moved about the UI to other DragSlots. The DragSlot is responsible for initializing the initial drag event upon user interaction. The DragManager handles the attachment of the DragSlot’s data/icon to mouse movement and communication between the original DragSlot, where the drag began, and target DragSlot, where the drag ends. Note that the DragManager must be initialized for the DragSlot component to work.

The DragSlot class is the base functionality and skeleton for all interactive slot elements in the UI. DragSlot should be extended to properly interface the events with the game’s backend. Many important functions, including startDrag() and endDrag(), are stubs. These stubs are designed to be overridden by subclasses implemented by the developer. This allows for DragSlot to be the base class for many different type of slots throughout the UI.

For example, a developer may want a drag that starts in an ActionBarSlot and ends in an InventorySlot to do nothing; a drag that starts in an InventorySlot and ends in an ActionBarSlot to create a link to the inventory item; and a drag that starts in an InventorySlot and ends in an InventorySlot to move or swap the item. By subclassing DragSlot, users can create unique behaviors for each type of slot in the UI.

In the case of MMO Kit, each of the Widgets (Inventory, Spell Book, Action Bars, etc…) has its own implementation of DragSlot. Note that all of these individual classes extend com.scaleform.mmo.core.MDragSlot, a base class which extends DragSlot, which includes basic logic for registering and unregistering the MDragSlot with the GameUIAdapter in the backend..

The MMO Kit includes a basic CLIK-based windowing framework that supports opening, closing, moving, and swapping focus to windows within the UI. The core of this framework is the Window Manager class, which provides functions for the opening a new window, changing focus, and swapping window depth based on the last window clicked by the mouse.

The windowing framework uses the com.scaleform.mmo.core.MWindow class for the logic that makes the windows interactive. The MWindow symbol in MMOKit.fla is used for the visual shell of the basic window: the title bar, and the buttons that allow for resizing and closing the window. The Paper Doll and Spell Book widgets use MWindow class to embed the widget within the context of a UI window.

The MWindow Symbol uses Scale9Grid to embed content of arbitrary sizes without distorting the window’s edges and corners. The background of the Window is a medium sized bitmap which is scaled up or down depending on the size of the content within. Minor artifacting of the background may occur if the window content is much larger than the original background bitmap’s size, however it is only noticeable upon close inspection. For this reason, it may make sense for developers to have background bitmaps of multiple sizes that can be used based on the size of the content in the Window.