Climbing theory in FPS or TPS?

Couldn’t find this already posted…

If you have physics for your characters and want them to climb a wall or anything vertical, how is this typically accomplished in a FPS or third person type game? For example, what is the basic theory for climbing in the Tomb Raider series or the ropes in games like Rainbow 6?

If someone has a link to an answer for a different engine, that’s fine, too – Im not trying to reinvent the wheel. :slight_smile:

EDIT: I’m thinking specifically about gravity but maybe I haven’t learned enough about setting up an FPS to tackle this yet. Apologies if it’s a stupid question!


I would very much like to know the answer to your question myself. I’m no professional, but from what I can tell, most people simply use either a collision-proxy object for detecting collision with the player when it’s near, or they use a physics trigger to detect when the player is near. The climbing delays could be driven by a timer. (IF in contact with player → player height/gravity +=1.)

I’m aware this might not be the answers you were looking for, but there are numerous tutorials out there for this I believe for other game engines.

1 Like

It’s the first time I’ve done this, I guess it’s not the most elegant way to do it…
Anyway here I leave a sample file of how to go up and down a “ladder”
(Scroll with the up, down and jump back to drop the ladder with space)(left click to reset the position of the “cube”).
I hope that if someone finds another way to do it, I would like you to let me know.

small error in the above file :sweat_smile:

references and scrolling to the sides


I’m not near my computer, right now, so I can’t test what you’ve done. But, the way I, a total amateur, would try is to not involve dynamic physics, like from a dedicated engine, at all.
Basically, figure out how you want to “initiate” climbing (button press, aggressive enough movement towards climbable surface/object) and then completely switch movement controls and dynamics. Once Climbing™ has been disengaged, regular physics and controls again take back over (so, you fall and such).
The above should work for walls and simple rope climbing (actual rappelling mechanics, involving pushing off and all that are a whole different beast, I believe). This is, more or less, how I think climbing vines and ladders is done in Ocarina of Time, and similar. But, I don’t know how to handle ledges…

Granted, I have no idea how to translate this into code, or even nodes. But, the theory makes sense to me and seems technically correct and feasible-ish.

Maybe we should add a section to the official documentation for Theory such as this. It would be a different approach than having step-by-step tutorials that can be hard for regular people to translate to a different situation.


There are a lot of ways to do this. You can use raycast or shapecast, pre-positioned objects in the positions the player is allowed to climb, collision checks, etc. Simpler methods will require more manual work with the map, as you will need to place the climbing colliders all over the map.

I’ve already done a climbing system in UPBGE using just logic bricks, i will tell how later.

But the BEST way i’ve done this in Armory was in this way:

  1. You know where the player is facing (a world vector), no matter if TPS or FPS, it is the transform look. For reference, you can get this vector in the Get Transform Orientation node iirc.

  2. So why is that vector useful? Simple. You can take the player position and add that vector to the position of the player. As a result, you will have a position 1 meter in front of the player, because this vector is normalized. Multiplying this vector (before adding it, obviously) by some value will allow you to determine its distance (see the empty in front of the capsule)

  1. Okay, now you have a point in the world, you can do some raycast from it, right? Yes… let’s call it the raycast start position. But we need another vector, now the Transform up vector. It is the same as the look vector, but the direction will be the up axis of the player:

  1. The up vector is also normalized, so you just need to take the facing position and SUBTRACT the up vector to it, as the result, you will have this:

  1. Now you need to correct the offset of this vectors, to end with something like this:

  1. I guess it is clear you just need to move these vectors up a bit more, you already know how to do this, just add the up vector of the player transform scaled by the offset you want. You can take the player dimension in Z as reference for this vectors.

  2. Done. You already know where will be the start of the raycast and where it will end, so just intersect any collision point between this two vectors.

  3. If the raycast hits something, you will have this (the collision point):

  1. Oh hell, another vector to the count, but it is almost finishing… With this vector you know the HEIGHT of the scalable object. But you don’t know where it starts :frowning:

  2. Your mission now is to test another raycast… now the end position will be the HIT of the previous raycast.

  1. If the collider have VOLUME this ray test will work (not a flat plane), i know it looks like will pass directly over the surface of the cube, but no, because the HIT point (end point of this raycast) is inside the face. So in case there is a hit, now we have another point in the world. And yes, it is the ledge.

  1. Of course, there are so many situations that will made this to don’t work, because this cube could be rotated:

  1. In that situation, if you want your climb system to be really dynamic, you should use the normal of the first hit to define the position of the second hit, to achieve something like this:

  1. And also, the information of the last hit is not just a point in the world. You can actually use the normal of the hit to determine the player rotation when it climbs (left cone = current rotation, right cone = desired rotation):

  1. And it is not the only thing to think about. You also need to do collision checks to decide if the climb end position have a space that will fits the player. For that you should project a few ray tests or a volume collider to check this before moving the player:

I know it may seems hard to do, but is really easy. You can do that in one or two hours i guess. But of course, there are many situations to consider yet… will the player be able to move sideways while holding the ledge? I hope yes because this is fun :slight_smile:

But let me tel how i have done a simple climb system using upbge logic bricks years ago:

I think the image explains it, but it is basically two raytests, one above and one below. When the lower ray hits something and the upper not, means i have something to hold. So when this is triggered, i moved the player to the climbing state. In this state, the capsule is moved above until the lower ray stop to detect the ledge, to correct the positioning of the player in the ledge in cases like that:

I don’t have to say this method is not good, because if the player is falling too fast the detection will not work.