Trying to execute a grapple, What route to go?

So I want to use a grapple mechanic between the user and any enemy it fights. At the same time, It has a huge amount of combo physics to it, so every character has a healthbar above their heads, and each one has a rigidbody and boxcollider attached to achieve this. Not saying that it’s impossible to create the grapple mechanic, but I want to see what routes I can take to execute this in a smoother, proper, transition.

My original idea is to create a grapple object with the user, and when a user grapples an enemy, the user and enemy gets deactivated and the grapple object plays the animation. Obviously, once the animation is done, reactivate them. The biggest issue with this is that the camera, healthbar, and other objects connected to the user get deactivated as well. I’m sure I could fix it, with time, But I’m curious on what other people would do in my situation.

So, What other ideas would you have?

Wouldn’t playing a grapple animation also allow the player to clip through geometry under a lot of conditions?

Tbh, piecing together an animation with gameplay sounds like a lot more trouble than simply getting a healthbar to not be disabled. It sounds like you aren’t too familiar with what’s going on, are you using an asset package? If you are, the way it is set up will probably dictate the easiest option for what you are trying to do.

Shouldnt the healthbar just be a screen space canvas and then position the 2D panel over the head using Unity - Scripting API: Camera.WorldToScreenPoint

Hi guys, thanks for the responses! So I should go into depth a little more on what is going on. Picture an old school super Mario game except the enemies you come across you fight using combos, specials, etc. This is a 2D game, I should note. It’s not an asset, it’s actually a project I’m working on, one of my first in Unity actually. Also, the healthbar is just a small thing, but every enemy you run into has a healthbar over their head, and I haven’t used the worldToScreenPoint mechanic yet, I’ll probably implement that later.

So, I’d say my biggest problem is making things easier down the road. I’ve been doing a lot of restructuring code to make code I’m using flexible with all objects. Simple code like enemy movement, getting hit, targeting the user, and things like extensions for fading or other general game functions.

So, let’s say the user holds the grapple mechanic and I switch to it after a specific collision happens. I’m still aiming to deactivate the enemy and once the grapple is done playing, I want the enemy to be reactivated, and I want to change it’s variables and position, as in decrementing it’s health or changing the enemy’s position and sprite to a knocked down state.

So, if I go down this route, how do I find the enemy I just collided with after deactivating it previously? Is there a way to store the enemy object into a gameObject var through the collision code, where I can then bring it back out after the grapple? And, more importantly, putting all that aside, is this the route I should go if I want to use the grapple mechanic on a common basis?

This is more of a brainstorm for me, so I was just curious how I can do this more efficiently. And I’m not really looking for tons of coding help, it’s more of a ‘what is the right way to go about this’ thing. Hopefully, I put this in a better way

Not really sure this is the right place for you to post this but anyways…

… you seem to be missing an abstraction layer or three.

Deactivating an enemy seems like a very low-level technical detail, instead you probably want to store this as part of enemy state (e.g. state = IN_GRAPPLE). Presumably there would be some control layer where the enemy code decides on its state, with this state impacted (or even forced) by external inputs such as being grabbed.

Similarly the collision code should probably have little to do with this. Collision code might say “I’ve been hit by X” and send some kind of message or store that state each frame, but a higher level control class should be determining based on the collision state, player input, and many other factors what happens to the game state.

This should all be happening quite separately to visuals and animations. There needs to be some touch points, particular if your game position is driven by animation state, but ideally these should be as disconnected as possible.

Thanks for the tip. Sorry for the late response, been busy off the computer for a bit but I’m doing a lot of restructuring for my code so I can utilize this properly. But I do understand how it helps me so I’ll be going down this route. Thanks again