Branch for the 5th episode. This evolution step doesn't bring any groundbreaking changes. It is a sum of several refactorings aimed at further unifiyng some functionals. The stars of these refactorings are:
- Move and Model got rid of their hardcoded dictionaries for Moves registration. Instead Moves contatiner now has that functional and it constructs this dictionary automatically by accepting its Move children on ready. Additionally, this container now holds fields for export, like mode, skeleton, combat etc, if our Moves need them to be present in access. This limits our "drag an drop" routine as all contained Moves are getting their exported fields filled on tree creation phase as well.
- I enchanced the transition logic flow to better suit comboing and forcing moves. No conceptual changes, just improved readability and more synergy with backend animations framework. Old algorithm: force forced move if present, then check combos and just leave queued move as is, then activate default lifecycle. The old approach does all the same, but every state that utilises comboes and queued moves starts to have annoying code in the transition, that uses the queued move. New approach: Move gets two new fields, accepts_queueing and transitions_to_queued. They are "backend-animated", accepts_queueing automatically kills all the tasks of panic click prevention timings customisation or dynamic queueing windows. Transitions_to_queued is essentially a single timing of false becoming true at some point of the states lifecycle. Now new flow check_relevance works as follows: first we check combos for the last chance to queue something. Then if the state is ready to transition to queued, we don't transition to the stored queued move, instead, we are trying to force it (in case we were queueing the second hit in the series, but we already must die, we want to die, not to transition to the 2nd hit). Then if forced move is present, we force it. If not then default lifecycle activates.
- I created and ultimate Attack Move. It's a Move that is a scene, and it can be turned into literally any melee attack for your game if you have an animation asset for it. It is achieved by unifying attacks behaviour and pushing weapon hitbox manipulations into backend animations as well. This way Attack just needs a skeleton animation name to play and a corresponded backend animation name to "play" to manage its damage, parrying, poise windows etc. Finally, I created a small tool script for root motion baking from unrooted animations into Vector3 value track that is... Of course stored in backend animation as well.
These changes mark the end of the base controller journey. I retargeted default branch to this state and I will leave this project unchanged in the future. Next series will use it as a starting point, but will probably be a separate repo not to breed any branches further.