After work, and class, all I think I managed to do tonight was over-engineer my ability visualization system to the point of utter confusion. The goal was to decouple the visualization of an ability from its definition. This will be necessary so that things like "generic melee hit" can be an Ability, but every player class and monster can visualize it differently. In the GIF I posted last night, the visualization of the attack was hard-coded into the Blob class, but I want to be able to re-use the concept of "tween to a position, play animation, and tween back" as a visualization for more attacks (ideally while parameterizing the tween times, and animation name).
After ripping out all the hard-coded bits, creating an abstract scriptable object, AbilityVisualization, and a concrete implementation, GoToAndAnimateAbilityVisualiization, I actually have got the same functionality I had last night working. The only problem is, it's confusing as hell!
The AbilityVisualization SO doesn't know anything about the instance of the entity actually performing the ability, It needs to access the animator and transform of the entity for sure, so why not just pass it the whole GameObject in the BeginVisualization method and let it use GetComponent to find the animator? Well, depending on the hierarchy of the entity, the animator, and the transform to move, may not be on the same object (hint: they're not for the Blob, but are for the Player). Oh, I forgot, the AbilityVisualization also needs to know about the ending position (duh). I'll pass it a Vector3 for that too. Oh, well what if it needs some data from the 'recipient' of the ability? What if it actually has multiple targets?? It's getting very hard to define a clean interface for this.
In the end, I created an intermediate struct, AbilityVisualizationConfiguration, that has 4 fields. The acting entity constructs this configuration before it starts a given ability. The ability, in turn, has a reference to the SO defining its visualization. The ability gives the configuration to the visualization, and now the visualization has all the right components to access. Since the Ability only uses the abstract interface of the visualization, it doesn't care how it's implemented, but says "here's some components I think you might care about,. Go!'. When I explain it there, it doesn't even sound as bad as it is reality. Good grief!
I implemented Ingredients and Tools. Add an ingredient (e.g. a herb) to a tool (e.g. a mortar and pestle) and you can change the attributes of ingredients (well, almost, there is no actual logic for changing attributes but all the containers are ready)
Missing is: Tool UI, UI interactivity, some proper attributes and an Editor for phase transitions (currently it's with lists of custom container classes)
No gif today because you can't see the changes xD
watch them on github instead:
