Search Unity

Would like some advice on which way to proceed...

Discussion in 'Scripting' started by Kazzack, Jan 15, 2016.

  1. Kazzack

    Kazzack

    Joined:
    Mar 8, 2013
    Posts:
    27
    So I'm making a medieval fighting game in my spare time.

    Got a lovely character set up with animations and some combat logic, obviously I would like the players to be able to have a wide variety of weapons and fighting styles to choose from, the thing is I'm not too sure on how to go about this.

    Currently I have my PlayerCharacter with default animations for a sword and shield setup and fighting style.
    I will stress that I'm not asking anything to be done for me, but merely for ways to tackle this.

    Currently my animation tree is looking like this... animation controller.png

    His idle walk has a blend tree controlling all the different walking animations and the idle, the run blend tree is pretty much the same as walk, but of course toggled on/off for the different animations.

    The way my character is currently set up, is to have 2 different states, a combat mode where the character draws his weapon, has a different set of animations to the normal walk / run and then the extra combat animations.

    What I'm looking for opinions on is, although this works perfect for 1 set of fighting style currently implemented, would this work well for multiple fighting styles?
    Example, currently this is all set up for 1h and shield fighting style, but if I was to add blend tree's and more states for 1h, dual wield, 2h, ranged etc etc... Would this approach still be worth doing, whilst using a seperate Class to manage the current weapon the player holds, what types of animation to use depending on the weapon etc....???

    Does what I'm trying to do make sense.. xD
    Or do I need to re-think my system and find a more organised way about controlling all the animations and different fighting styles. Would love some re-assurance or suggestions, haha.
     
  2. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,694
    Robust character control systems, such as those used in assets like Third Person Controller and Motion Controller, use several layers. From top to bottom, they're generally something like:
    • AI decision-making or player controller input
    • Virtual control input: fed by the layer above
    • Logical body control: translates virtual control input into high level character states
    • High level animation logic: determines how to represent high level character states with Mecanim state machines
    • Medium-level animation logic: Mecanim state machines
    • Low-level animation logic: Mecanim's under-the-hood stuff -- actual blending, etc.
    This division of labor makes it easier to manage big Mecanim state machines. And your Mecanim state machines will get big. Currently you have two sub-state machines: normal walk/run and sword-and-shielf combat. You'll need to create additional sub-state machines, one for each fighting style.

    You can probably share common sub-state machines for some layers. For example, the character might use the same lower body sub-state machine for pikes and axes (the same footwork), but the upper body would use different sub-state machines (thrusting versus swinging).

    You'll probably use transition arrows to switch to different states within each sub-state machine (e.g., from idle to roll to stab). But to switch between different sub-state machines (different weapon styles), it's generally much cleaner to manually call Animator.CrossFade() in a script. Otherwise you'll have a crazy mess of transitions between sub-state machines.

    The logical body control and high level animation layers are typically finite state machines.

    The logical body control layer works on the level of "character is firing a crossbow while running". It doesn't worry about how to represent this in animation. It only has rules about when the character can run and fire, according to its current body state and virtual control inputs.

    The high level animation layer, on the other hand, doesn't have a concept of when the character is allowed to run and fire. It only knows that, if the character is running and firing, it should tell Mecanim to use certain layers and sub-state machines.

    All these layers actually make the whole thing less complicated because each layer has a relatively small, simple scope. This is just one way to do it; hope you find it helpful. Have fun!
     
    Last edited: Jan 15, 2016
    Fajlworks, Kazzack and ADNCG like this.
  3. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    You'll have a much better time using blend trees and nesting states inside others so your tree is very clear, this will enable you to make quicker changes to experiment with.
     
    Kazzack likes this.
  4. Kazzack

    Kazzack

    Joined:
    Mar 8, 2013
    Posts:
    27
    So I kind of have the right idea, I guess I need to go look at some more animation and mecanim stuffand see more of what you mean. Thanks for explaining this way of how to go about it. It does seem very overwhelming starting off :)
     
  5. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,694
    Yup, you absolutely have the right idea with your existing blend trees and nested state machines. The trick with different fighting styles is to make each a separate sub-state machine, usually at the top level of each layer, and use Animator.CrossFade, rather than transition arrows, to switch between them.

    It's true that the whole shebang is kind of overwhelming, but the advantage of all those control layers is that you can take on each one separately. Then the other layers can just treat it as a black box. The old divide-and-conquer trick. :)
     
    Kazzack likes this.
  6. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    FYI I have evolved our way of doing characters pretty much identically to Tony Li's approach, so I can certainly testify it works wonderfully, esp the abstracted input etc.
     
    Kazzack and TonyLi like this.
  7. Kazzack

    Kazzack

    Joined:
    Mar 8, 2013
    Posts:
    27
    Thank you both for your help. One last thing though, what is it that Animator.Crossfade does specifically? Like what are the advantages of using it over the Transition in the Animator window, apart from making it easier to read for de-bugging etc..?
    I did look here http://docs.unity3d.com/ScriptRefer...or.IAnimatorControllerPlayable.CrossFade.html
    But it doesn't explain the advantages or reasoning behind it.
    Thanks again ^^
     
  8. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,694
    That's the only advantage, but it's a big one. Otherwise you end up with this:



    In the developer's defense, Mecanim hadn't exposed CrossFade() at the time of that state machine, nor did it have sub-state machines. Sub-state machines help a bit, but you still end up with a mess of transitions at the individual state level going into other fighting styles.

    Using CrossFade, you can get rid of transitions between fighting styles, giving you something more like this:



    (That's Opsive's Third Person Controller.)
     
    Kazzack likes this.
  9. Kazzack

    Kazzack

    Joined:
    Mar 8, 2013
    Posts:
    27
    Ahah wow. Okay I can clearly see why CrossFade has it's advantages then. Thank you very much for clearing that all up.
    Dam, if I didn't want to learn for myself, Opsive's asset would of been an instant buy, pretty much exactly what I'm trying to make ^^