Update 2: The Grappling Hook
When we started with the earliest prototype of hake we had two core mechanics we knew we wanted to include: the shield and the grappling hook. It offers a satisfying and agile way to navigate the game world, and combined with other game elements allows for a (hopefully!) varied game style with multiple approaches to obstacles and multiple tactical solutions to combat. As a bonus, our randomly generated levels can get away with certain sets of map chunks that would not be traversible without the hook.
Simple vector approximation
First starting out, we had no idea how to make this sort of thing in Unity. As usual, we started with google but found mostly some stuff using Configurable Joint in Unity, but if I remember correctly we found that it didn’t really match our needs (we probably wanted something simpler).
At that point some of the math from school started to slowly ooze into my mind, and we started prototyping using a simple vector approximation of the motion. Basically, we raycast and store the grappling hook anchor point, and in each frame use the perpendicular vector to the vector from the player position to the anchor point to calculate direction of movement.
Since this is a rough approximation using linear movement, there is a certain degree of drift every frame. This is corrected for by recording the original length of the hook and adjusting player position along the vector towards the grappling hook.
Having the direction of movement it is simple to use some acceleration value to modify speed each frame, to accomplish a pretty natural swinging motion. Basically this means we have a sort of system where energy is converted from kinetic energy to potential kinetic energy. We augmented this system with an “energy loss” were we subtract a bit of velocity each frame, to avoid endless swinging.
To calculate initial movement speed along the grappling vector, we use the magnitude of player velocity times the angle between the velocity and the grappling vector, which seems to work.
Each calculation involving velocity or acceleration uses delta time to allow for frame-independent movement.
To give a nice feel to the game element, we needed to simulate wrap-around of the line around platforms. We achieve this by continually raycasting from player position to grappling anchor to see if the collision point has changed. If so, we push a new line segment onto a stack, and use that for all calculations. When the player swings back, we need to remove that line segment from the stack. We use the same raycast as previously, but using the previous segment as anchor, to figure out when we should remove the line segment. With little effort this method give a very lifelike feeling to the grappling hook.
We are quite satisfied with the feel of the grappling hook, but the game element is like a pole that attaches to where the player points - it might feel more natural if we could simulate a rope more closely. The naive approach from the top of our heads is to use the angle of player velocity to somehow determine when to “disengage” the grappling hook mechanic, allowing the player to freefall until the rope again reaches its initial length, but it seems finicky.
Does anyone have some tips regarding the above? Or any comments on better approaches to the grappling hook mechanic?
Thanks for reading!
Grappling hook works wonderfully, great job! What would be cool to add is if the velocity of the human reaches x km/h (for example 30-50) and the human smashes to the wall, he dies, it could create somewhat a challenge to dodge the borders of the map.
Thanks for the feedback! We've actually implemented fall damage which is tied to the velocity of the player. So, both falling long distances or smashing into walls at high speeds leads to instant player death. However, we haven't yet found a good solution to give some indication to the player when he is in the "danger zone" so to speak.