Closed ghost closed 8 years ago
Overall I think this is a good idea, the trick is with how we assign the hitboxes to make sure we can actually do them in the animation tab. Maybe we will find it works out just fine. I did have one issue before, which might give an idea on what I am thinking we might need to solve while doing this. When we moved HitBox to be a child of player, the animations for Player could no longer see the HitBox manager functions on HitBox, as it was a separate element. To solve this, I created a pass-through function in PlayerMovement that takes the args of HitBox.hitboxes and passes it to the real HitBox function:
public void setHitBox(HitBoxManager.hitBoxes val) {
//note hitboxmanager is a pointer to the HitBoxManager component attached to this players HitBox
hitboxmanager.setHitBox (val);
}
While abstracting like this, we just need to make sure we can properly set the hitboxes by function calls in the animation editor. Other than that though, I think it would definitely be a good idea.
By the way, should we include HurtBoxManager (will exist Soon :tm: ) in this as well? Since HurtBoxManager is a copy of HitBoxManager, it should be able to be done in the exact same way as HitBoxManager.
Wizardry! Is this an acceptable solution? Code still needs some work, but this should give the idea.
Nice. Yeah something like that looks good. We won't have to have those unused hitbox stubs now for different moves for a character and between characters
Yep, and they will be categorized by an array name, so it should group them nicely.