No replies to this topic

[Sean Cove]

Summary:

UI 2.0 was not only a redesign, but a reengineering of the whole UI system that drives it. Named UI 2.0, but it is the third iteration of the UI, along with UI 1.0, and UI 1.5. To help understand why with UI 2.0 we decided to do a full rebuild of the UI, I need to tell you a little about UI 1.0 and UI 1.5 first.


History:

UI 1.0 was an iteration that much of the general public didn't get to see. It was largely placeholder work to prototype the large grand design of the UI. Many features were stubbed in and non-functional, but it served to show the flow of the final product. This early UI contained stubs for things like Merc Corp management, an Inner Sphere map and a Leaderboard, all of which were non-functional, but you could navigate and see what could be there in the future.

UI 1.0 was also used as a sandbox, for we hadn’t worked with Crytek, or Scaleform UI technologies. We were learning what features Scaleform supports of Flash, and how it differs. Learning how Crytek’s code interfaces with Scaleform, and how to setup the flash screen assets, and communicate with them from C++ layers. It was a prototype build not a generic re-usable system. Only the smallest of flash assets were reusable, such as buttons, display lists, and other components that make up a screen. Much of the C++ code and Actionscript driving the screen layers were built to function for a specific design.

Up To Now:

Then we started work on the current UI in the game, UI 1.5. UI 1.5 has been the version that has gone through the most iteration, beginning with stripping out, and disabling stubbed screens, and reworking many of the existing functional screens. Using the base of UI 1.0, and what we learned about Crytek and Scaleform, to create a few central systems and centralize more of the code. During the course of UI 1.5 much of the Flash layer was rebuilt to fit the new look, leaving the C++ layer much untouched, for it was mostly used to manage and store data from the User and backend database.

Throughout the beta tests, many of the flash screens would go through much iteration. One example being the Mechlab, where in the beginning, all you could change were weapons, armour points, and the engine. There was no upgrade system (artemis, armour type, heat sink types), no paint scheme customization, and no engine heat sinks. The Mechlab must have changed at least once a month, though not all of it visible to the end user. This left the Mechlab code in a bit of a Frankenstein state, having gone through many iterations, with new features and multiple systems talking to each other to manage all the data. So when design started talking about a new UI, a UI 2.0, we jumped at the idea to reengineer the UI systems we were using.


Where We're Going:

Much of the reengineering started before the design of UI 2.0 was complete. Over the course of a few months, a handful of engineers rewrote many of the core systems, with the goal to data drive as much as possible and be able to run as much of the logic for the UI in C++ rather than on the Flash side with Actionscript.

We structured the new system to make the Flash side completely reusable, it became a data display system - with a little screen logic - making it possible to reuse Flash assets in full. Screens became a Flash layer, with a C++ driver layer that can be changed independent of the Flash asset. To accomplish this we centralized many of the systems that were in UI 1.5 into one or more sub systems that were common to all screens. This also reduced the amount of work required to bring a screen online. This has allowed UI 2.0 to separate from the effects of taking new engine drops from Crytek, changes in our backend and gameplay systems without having to change any screen logic, for the UI central system is the only piece of code that talks to and is aware of the systems underneath.

In UI 1.5, many of the screens were directly talking to these systems, which meant that if any of them changed in a major way, the UI would have to be adjusted to bring the UI online again. With all this in place, it leaves us with less maintenance work and allows us to focus more on usability of the UI, rather than keeping it functional.

UI 2.0 was a return to square one, using our better understanding of the systems involved; we rebuilt the foundation of the UI to better support the product as we continue to develop features. The new foundation is more flexible and less specialized, allowing the Designers and Artists the ability to work free of as many limitations as possible.

Please leave all Feedback related to this post here:
http://mwomercs.com/...eedback-thread/