Recently I did a performance comparison between Coherent GT and UMG and by doing so I gained insight on working with UMG. I’d like to share my first impressions with you, guys. As I was feeling more comfortable in the HTML world I started by prototyping the interface using Coherent GT. I moved with small steps at a time – after finishing one part of the interface (such as nameplates or the group member panel) I was implementing it in UMG.

Getting started

Implementing the nameplates, for the most part, was straightforward in both technologies. The only exception was that in UMG I had to save the value of the progress bar in a separate variable. It was possible to set the value but there was no way to get it back (This has been fixed in v. 4.6). I dealt with some minor inconveniences along the way – mainly how confused I felt about the UI of the UMG’s editor. For example, changing the fill colour of a progress bar is done in the following way: Appearance -> Fill Color and Opaque, whereas changing the background color is done in an entirely different menu – Style -> Background Image -> Tint. There was also this funny bug that drew the sprite sheet containing all the icons which the editor uses when I mistakenly changed Style -> Background Image -> Draw As to Border instead of Box:

The difficult part

I decided to do the inventory next and in a couple of minutes I had it completed in HTML. When I started working in UMG I faced a serious trouble – I had to completely change my mindset. It’s been a long time since I last used a layout system other than HTML’s box model (I used to work with WPF and WinForms once upon a time) and the transition to UMG’s layout model was challenging. The most difficult part of the transition was the container fest that UMG comes with. The entire system is designed around putting stuff in panels, grids, and boxes. They are the only way to layout your elements without falling back to absolute positioning. Even setting a border requires the usage of a container. This has the unfortunate consequence of making the navigation of the hierarchy of elements cumbersome. The visual selection also presents a problem because often you end up selecting the element’s container when you meant to select the element itself or vice versa. HTML copes with this problem by:

1. Not making you create additional elements in order to style your UI
2. Giving semantic names to the elements – when you see a li you already know that you are looking at an element of some list. When you see a HorizontalBox nested inside a VerticalBox you don’t gain any information about the current context.

Our inventory is basically a table, each cell of which is an image with a border. Producing the table in UMG doubled a number of elements in use since every cell was necessarily nested inside a Border. This also increased the needed micromanagement to get everything working. Whenever I had to move an item or change its dimensions, I had to keep in mind to be careful with the element’s siblings and parents (and whether to move the elements themselves or the border around them) as they would very often move unexpectedly. After completing the basic inventory I thought I might change the background of the item, currently hovered with the mouse. It took me 3 lines of CSS and a moderately sized Blueprint graph to accomplish that in UMG. This made me realize my favorite feature of HTML – its flexibility. I can’t think of an interface that cannot be recreated using HTML. For example, this guy made Mozilla Firefox’s UI in pure HTML. On the contrary, thinking outside the box is difficult in UMG. You are severely dependent on what Epic has exposed – consider:

• the missing GetPercentage method mentioned above
• the lack of reusable styles
• UMG’s positions and sizes are measured using a special unit and don’t support percentages / pixels which can be incredibly useful

Putting limits on your UI designers’ imagination will cause either:

1. A redesign of your UI so that it fits in the creative bounds defined by the system in use.
2. A lot of hackery workarounds.

After completing the inventory, I pushed my demos to our git repository and asked around the office for an opinion on its design. A colleague of mine answered the call, pulled my demos, moved a few things around and uploaded his changes back to the repository. When I downloaded locally his changes a problem emerged – the UMG-based project had a merge conflict that git could not resolve since widgets are binary files and I had to apply the changes manually. There were no other significant problems and I managed to finish the rest of the UI soon enough so I’ll skip the boring details.

Wrap-up – Coherent GT or UMG?

HTML is a mature technology that’s being developed with the help of many big corporations (including Microsoft, Google, Apple, even Adobe!) in order to provide the best product to the end users while easing the job of the developers. This results in a faster, smoother and more productive workflow. We should acknowledge that UMG is still “a work in progress” and needs time to catch up on missing features and usability. In the end, here’s the major conclusion: I spent about an hour creating the HUD using Coherent GT from scratch and about 3 hours doing the same thing in UMG. This makes me wonder whether my inexperience caused the delay or the problem is really in UMG. What do you think? Have you tried UMG and Coherent GT? Tell us in the comments below, on the forums or twitter!