Page MenuHomeAnticto

Mutable for Unreal Engine 4 | Create States and data driven user interfaces
Updated 11 Days AgoPublic

Overview

This article explains the steps to go from an existing Customizable Object to a playing character that can be modified with an interface automatically generated from the object data. The article covers the following chapters:

  • Create States:: Create an configure the multiple States.
  • Set UI data: Add metadata to Customizable Objects to automatically create an UI.
  • Access the UI data: Read the UI metadata of a Customizable Object to adapt widgets to the character parameters.
We recommend visiting the Basic Concepts and States pages before start creating any State.

Create States

This chapter covers the creation and configuration of two States: one in-game State and one edition State.

The resulting Customizable Object of this example can be found in the Village Demo in Content/HowTo/DataDrivenUI named "DataDrivenUICharacter".

Assets required

  • A Customizable Object with at least one Group Object Node in the hierarchy
The asset used in this step can be found in the Village Demo in Content/HowTo/RemoveUnseen named "RemoveUnseen" together with the assets that create it.

Steps

  1. The first step is to create the States at the Customizable Object where they are most relevant. Add two States for the Base Object, at the node properties States array.

image.png (322×784 px, 68 KB)

In this example, the Customizable Object has been renamed "Data Driven UI Character"


  1. The second step is to create an in-game state to use in situations where there's no plan on changing properties fast. Name the first state created, and make sure the options "Don not compress Runtime Textures" and "Build Only First LOD" are off.

image.png (508×619 px, 48 KB)

In this example, the State has been named "InGame"


  1. The third step is to create a state to use in a character edition lobby, where many parameter changes are expected. Name the second state created, and make sure the options "Don't compress Runtime Textures" and "Build Only First LOD" are on.

image.png (505×619 px, 48 KB)

In this example, the State has been named "Clothing"


  1. To finish the edition State, add the parameters which are important to this State. To do so, add as many properties as needed in the Runtime Parameters array. For this guide we are going to add all the clothing parameters.

image.png (325×622 px, 30 KB)

In this example, we need three parameters, named "Boots", "Trousers" and "Shirt". Because the Group Type is of type Toggle, it defines an independent parameter for each of its child objects. In the example, as we want to use all of the objects, we add all three parameters (one from each child).

image.png (796×1 px, 184 KB)
image.png (190×519 px, 32 KB)

When the parameter comes from a Group Object with the Group Type of types Toggle, the parameter name is the Object Name of each Child Object.
image.png (256×928 px, 66 KB)
When the parameter comes from a Group Object with the Group Type of types At least one Option or One or None, the name of this parameter is the Group Name of that Group Object.
image.png (178×910 px, 57 KB)
When the parameter comes from a Parameter Node, the parameter name is the Parameter Name from that Parameter Node.
image.png (225×754 px, 86 KB)

Result

This is now a Customizable Object with correctly set States, ready to use under two different conditions by enabling one of its States. It is ready for a game, but contains no interface information to automatically generate one.

Set UI data

This chapter covers the addition of metadata to Customizable Objects to automatically create an UI.

The resulting Customizable Object of this example can be found in the Village Demo in Content/HowTo/DataDrivenUI named "DataDrivenUICharacter".

Assets required

  • One icon image asset for every toggle parameter.
The assets used in this step can be found in the Village Demo in Content/HowTo/DataDrivenUI.

Steps

  1. Choose a thumbnail image for each toggle parameter. In each Child Object Node of the group, inside the Parameter UI Metadata node property, set each chosen image asset as the UIThumbnail property.

image.png (440×740 px, 74 KB)

In this example, the "Shirt" child object is given the "DDUI_Shirt" image.

image.png (439×752 px, 68 KB)

In this example, the "Trousers" child object is given the "DDUI_Trousers" image.

image.png (454×700 px, 62 KB)

In this example, the "Boots" child object is given the "DDUI_Boots" image.


Result

This is now a Customizable Object with UI metadata set, ready to be used by the game in any way it sees fit when generating the UI.

Access UI data

This chapter covers how to read the UI metadata of a Customizable Object to adapt widgets to the character parameters. It includes the usage of the Customizable Object UI metadata to automatically generate an interface that allows the modification of the character and reads the character State to determine what are the parameter values when it's created.

This tutorial does not cover how to create a playable character, a level or how to setup a basic widget. Those are, however, provided, as mentioned at the Assets Required section. How to create a character from a Customizable Object Instance of the Customizable Object that has been made in the previous steps can be done following these steps.
The resulting widgets of this example can be found in the Village Demo in Content/HowTo/DataDrivenUI. The widgets final configurations are "DDUI_Container_Final" and "DDUI_Toggle_Final", and the level final configuration is "DataDrivenUI_Level".

Assets required

  • A level to play in
  • A Customizable Object Instance as playing character
  • A user interface container widget
  • A user interface toggle button widget
The assets used in this step can be found in the Village Demo in Content/HowTo/DataDrivenUI. The widgets initial configurations are "DDUI_Container_Initial" and "DDUI_Toggle_Initial", and are referred to as container widget and button widget respectively in the following steps. The level initial configuration is "DataDrivenUI_Level_Initial", and is referred to as level.

Steps

  1. The first step is to prepare the container widget to know what instance is it working with. To do so, go to the container widget graph and add a variable of the type Customizable Object Instance reference.

image.png (1×1 px, 251 KB)

In this example, the variable name is "CustomizableObjectInstance"

  1. Then, expose that variable on spawn, as it is going to be used when constructing the widget. To do so, make sure the toggle buttons Instance Editable and Expose on Spawn of the instance variable are set to on.

image.png (839×886 px, 148 KB)

  1. Now, when the container widget is constructed, get all the parameters for the current State. To do so, access the current State and get its parameter count.

image.png (845×1 px, 263 KB)

  1. For each parameter, get its name, and from the name, the parameter data.

image.png (614×1 px, 285 KB)

  1. From the parameter data, get access to the name, type and the UI metadata.

image.png (837×1 px, 280 KB)

  1. From the type of parameter, decide what to do. In this case boolean parameters are going to create button widgets

image.png (787×1 px, 248 KB)

  1. To give the button some content, it needs to know what it represents. To do so, the first step is to store that information, so go to the button widget graph and add one variable of type string for the parameter name and another of type Customizable Object Instance reference.

image.png (581×920 px, 126 KB)

In this example, the parameter name is stored in a string variable named "Parmeter", and the instance in a variable named "CustomizableObjectInstance".

  1. Then, expose both variables on spawn, as they are going to be used when constructing the widget. To do so, make sure the toggle buttons Instance Editable and Expose on Spawn of the instance variables are set to on.

image.png (915×835 px, 174 KB)

  1. To create the widget in a configuration consistent with the current value of the parameter, we have to read its current value. As it's a boolean parameter, use the bool value to set the button State.

image.png (795×1 px, 277 KB)

  1. To make the widget use the icon provided, read its value from the UI metadata, then load the resource and set the button icon to that texture.

image.png (1×3 px, 977 KB)

  1. And to complete the button widget, give it functionality. First, go to the button widget designer and enable the "On Check State Changed" event.

image.png (785×1 px, 173 KB)

  1. Then, back to the button widget graph, set the parameter to the value of the button, and update the instance to reflect the changes.

image.png (1×1 px, 385 KB)

  1. The button has to know what is modifying to actually work, so go back to the container widget blueprint, refresh the button widget spawn node, and connect the new input pins to the relevant data.

image.png (694×1 px, 263 KB)

  1. Now, to be able to give the actual instance reference to the container widget, go to the level blueprint and refresh the node "Create DDUI Container Initial Widget".

image.png (401×1 px, 281 KB)

  1. With the constructor input pin exposed, it's time to connect to it the Customizable Object Instance reference that the menu is going to modify.

image.png (620×1 px, 274 KB)

In this simple example, we are interested in modifying the player character, so we first get the Customizable Skeletal Component of the player and then retrieve the Customizable Object Instance reference from it.

You can have the Customizable Object instance reference stored in a more direct or more sophisticated way in your game, it's not necessary to extract it every time from a customizable skeletal component. For example, it can exist before a skeletal component and be used to construct both the customizable skeletal component and the menu that modifies it.
  1. When the container widget, we also want to set the instance to a State in which it will update the relevant parameters faster. In this example, do so by setting its State from the level.

image.png (1×1 px, 405 KB)

In this example, the "Clothing" State is the most appropriate, as it's what the widget spawned after it will modify. The State name is verbatim the defined in the States property of the base object node of the modified customizable instance. We have changed the State before the widget is created so the widget can use the node "Get Current State" to know what it's modifying, but you could organize it however fits your project.

  1. And when the container widget is destroyed, re-set the State to the playing mode.

image.png (771×1 px, 395 KB)

In this example, the playing State name is "InGame".


Result

This is now a playable Customizable Object character in a level with an automatically generated UI that allows to change its parameters at runtime.


Permission to use the DemoUI in your game

The fully fledged UI widgets and blueprints provided as example with the demos is free for you to copy and use for any purpose, including commercial purposes and/or further customize it to fit your needs. This applies to all the widgets and assets found inside the mutable plugin content path: Content/UI/DynamicallyGeneratedGUI_DGGUI.
Last Author
gerard
Last Edited
Fri, Oct 8, 4:03 PM

Event Timeline

ricard created this object with visibility "All Users".
ricard edited the content of this document. (Show Details)
ricard changed the visibility from "All Users" to "Public (No Login Required)".
ricard published a new version of this document.
gerard changed the title from Create data driven user interfaces to Create States and data driven user interfaces.Thu, Oct 7, 12:59 PM
gerard edited the content of this document. (Show Details)
gerard changed the title from Create data driven user interfaces to Create States and data driven user interfaces.Thu, Oct 7, 3:12 PM
gerard edited the content of this document. (Show Details)
gerard changed the title from Create data driven user interfaces to Create States and data driven user interfaces.Thu, Oct 7, 3:31 PM
gerard edited the content of this document. (Show Details)
gerard changed the title from Create data driven user interfaces to Create States and data driven user interfaces.Thu, Oct 7, 3:44 PM
gerard edited the content of this document. (Show Details)
gerard changed the title from Create data driven user interfaces to Create States and data driven user interfaces.Thu, Oct 7, 6:45 PM
gerard edited the content of this document. (Show Details)
gerard changed the title from Create data driven user interfaces to Create States and data driven user interfaces.Fri, Oct 8, 12:24 PM
gerard edited the content of this document. (Show Details)
gerard changed the title from Create data driven user interfaces to Create States and data driven user interfaces.Fri, Oct 8, 1:04 PM
gerard edited the content of this document. (Show Details)
gerard changed the title from Create data driven user interfaces to Create States and data driven user interfaces.Fri, Oct 8, 4:03 PM
gerard edited the content of this document. (Show Details)
gerard published a new version of this document.Fri, Oct 8, 4:06 PM