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.
This chapter covers the creation and configuration of two States: one in-game State and one edition State.
This chapter covers the creation of Customizable Object States. As an example, sets up of one playing state to use while playing and one character edition state for clothing from on a Group Object Node.
- A Customizable Object with at least one Group Object Node in the hierarchy
- 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.
In this example, the Customizable Object has been renamed "Data Driven UI Character"
- 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.
In this example, the State has been named "inGame"
- 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.
In this example, the State has been named "Clothing"
- To finish the edition State, add the parameters which are important to this edition State. To do so, add as many properties as needed in the Forced Runtime Parameters array. Name each one of them exactly as the property that must be included in the state. For this guide it's three parameters, as the Group Object Node of group type Toggle defines one toggle parameter for each of its objects.
TODO GMT Update image
In this example, we need three parameters, named "Boots", "Trousers" and "Shirt", the Object Name property of each object included in the group. We need the names of all the objects in the group only because this group is of type Toggle, and this type of group defines an independent parameter for each of its objects, but in the example we want to use all of them under the same state.
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.
This chapter covers the addition of metadata to Customizable Objects to automatically create an UI.
- One icon image asset for every toggle parameter.
- 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.
In this example, the "Shirt" child object is given the "DDUI_Shirt" image.
In this example, the "Trousers" child object is given the "DDUI_Trousers" image.
In this example, the "Boots" child object is given the "DDUI_Boots" image.
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.
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.
- A level to play in
- A Customizable Object Instance as playing character
- A user interface container widget
- A user interface toggle button widget
- 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.
In this example, the variable name is "CustomizableObjectInstance"
- 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.
- 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.
- For each parameter, get its name, and from the name, the parameter data.
- From the parameter data, get access to the name, type and the UI metadata.
- From the type of parameter, decide what to do. In this case boolean parameters are going to create button widgets
- 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.
In this example, the parameter name is stored in a string variable named "Parmeter", and the instance in a variable named "CustomizableObjectInstance".
- 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.
- 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.
- 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.
- And to complete the button widget, give it functionality. First, go to the button widget designer and enable the "On Check State Changed" event.
- Then, back to the button widget graph, set the parameter to the value of the button, and update the instance to reflect the changes.
- 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.
- 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".
- 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.
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.
- 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.
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.
- And when the container widget is destroyed, re-set the state to the playing mode.
In this example, the playing state name is "InGame".
This is now a playable Customizable Object character in a level with an automatically generated UI that allows to change its parameters at runtime.