It’s time to say a few more things about our Great Graphical Gear User Interface Library. Boy, isn’t that a mouthful? ::- D.
The G3 UI Library is a simplified, game-oriented alternative to Adobe’s Flex. There are huge differences between what a game demands of a UI Library and what a business applications framework (which is what Flex really is) can offer. The “F” in Flex is for “Fat”. It’s huge, eats up a ton of memory and its a pain to /really/ customize. And by /really/ customize, I mean the enormous differences between the UI of two games.
But this is not to say that Flex is bad. On the contrary. The fat guy has its strengths, but the fact that it was conceived for a certain application domain cannot be changed so easily. Just like the G3 UI Library is not meant to be used for business applications. However, the G3 UI Library could scale up to business while Flex can’t scale down to games.
The class structure of the Library allows for a complete separation of functionality and design, through the use of template methods and other design patterns. The “Skinnable/Metallic” part of the library, which also draws the Widgets, does so using the most primitive objects in AS3 (Shape, Display Object), allowing for a very light memory footprint.
Besides, creating a UI Library was a challenging task and it immediately peeked my interest and I was curious how I could pull it off. I built my last UI library in procedural Pascal 12 years earlier, and naming that, a “UI library” is a not fair, all it could do was square, bland buttons.
I realized that this is no easy undertaking and that I’ll probably have to invest many months of work. But I’ve seen many games which employ Flex controls. They all have the same bugs, the same functionality caveats and the same ridiculous memory usage, sluggish UI performance and poor rendering. I wasn’t happy to take that route.
So, given the poor choice of alternatives for a pure-AS3 UI library, I’ve decided to roll my own! Enter the Great Graphical Gear User Interface Library. What a mouthful, eh? That’s why when we talk about it amongst ourselves, we lovingly call it simply G3 UI.
G3 UI Core
The structure of the G3 UI Lib is based on the trusted Abstract Factory Design Pattern, which is the best structure to use when dealing with User Interface Libraries.
At the core of the G3 UI, we got the G3Director static class, which contains several global management function which control the UI Engine.
Then, we got the Renderer Interface, which allows the G3 UI to be rendered in any kind of Display Object Container (the Stage, a Sprite, a Movie Clip).
The G3Designer Interface is used in enabling the Model-View-Controller way of working with User Interfaces. We do that using Designer Files which contain all the UI code. This is similar to how Microsoft implemented things in Visual Studio. As a matter of fact, the G3 UI has its own special UI Designer which I wrote in C# (compilable with the Mono Framework, to ensure cross-platform support).
Not present in the Diagram segment above is the G3LayerManager, a very useful class: it’s a Z-Index organization engine which is used in all our Flash Games and, now, in the G3 UI as well. The LayerManager is an extremely versatile tool, completely removing the worry of ever calling functions such as setChildIndex and swapChildren.
G3 UI Abstract Factory
Here, you can see how the Abstract Factory pattern is implemented on a few Widgets in the G3 UI. The base class is, of course, the G3Widget.
G3Widget is, in turn, extended into Buttons, Panels, Radio Buttons and so on. These constitute the actual User Interface Elements which comprise the G3 UI Library. But, by themselves, they are aspect-less.
Only the last tier of Widgets can actually be constructed and used. In the above Diagram, you can see the “Barren” variety, while the “Metallic” variety is not shown. “Barren” and “Metallic” are two very different UI styles.
“Metallic” comes with its own drawing functions while “Barren” forces the user to custom draw everything and provide only the names of the sub-components so that the G3 UI Library injects its functionality in them. Actually, this will be renamed into “Inject”, which is more relevant to its real use.
You can see two G3Constructors: Barren and Metallic, but the library supports unlimited customization, which is not only restricted to UI, but also allows modifications in the behavior of the base Widgets.
G3 UI Widgets - Part 1
In this Diagram segment, you can see a part of the G3 UI Widget hierarchy. This part focuses on Panels and Images.
The Image is a rather special case, as it required me to use loosely coupled interfaces to pull it off. This is because the Border of an Image is at the base of both Image and ImageRoller, but we get into considerable (read: impossible to solve) trouble when we wish to conciliate that with the fact that both Image and ImageRoller can have any number of child classes. The result is that the Border class cannot be abstracted unless its extracted from the inheritance chain of Image and ImageRoller.
The solution was to indeed remove the ImageBorder from the inheritance chain. But I still managed to make it inheritable, by using the concept of a Border Renderer, which is a per-Constructor class. Images and ImageRollers require a Border Renderer which to do the border rendering for them.
G3 UI Widgets - Part 2
Here’s another segment from the G3 UI Widget hierarchy. Enjoy it while it lasts. In total, there are about 20 Widgets right now in the G3 UI Library.
UPDATE 2012-01-27: see the architecture in action! Version 0.4 of the G3 UI Library, which is featured in our 2011 game, Alien Invasion, has gone a long way from we were in 2010. Click here to see some Alien Invasion videos.
There is also a fully functional demo of the G3 UI Library^ (version 0.2) on its own website.