Devlog: push blocks and rope bridges

This week has been really productive, despite how little free time or sleep I've had.

Nov 3

After refactoring the HUD code a little, I can now request action icons at any time. The climbing prompt now shows when reaching a ledge both from the ground and mid-jump. It was easier than I expected.

The first room of level 2 is complete. I had some issues when exporting the tree that breaks and forms a bridge, but it turns out that I had accidentally reversed its normals in Blender before exporting it. I still have to fine-tune it a bit, because Ternera doesn't quite know how to walk on top of it.

Nov 4

Another prop finished. A block can now be pushed and used as a step to jump over the river. I prepared the code so it can be recycled in one of the puzzles of level 3, Sheerk Prairie. Also, accidentally this happened while programming it. DUN!

Nov 9

I spent the last few days working non-stop on the physics of procedural rope bridges, the first of which were just theoretical calculations, but it was absolutely worth it. Here is the documentation I produced.

 Calculation of rope bridges physics

My bridges are made of four solid segments which rotate and adjust to follow the player's position when they're standing on top of it. The generation algorithm takes the width of the chasm the bridge must cross (w), compensating for vertical offset if there is any, and how loose the bridge must be, given its maximum hang distance (h) when the player is standing right on its center (top left figure).

With w and h we can calculate the length of the four segments (s) and their rotation for this configuration. With s, we can then compute the segment angles when the player is standing on top of the first or third joints (bottom left figure). And finally, when the bridge has no weight on it (right figure), the angles have to be estimated because I spent days trying to figure out how to solve that equation and kept getting complex numbers.

Fortunately, it turns out that the angle value needed for the resting configuration is, for some reason, almost exactly half of one of the values of the previous calculation, down to a difference of half a hundredth of a radian. This allows us to run an extremely fast estimation algorithm that gets the right angle in just about one or two iterations. And for all other possible bridge configurations, we can just interpolate between the already known cases.

 Rope bridge example

It works really well, although I think I can improve its collisions a bit, since a flexible bridge with just four segments is rather wobbly. I have plans to simplify the procedural collider and compensate it with more flexible segments that adapt to the player's position individually. Which is a pity, because then I will no longer need to use the tiniest class I've ever written.

Look how tiny it is, it's adorable

Now, I could instead keep bridges static and most players probably wouldn't notice, so all these calculations seem rather unnecessary. However, they also allow me to make bridges that can break or retract. That's right, the code is fully ready and tested to have them snap when enemies cut them down, usually while the player is walking on them, and allies can help by extending new ones. Broken bridges can also be climbed as rope ladders, which means that enemies can accidentally create shortcuts to higher parts of the level.

I had so much fun designing and programming all this. I've also fixed the last few geometry bugs in the first room of Vecino Forest and have already started working on the second room, the jackalopes' treetop village, which will include both breaking and extending bridges.