Thouhgts on Chooser plugin in UE5

6 min readMar 17, 2024

Hello Unreal Community!
Recently, scouting through Unreal’s roadmap, i’ve seen an interesting page which was detailing a system which can do complex asset selection operations at ease.

Having expirience of my team building a simular system for context based animation selection i was intrigued.

So in this article, i just want to share my finds and gloss over the things that may come in future versions of an engine.

The code with the example of Chooser usage will be on the Github
Enjoy :)

Big Disclaimer

To start off, i want to say that this article should’nt be considered a guide or tutorial of any sorts.
Mostly, it’s just mine thoughts and notes.

Currently, the state of both Chooser plugin and it’s documentation are very rough, to say atleast.

There are a lot of things, at this moment, which really do not make sense from architectural standpoint and/or hard for me to understand, as they are basically incomplete.
As at the time of writing the current version of Unreal is 5.3, and the Chooser plugin is Exerimental.

So do not consider everything to be 100% correct, as most of this stuff are just mine notes and assumptions.

Introduction

At first Chooser plugin provides tools to select specific assets based on pre defined conditions.
For example, if you have a large dataset of assets that need to be picked dynamically based on some input data.

In this case, Choosers will come in play by selecting the correct asset, basing it’s selection on provided input data like gameplay tags, float ranges etc.

Choosers

Choosers are pretty self explainatory. They choose)
But they can be even more than that.

To create and use a Chooser, you’d need to create an assset with a type of Chooser Table.
And to use it, you’d need to call Evaluate Chooser function.

Choosers execute select operations based on provided data and they can also Output data too.
Context data represents what data Choosers receive and output and it can be either Object data or Struct data.

Also, you may notice the “Direction” property. It defines what should we do with the data — take it as an input, output or both

This can be more illustrated on the Evaluate Chooser node, which is responsible for processing choosers.
Depending on the Context Direction setting, it creates supposed pin either for node input or output.

Note. Obviously, this behavior applies only for the Struct properties, as they are passed by value, and Objects are pointers

Where choosers get their data?

Thats a pretty simple question to answer.
If you had used Property Accessor node in animation blueprints you’d probably know what i mean.

Choosers depend of the data they get through FPropertyPath that is bound to the Data Contexts which we discussed previously

Boolean evaluation is binded to Is Enemy property from context

In simple words, we just bind property which we would want to take into account, and at the time of the evaluation — property is accesed using passed in Context objects.

Rows and columns

To the naked eye, choosers UI resembles a Data Table a little bit.
And that is because of rows and columns.
Let’s get to know what those rows and columns do.

Rows — represent the variant of an Output result, that can be choosed
Columns — represent conditions current Row must undergo to be selected

Each row is evaluated from top to bottom.
Columns are evaluated from left to right.

Row output data

Main output of the Chooser comes from its row, and is determined by Output object type and Result type(can be either class or object)

But, row can also perform other actions — like for example, evaluate other Chooser, Proxy table etc.

But only if the Chooser and Proxy table which will be evaluated in this row share the same Context Data structure and Result Type.

Columns and conditions

The conditions list which we can use is pretty standart

Boolean variable (can be true/false/any)
Float Range
Gameplay Tag(must reference FGameplayTagContainer property)
Enum (compare if equal or not equal)
Object (compare if equal or not equal)
Randomize (weighted chance of this specific row to be selected)

Output types are also as follows

Float
Bool
Enum
Struct

Choosers have also a built in debug functionality, where you either manually input the numbers or choose from the assets that are using this Chooser Table

Example usage

The enemies health is choosed using CT_BallColor chooser, which firstly filters if the subject is enemy, and then selects the row by health value.

Then it outputs predefined parameters of the material to the ST_BallColorParameter structure

Players ball material is evaluated in the separate chooser — CT_PlayerBallColor and is picked through randomize.

Couple of words about Proxy Tables

Proxy tables — are inheritants of Choosers, and use the same logic, but differ in one way.

Instead of keeping logic of Context Data, Result type etc. in the same table, they use Proxy Assets — which are like templates/identifiers.

At the time of evaluation, you can provide different Proxy tables with different assets to return

Keep in mind that Proxy Tables do not have complex condition evaluation, and can only evaluate assets based on the Proxy Asset provided.

Although, it’s not entirely clear of what use case it may serve, and i’m just assuming that this is correct way to use Proxy Tables.

You can look at the use cases for those on Dynamic Asset Selection, in the links section below.

Conclusion

At it’s current state, the Chooser plugin remains buggy — filled with crashes and some holes in the design.

But overall it proves a very handfull tool in development, as it has a great potential to solve a lifetime long problem of a complex asset selection algorithms.

Hopefully, we see some things improve in the feature, when Chooser plugin moves to Beta stage.

As for now, that’s all.
If you’d have any questions, or suggestions — feel free to discuss this in the comments.

Sleep tight!