Coherent UI GT Vs. UMG – An Experience Comparison

Coherent UI GT Vs. UMG – An Experience Comparison

Recently I did a performance comparison between Coherent UI 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 UI 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 spritesheet 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. 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 the amount 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 favourite 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.

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 UI 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 UI GT? Tell us in the comments below, on the forums or twitter!

I Actually use a combination of both … I am currently using HTML loaded off an external web-application server (Re-Spawn and Flow UI) for my User Authentication and Player Leader Board, and Player Statistics and then use a UMG system in the game itself.

I actually find UMG relatively simple to use, granted I can do HTML development a last faster … but I prefer to keep my complexity out of the game and in the FlowUI system. This gives me a ton of benefits … but I am not going to go in to that now.

Should be moved to Feedback Section :wink:

Thank god I’m using Slate C++ and I don’t have to choose. =)

I think I would choose UMG/Slate any time over any other 3rd party solution especially over the one HTML/CSS/JS based. For three reasons:

  1. It’s tightly integrated into engine. It means it will have updates, and will benefit more as engine is progressing.
  2. It’s very, very fast. I don’t need nor want, to hook up almost entire web browser, to render simple or even complex UI element. The only time when I would need that, is when I need to display web pages in game.
  3. Last time I checked Coherent process in games like Plantary Annihilation or GuildWars 2 it was over 300MB! Yeah On my PC it’s not a big deal. But ****! It’s 300MB for actual game data vs just UI.


This comparsion doesn’t really hold up.
Tick in blueprint ? Really ? Transformations in blueprint, iterated by tick ?
I mean ehm.
I wouldn’t use blueprint to anything other than cosmetics and even driven elements of game.

The UMG editor, I would really only use for simple things, or as last step where you configure how things look, with underlying logic coded in C++.

But in anycase will hold off with any further comments, until I will fully implement floating damage number in UMG, and then test how it will really perform with hundreds of items floating around ;).

Some of us aren’t able to write in C++ so we use Blueprint/UMG :frowning: I wished I could write it in C++ but it’s hard to learn, so yeah…not an option for me (yet)

To be fair, one of the main demands of a UI toolset are going to be the amount of programmer time it takes to set up the UI versus an artist or designer. Especially when it comes to things like UI behavior, rather than data or command structures, requiring too much programming time is a major downside to a UI framework. You cannot expect UI logic to be written in C++ to be “expected”. Right now, UMG has several issues, editing-wise and operation-wise (and performance-wise for that matter) that in the short term, something like Coherent could help. The HTML/CSS combination is far more artist and designer friendly, which to me makes it an attractive option as time I don’t spend doing UI support is time I can spend implementing core gameplay systems.