I spent a few hours looking into redesigning the User Interface for Satellite Simulator (a game i’m working on in a team of 4) we are looking to make the design a lot more intuitive and “juicy”!

The first thing I looked at were borders, boxes and images within the button, image and border components., the plan was to create a style which allowed custom borders and fills to be selected and edited on a game-wide basis.

Here’ were i got to:

Pasted image at 2015_10_06 11_30 AM

The way that Nick Darnell recommended it should be done now that slate brushes are no longer supported (which originally allowed UI- Wide alterations) is to create a unique widget for the “style”.


Step 1:

Create a new blueprint widget.

Create the following hierarchy.


In this hierarchy, we see a border which s used for… you guessed it… the border! And an image which acts as the “fill”. These two components have independent settings which require them to be seperate parts:

The border was set to the “box” setting, and needed a margin to allow dynamic scaling (i use 0.1 based on my image – you will have to play with this) and the image needed to be set to fill.

The margin allows the border to scale when the style is used in the UI (it maintains the pixel ratio of the margins of the image based on your margin setting, and stretches the parts outside those margins).

Step 2:

Now you will want to add this to your “Main UI” or wherever its required, the unique widget style can then be used multiple times, and you will only need to edit the unique widget to make changes to the whole interface.

Create the following hierarchy:


In this image you can see how the button in my UI holds the unique style widget, I use an overlay to add elements such as text above the base style.

I use the built-in button style settings to change things like the hover tint, and pressed tint and padding.

Step 3:

Now that your style is setup, you can begin editing it from the original widget:


Here I’ve changed the fill in the base style widget to a grid, but you can see an important error in the workflow, the fill does not “always” fit the border, depending on your border, because it is simply a square component set to fill.

The Solution:

I started by using a material instead of straight up textures set inside the UMG editor. The benefit here includes a plethora of animatable options within the material editor, such as panning (which i used for the fill) and even “dynamic material” graphs to be set upon events in the game, such as a new reward icon flashing on screen.

Another benefit of using materials is that you can store your texture assets in layers on each texture in the RGBA channels, reference them through the material editor and essentially “build” a new ui using a master material and material instances.

Solution Step 1:

widget_layers1 widget_layers2

These two examples show the how I’ve now got 8 usable borders/fills available for compositing with the material editor in unreal engine 4.

To export a 4 channel Targa from photoshop, you can create an 32-bit RGB colour space image, add a mask in the channels window, and individually select and paste graphics to each layer, export as Targa after.

Solution Step 2:

Setting up the material in unreal engine 4 is based on how you’ve set your texture channels up and how you want to animate / display / customise the final image.

Optimise your textures for use with the UI as so:


Add your textures into a material graph (set to translucent).

Solution Step 3:

Setting up the material takes a bit of doing, and may be different for everyone based on how you’ve set up your texture channels, but the essential idea is this:

  1. Set your Fill style
  2. Set your Border style
  3. Set your alpha/opacity based on the fill and border styles
  4. Add them together and clamp
  5. Apply to translucent material

As seen below:

Emissive channel setup –


Opacity channel setup –


The parameters used in the material offer the following customisation for the UI:

material_2 material_1

Solution Step 4:

We now create material instances, and set parameters accordingly which will then change all elements which use the instance within the entire game.


Solution Step 5:

The next step is to make sure that each material “TileX” and “TileY” is initialised based on its screen size.

To do this, create an array of your button widgets and get their size, and then set their dynamic material instance parameters for TileX and TileY:


The final result can be seen below, and scales the “fill” area dynamically on the “event construct” of the main ui:

finalButton final button 2

Although this is not 100% ideal when having to create a new instance when tiling needs to be edited, we can still get the following benefits:

  • modify large portions of the UI quickly
  • minimize texture usage
  • create unique effects within the interface

Future potential:

  • Optimise texture usage by creating a larger 4 channel “atlas”
  • Modify the base material to access specific UV coordinates for each mask
  • Edit parameters to use different atlas areas