One of my last team’s biggest takeaways from showing at GDC 2016 was that our title’s combat just wasn’t good enough. It didn’t feel quite right and the animations didn’t flow the way players wanted them to. So when I got back to the studio I revamaped that whole system.
Initally all the detecting of collisions was with a collider attached to the player character’s weapon. One of the key breakthoughs was when I instead adopted an approach similar to other traditional 2d games with a number of separate hit boxes synced with the animations. This meant that the animations themselves no longer needed to drive the collisions, which gave the animator the freedom she needed to really nail that more classic feel we were going for.
It also ment building some sort of tool for creating and placing all those hitboxes.
What you see here is that tool after it grew into a whole suite for managing a character’s moveset. A ton of features got added to it, like an edit mode animation preview, spawning effects, sounds, and managing damage, among many others.
It’s a nice showcase of an approach I’ve been using more and more when building tools and systems within unity. Oftentimes when you are trying to do things in a “unity” way, i.e lots of smaller single purpose components, storing your config data in scriptbaleobjects, what ends up happening is it becomes complicated to make a simple change because all the places you need to edit some values are spread out between several objects. So to combat this I’ve taken to focusing on suites of tools around a general purpose. When using the editor to the left, a user is able to edit several components, scriptable objects, and state machine behaviors at once in a single location. Also for all those things I leave their defualt inspectors intact which sort of acts as a built in “advanced mode” if something goes wrong and dev staff needs to drop in quicky to help an artist fix an issue.