Avoiding hardcoded values with Animator triggers Unity-CodePudding

Is there any recommended way for avoiding hard-coded values when updating triggers of a Unity Animator?

Currently I'm resorting to hard-coded variables, essentially copying their name from the Animator editor, and then calling them like so:

animator.SetBool("PurchaseAvailable", isUnlockPossible);

The problem with that, is that the name of the trigger might change, or be completely removed at one point, and then I'd only find about a problem on runtime, or even worse, in production.

Any suggestions will be greatly appreciated.

Thanks.

CodePudding user response：

Unfortunately there are none. They are not variables which can be accessed in the normal var_of_type.name_of_prop_or_var manner. There is an abstraction layer that translates the string to a mapped property that is the actual trigger. If you worked with the AudioMixer, the variables exposing audio properties (such as the volume, for instance) works the same way.

While you could probably make a centralized relationship, such as a Dictionary to map your own name of a property to an internal animator property, the result would still be a string. The difference is it being centralized, one change when populating the dictionary would not impact the code that uses the key, not the value. Still the problem remains that while the code would have less risk, the Animator would still use its own parameter list and thus, you'd need to change it there too.

Still, I don't want to close this answer with a basic "no" without addressing your concerns. You mentioned you are worried that errors would occur either at runtime or on production.

Controlled runtime sessions such as unit tests or full-on testing are meant exactly for this. When playtesting, if your QA team performs proper testing (end-to-end testing, A/B testing and last, but not least, regression testing) they should be able to spot any inconsistencies in code where such problems would occur and in my opinion, it's encouraged as that is one of the point of testing. And if testing is done correctly, the chances of it happening on a final production release are slim.

So for short: while there is no way to automatically check this at build-time, I wouldn't worry about errors during testing, as long as testing follows proper guidelines. However, consider that if you feel the need to change the parameter names too often, there might be a different problem, either in consistency, design or any other area that impacts your development and I'd address that first.

CodePudding user response：

This is not something that you can miss while testing because it will break your game's animation behaviour and you will see errors if you use a wrong string. Just to make things easier, handle from single place and for optimization purposes i would use Animator.StringToHash function.

[SerializeField] private Animator _animator;
    
private const string AnimParam1 = "test1";
private const string AnimParam2 = "test2";
private const string AnimParam3 = "test3";
    
private static readonly int Test1 = Animator.StringToHash(AnimParam1);
private static readonly int Test2 = Animator.StringToHash(AnimParam2);
private static readonly int Test3 = Animator.StringToHash(AnimParam3);

private void Awake()
{
    _animator.SetBool(Test1, true);
    _animator.SetInteger(Test2, 2);
    _animator.SetFloat(Test3, 3.0f);
}

You can also use Animator.parameters at runtime to run some manual checks if you like but i don't think it will worth the effort. If those parameters were also ready at build time then you could definetely use them to your advantage.