I wonder if I'm the only one who has in the past felt the need to be able to store a reference to a variable in a rather dynamic type, one that does not exist yet. I have again gone through such a situation. But let's first look at how things are usually done.
A typical case: A state has a switch that looks at a variable's value and sends event 1, 2 or 3 in accord with the result.
The conditions can only lead to the modification of the variable's value as the flow is sent to further states where the variable is set. There is one exit branch per
However, it is not possible to say that if condition 1 is verified, then use FsmVar1, or if condition 2 is verified, used FsmVar2, etc.
There is a way to circumvent this limitation but it certainly implies a considerable amount of acrobatics.
It's possible to use a FsmString to store a reference to a variable by calling this variable by name but it's obviously far from being practical, there is no list to pick from because as usual these plain text fields are invisible to the Graph View's awareness.
Now, it would be possible to create such a list indirectly and manually with a FsmEnum "MyVars" that would contain all the names of the variables we want to be able to switch between.
Then, say, we pick this or that enum value (so that means var_name_1, or var_name_2, etc.), then we convert the value to text, and finally we store that text in a FsmString titled "var reference" for example, strictly to be used with the "(...) FSM [Variable/Type]" series of actions, because that's the only kind of action that allows a user to refer to a variable by name.
This would require a bit more work, chiefly the enum setting up, than using a FsmArray but it would have the benefit of making visible the variables' respective names in a drop down enum list; the array variable doesn't generate such a list, vars must be found by index value and the only way to see the names is by clicking on Debug and displaying their names separated by comas which is not that much readable.
The enum hack is far from being perfect either as it suffers issues with nomenclature.
Even with an enum list such as
var1, var2, var3, var4
it will force a capital letter on the beginning of any name. It will also add spaces between words or between words and numbers. Etc.
In this case, var1 comes out as Var 1.
So the name of the variable that's stored as a string in the FsmString 'reference variable' needs to be reformated to fit with the way our variable is named in our FSM (here, it's called var1).
It's important because there is a tendency to avoid capital letters for variables, especially for local ones. To solve this I would use the custom action String Compare Set Multi to check what the incorrectly formatted name is and replace it with the proper one, which again adds another layer of work. Without this action, the FSM would become considerably larger, literally needing one extra branch for each variable in the list.
THE IDEA
What I'm thinking of is a much more integrated (dynamic) variable type, some kind of placeholder. It would work a bit like a FsmObject but it would be dedicated to work with FsmVars only, and set up so as to define what type of FsmVar it's meant to work with (user's choice here).
Ideally, it could autodetect this type when the user wants to create a new variable from a variable field, but instead of choosing a classical "static" type, he'd choose the dynamic one and this would automatically set its kind of FsmVar to work with to be of the type of this field.
Say you can do a set float value, from there you can create a new variable.
Now you could also create a new dynamic variable to store a reference to any other float variable that already exists in the FSM.
This is strictly to avoid having to create more branching and static visual code when all that is needed by the developer is being able to swap from one variable to another depending on the conditions met at runtime.
Also, this new type of variable should look different in the UI because of its special nature.
An added function would be to allow this referential variable to filter variables by category. Multi-select several variables from the Variables tab* that you want to be used, throw them in a category and declare that category as to be the sole set of variables the dynamic placeholder should work with (requires all vars to be of the same type though).
Now that is very out there in terms of needs in the sense that it might be limited to very few specific cases, but in my game logic there's a core part where it turned out that I had to really stuff some states with heavy action jamming to emulate this level of flexibility, remembering thinking I wish I could have used placeholders for vars instead of being stuck with static references.
It's also true that something similar could be used for Events since, thus far, the only way to add a bit of swapping flexibility in a FSM is to refer to events by name, in plain text, or to store this in a variable without any possibility to pick from a list of recognized events. Besides, in the case of all capitalized events, I don't need to explain to you the extreme pain it would be to rely on the same enum hack described above: imagine trying to create an enum entry corresponding to the event "FOLLOW ENEMY 1" or anything with / in the name too!
So I will leave this out here just in case some other people find themselves needing anything like this and would like to add their own opinion to this.
* this is currently impossible btw. No SHIFT option or else. So this is hypothetical.
