An interesting gameplay system that I’ve investigated relatively recently was a climbing system for third person action games. I implemented a dynamic system for one game that ended up not shipping in the final game and more recently I explored a static system with a content heavy solution and there were some interesting details that came out of these investigations for me. Neither system shipped but we had working solutions in both games.
I don’t want to discuss the static (anchor) solution too much as that has been done many times in great detail by a few talented teams. But I would say that it is an immense content challenge, especially if you want to try and match the same kind of climbing experience that the best games currently ship with.
Anchor climbing is what I would call static climbing, something that much of what the Uncharted, Assassins Creed and Tomb Raider style climbing systems depend on.
Anchors can be points, line segments, splines and so on and they are annotated with type of anchor.
The climbing character is attached to an anchor and the anchor can move around so it is not a completely static system but it depends on those anchors for the movement.
The movement from anchor to anchor is a content heavy solution if you want to achieve high quality as each type of anchor requires an entrance from each possible direction and from each other type of anchor you can move from.
The nice thing about this solution is that you can create content for any type of context so like Ubisoft has presented in the past you could use the same system for climbing buildings and climbing trees. Also because you essentially attach and animate the character relative to an anchor you can move the anchor dynamically with the character following.
Dynamic climbing is what I would call the climbing system in Zelda: Breath of the Wild and more constrained variants of it is used selectively in games that primarily rely on anchors.
In this system the character is moving on a climbing surfaces that can be defined by material properties or by logic that analyses the physics collision to determine how the character would move over the geometry.
Depending on how advanced the solution is this can also handled the surface that the character is on moving dynamically.
For one of the games we wanted climbing that could be done everywhere so that you could get to anywhere. Since the amount of geometry that would need to be tagged with anchors we went with a dynamic solution that would analyse the collision geometry for valid movement. Additionally we needed this system to work in multiplayer with multiple players climbing at the same time.
Aside from surface climbing we also wanted ledge grabs/mantles which was kept for the shipping game so we had a system for doing physics queries and validating free space.
We went through several iterations to get to a good solution but we started by going down the wrong route as you do.
In our first implementation we had the character capsule and we put it against a wall when you started climbing, then we moved it similarly to how you move a character on the ground by applying velocity to push it around, if there was a complicated piece of geometry blocking the capsule the character could get stuck and the capsule was always at a certain distance away from the wall so it never was perfectly planted against the wall.
The were several shortcomings here as you could imagine, getting stuck anywhere was not an option, the character floating a bit away from the geometry was not optimal and the character was moving using velocity and was not aware of the hands and feet being planted.
So we needed to do better.
So we had a system for climbing but it had issues and we wanted to solve them in ways that we knew would work.
We disabled the capsule collision against the level geometry. That meant we could get the character closer to the wall and our IK solution for feet and hands was looking correct. We calculated the position of the hands and feet relative to a wall plane so that we knew how the animation was relative to the climbing plane. That way we could attach the hands and feet to the walls and animate away from them.
That meant we would not get stuck on bits and pieces and the character would look aligned to the wall.
For making the climbing feel satisfying we wanted to utilize the animations and move in fixed steps rather than fully analogue so we implemented a system that was doing physics queries relative to the characters current position and facing and the direction of the stick. We used two different distances, one full length and one half length and then we also had two corner queries (inner and outside). We also had queries for climb up from the surface to ground up and down.
1. Move Query at long distance in the direction of the move.
2. Move Query at short distance in the direction of the move.
3. Inner Corner Query at fixed distance in the direction of the move, horizontal only.
4. Outer Corner Query at fixed distance in the direction of the move, horizontal only.
5. Climb up and detach query at a fixed distance.
6. Climb down and detach query at fixed distance.
We organized these queries so that the long move query was done first, then the short, then the corner queries and lastly the detach queries. The reason we wanted to have the short move distance is because that was better to use when the wall geometry was undulating and then for more flattened surfaces the longer moves were used. Also when reaching the end of a wall you want to get as close as possible to the end.
We merged this with our action system so we had replication handling which move was selected and the checks that we did on server and client was set up to match by simulating compressed position/etc.
The way we set up the movement animations were so that we had two sets of move animations that were set up to animated in sequence.
Movement A (short and long distance)
20 frames start->20 frames move->20 frames settle.
Movement B (short and long distance)
20 frames move->20 frames settle.
We basically set it up so that whenever you started moving we would play the 20 frames of the start section and then the 20 frames Move A and if you were still holding the stick we would transition to Movement B in the move section. Whenever you released the stick we would transition to the settling part and that settling part was interruptible at any point.
This achieved a few things, we had deterministic movement and we had smooth movement and we could switch distance and direction at the loop points. It felt like the character was climbing as he had to grab hold before changing his movement direction.
One thing that is necessary on a climbing solution is to have a good IK system and what we were using was two bone and three bone ik chains for arms and legs with a custom hips adjustment that would rotate and position the hips at a good relative distance away from the wall.
We also investigated full body IK and full body IK is something you want to utilize when you are moving multiple limbs like this so that you can reduce the amount of content you need to create.
We utilized additives and procedural code for handling the different slopes of the walls and we did not create specific climb animations for different surface angles but we did create different climb animations for the different directions. Left, Right, Up, Down in pairs that fit.
There were issues of course, with higher fidelity requirements the collision becomes either more advanced (which comes with memory and performance costs) or it becomes too simplistic (where the character is too far from the surface for our detailed IK raycasts to be able to place the hands and feet.
The bigger problem in my opinion was the problem of how to make the climbing fun and interesting, it’s not enough to just have a wall and you just climb up it ala Zelda and the challenge is against a stamina meter. That to me is the least interesting type of climbing. The prototypes that we did showed that the most fun for the climbing was when we intentionally put in obstacles so that the challenge became finding your way up, changing the design goal from climb everywhere to get anywhere to instead climb and get anywhere.
However that would then require designers to author climbing challenges everywhere in the world. That, the higher fidelity requirements and the gameplay focus on combat meant that system didn’t fit with the game.
Since I’ve spent quite a bit of time working on traversal systems and find them a major element in making third person character action games fun I obviously think that you can make a game that has this climbing system in it and I think if you used this as a challenge element you could make a very satisfying game.
A game that has jumping, double jumps, hover, flying, swimming, dashes, wall running, ground sliding would be a lot of fun as you can see in Mario, Spiderman, etc. and dozens of 2d platforms.