Okay I realize this is kind of a vague question, but here it goes:
I wish to make an animation system in Unity where each animation state is entirely “scriptable” and coupled with the game logic attached to it, where animations are modular instead of being all pre-placed in one mecanim graph, and where all state transitions are handled through code instead of being pre-determined and being triggered through blackboard-style variables. This hypothetical system would replace mecanim completely in my project and would be used for things like character animation, combo systems, etc… You could imagine, for example, that “CharacterMovementState” would be a ScriptPlayable that handles the locomotion animation blend tree as well as moving the character, and “CharacterAttackingState” would be another ScriptPlayable that would handle attack animations, dealing damage and the combo system logic, etc…
The whole point of this system is to make sure that there is no dissociation between an animation and its gameplay logic. So if for instance my sword attack animation gets interrupted mid-swing for whatever reason, the damage handling will necessarily be interrupted too. And vice-versa. I’m not even sure yet if it’s a good idea to couple animation and gameplay logic, but I wanna try it
But anyway, my question is: is this a risky idea? Is this what the Playables API was meant for? Does the API have some kind of non-negligible overhead that would make it “less performant” than mecanim? Was the Playables API mostly just made for cutscenes/set pieces/scripted events without too much effort spent on performance? Am I going to encounter a brick wall as soon as avatar masks, animation layers and root motion start coming into play?
PS: I understand that the API is experimental at the moment, but I’m mostly interested in knowing if this would work in the final planned version