koobas.hobune.stream
How would I make a branching attack system?
I've been looking into experimenting with different ideas, just to see what I can learn and how I could apply it or put a twist on it. One of those is a branching attack system (Think Dust: An Elysian Tail where you can either start a normal attack string, or press the attack button and then another one to do a rising uppercut-esque attack, which can lead into air attacks and the like).
I thought it would be a matter of having, say, an array or list that stores the names of attacks and when pressing another button, it would check the name of the attack and what the current number of button presses in the chain would be. I believe that this could work, however I also feel like it would be incredibly sluggish to work on, and difficult to easily maintain depending on how much would need to be done.
Would this work? Or could there be a far better way to implement this?
im guessing u want like a combo system so if u press right right up it does a combo for example.
i havent done anything like that yet but if i had to guess i suggest starting a timer when an input is made. for example player pressses right, a timer lets call it righttimer (ik im very creative) starts counting down from lets say 0.7 secs, then you check for another input while the timer is counting down, and if a timer is counting down then do a different attack. that input will start another timer, for example we got inputs right then left, now the righttimer is on lets say 0.5 secs left and lefttimer is on 0.7 secs left. now we check for inputs again and if righttimer > lefttimer and input up, we do attack X, if lefttimer > righttimer do attack Y.
It is not the definitive answer and not even an advice. It is what I would try to do if I was going to make a branching attack system. I don't believe I am competent enough to suggest the best practice for developing a complex system. I would like to discuss my wild guess however.
I would try to make such a system using unity animator controller state machine and animation events. There are several pros and cons compared to writing all the logic down in code.
Pros:
All the combos and all the branches are clearly visible as well as the whole 'attack tree'.
It is easy to add, remove and modify transitions between attacks.
Easy to modify all the timings and sync function calls with animation: you may call DealDamage() event in exact frame you want, then listen for the GetKeyDown() needed to continue the combo for 0.5 s and then stop listening before recoil ends.
You'll need to make a lot of states for character animation in such a game anyways. Why not use it as a scaffolding for the attack system instead of the other way around.
Cons:
Animator window UI is suboptimal to say the least. You'll go through lots of unnecessary mouse clicks. You can't see transition parameters without clicking on it, you can't see what animation is in the state without clicking on it, you'll need to locate animation file in asset hierarchy to switch off the looping every time and so on.
Animator events are not pretty either. Even more clicks, even more 'blind' UI, function calls may only receive one parameter - a limitation that is hard to circumvent sometimes.
Easy to mess up and hard to debug. You wouldn't know about a typo in parameter name or a wrong function you selected from dropdown menu until you try it out in the play mode. Locating the error in code or animation becomes even more time-consuming.
Animator-based system is more performance-sensitive that script-based.
