hake devlog #2 news

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.

Line segments

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.

The future

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!