Help Best practices for climbing up / down a rope?

[ShawnF]

I'm working on a 2.5D game with rope swinging/climbing. I've tried a few different approaches to dealing with the climbing, but haven't gotten anything that QUITE works. So far my implementation is:

• The actual game mechanics are the character swinging on a hinge joint that's independent of the obi rope. The obi rope is just used for visuals and collision detection, not the swinging rope movement.
  

• When you jump on to a rope, a new particle group is created and attached to the character's hand when the collision box hits
  

That works fine for attaching to a rope and swinging. 

For climbing, it gets trickier. The best version I've found is:

• When you climb up and down, each "step" attaches to the next particle up/down
  
• Your attachment to the hinge joint is then re-established based on your new location
  

This seems to work fine if the rope is steady, but the problem is that if I climb downwards while a rope is swinging, the particle's position is often higher than it would be if at rest, so the rope never extends to its full length. Hard to describe, but video here:
https://youtu.be/_TBW25ytktI


Any tips on avoiding this? I tried looking into the following two approaches, but I couldn't find a way to make them work:
1) Move the player independently of the obi rope and then somehow find the closest appropriate particle to attach and move it to the attach point. 
OR
2) After attaching, move the player down further if necessary to reach what would be the resting length of the rope at that point. Is there a way to find out how far the attached particle is from the top of the rope?

And in general, do you have any tips on best practices for getting a solid climbing setup? Does my implementation seem reasonable, or will I run into issues in the future that I might not have anticipated? (For example, I don't have climbing animations set up yet, and I could imagine that this could introduce some future headaches that I haven't seen coming...)

The main code used for moving the player is:

Code:

public void AttachNewParticleIndex(int indexChangeAmount)
    {
        // Get the new particle index that you're climbing towards
        int newParticleIndex = GetParticleNeighborIndex(indexChangeAmount);
     
        // Get new position to move to
        Vector3 newPos = solver.positions[newParticleIndex];
        newPos += transform.position;  // Adds the rope's position because the position of the particle is relative to the rope
        newPos -= attachedRopeChar.attachTransform.localPosition;  // newPos offsets the char's position so that the attach point is aligned with the rope particle
       
        // Detatch char from old position and move towards new one
        Destroy(attachment);
        Vector3 newCharRotation = new Vector3(0, attachedRopeChar.transform.rotation.eulerAngles.y, attachedRopeChar.transform.rotation.eulerAngles.z); 
        attachedRopeChar.transform.rotation = Quaternion.Euler(newCharRotation); // reset char rotation
        attachedRopeChar.transform.Translate(newPos - attachedRopeChar.transform.position, Space.World);  // Move char to the new particle pos

        // Create new attachment
        attachment = obiRope.gameObject.AddComponent<ObiParticleAttachment>(); 
        attachment.target = attachedRopeChar.attachTransform;
                   
        // Create a new particle group and assign it the particle that you are moving to
        var group = ScriptableObject.CreateInstance<ObiParticleGroup>();
        group.particleIndices.Add(newParticleIndex); // index of the particle in the actor
        attachment.particleGroup = group;
    }

[josemendez]

Hi!

Judging from the video, it's clear that the character is ignoring rope physics completely. In particular, it's ignoring the position/velocity of the particle it is attached to.

The rope should be enough to make the character swing, no need for the extra hinge joint. Otherwise you'll get a rope that sags below the character, as it's impossible to make a group of distance constraints (or constraints of any kind, for that matter) converge perfectly.

If you want to keep the hinge joint, you can get the length from any particle to the top of the rope by iterating trough rope elements towards the top and accumulating their length.

kind regards,

[ShawnF]

The rope should be enough to make the character swing, no need for the extra hinge joint. Otherwise you'll get a rope that sags below the character, as it's impossible to make a group of distance constraints (or constraints of any kind, for that matter) converge perfectly.

I'd definitely be up for removing the hinge if you feel like it will be problematic in the long run, I mostly just had some trouble getting the system working without it. But at the moment I'm confused by the issue you describe. Isn't that actually the expected behavior? I'd think that the rope should be taut from the top until it touches the character, and then loose below that point. Or did you mean something else?  

In any case, I'll spend a little time trying this out and see what issues I run into. Hopefully it resolves my issue.

If you want to keep the hinge joint, you can get the length from any particle to the top of the rope by iterating trough rope elements towards the top and accumulating their length.

Thanks!

[ShawnF]

So I spent a bit more time getting it working without the hinge, but I've run into two issues that maybe you can help with:


1) There's a lot of bounciness that I'd prefer not to have, especially when you first jump on the rope. I tried making the rope quite stiff (increased Substeps and decreased resolution), but it's still not ideal and making those values more extreme doesn't seem to help. Any advice? I'd like to try to achieve a less realistic, smoother pendulum feel when you jump on a rope similar to the WITH HINGE version in the video below.
https://youtu.be/870T-00yBTw


2) After the first time attaching to a rope, any future new attachment to a rope causes the following error. It doesn't seem to actually cause any problems, but I have no idea what could be causing it. Apparently it's from a change I made, but it's not in my code, so I'm not sure if it's a bug on your side or if I'm doing something incorrectly.

ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
System.Collections.Generic.List`1[T].get_Item (System.Int32 index) (at <1f66344f2f89470293d8b67d71308c07>:0)
Obi.ObiParticleAttachment.BreakDynamicAttachment (System.Single stepTime) (at Assets/StoreAssets/Obi/Scripts/Common/Utils/ObiParticleAttachment.cs:480)
Obi.ObiParticleAttachment.Actor_OnEndStep (Obi.ObiActor act, System.Single stepTime) (at Assets/StoreAssets/Obi/Scripts/Common/Utils/ObiParticleAttachment.cs:211)
Obi.ObiActor.EndStep (System.Single substepTime) (at Assets/StoreAssets/Obi/Scripts/Common/Actors/ObiActor.cs:1193)
Obi.ObiSolver.EndStep (System.Single substepTime) (at Assets/StoreAssets/Obi/Scripts/Common/Solver/ObiSolver.cs:1640)
Obi.ObiUpdater.EndStep (System.Single substepDeltaTime) (at Assets/StoreAssets/Obi/Scripts/Common/Updaters/ObiUpdater.cs:114)
Obi.ObiFixedUpdater.FixedUpdate () (at Assets/StoreAssets/Obi/Scripts/Common/Updaters/ObiFixedUpdater.cs:54)


And btw, just want to say that I really appreciate how active you are on this forum helping people out. It's great to see such good support.

[josemendez]

So I spent a bit more time getting it working without the hinge, but I've run into two issues that maybe you can help with:


1) There's a lot of bounciness that I'd prefer not to have, especially when you first jump on the rope. I tried making the rope quite stiff (increased Substeps and decreased resolution), but it's still not ideal and making those values more extreme doesn't seem to help. Any advice? I'd like to try to achieve a less realistic, smoother pendulum feel when you jump on a rope similar to the WITH HINGE version in the video below.
https://youtu.be/870T-00yBTw

Hi!

Imho the main problem with having a hinge constraint and a rope is that unless the rope converges perfectly (which would take a lot of substeps/iterations) the section between the top of the rope and the character will always look a bit loose/wiggly because it is slightly longer than the hinge, which has a fixed length. Ideally the rope should be completely straight - but since the mass of the character is supported by the hinge instead, it isn't.

My advice in this case would be to override the position of all particles between the character and the top of the rope, distributing them in a straight line. This will ensure the rope looks perfectly taut when using the hinge.

2) After the first time attaching to a rope, any future new attachment to a rope causes the following error. It doesn't seem to actually cause any problems, but I have no idea what could be causing it. Apparently it's from a change I made, but it's not in my code, so I'm not sure if it's a bug on your side or if I'm doing something incorrectly.

ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
System.Collections.Generic.List`1[T].get_Item (System.Int32 index) (at <1f66344f2f89470293d8b67d71308c07>:0)
Obi.ObiParticleAttachment.BreakDynamicAttachment (System.Single stepTime) (at Assets/StoreAssets/Obi/Scripts/Common/Utils/ObiParticleAttachment.cs:480)
Obi.ObiParticleAttachment.Actor_OnEndStep (Obi.ObiActor act, System.Single stepTime) (at Assets/StoreAssets/Obi/Scripts/Common/Utils/ObiParticleAttachment.cs:211)
Obi.ObiActor.EndStep (System.Single substepTime) (at Assets/StoreAssets/Obi/Scripts/Common/Actors/ObiActor.cs:1193)
Obi.ObiSolver.EndStep (System.Single substepTime) (at Assets/StoreAssets/Obi/Scripts/Common/Solver/ObiSolver.cs:1640)
Obi.ObiUpdater.EndStep (System.Single substepDeltaTime) (at Assets/StoreAssets/Obi/Scripts/Common/Updaters/ObiUpdater.cs:114)
Obi.ObiFixedUpdater.FixedUpdate () (at Assets/StoreAssets/Obi/Scripts/Common/Updaters/ObiFixedUpdater.cs:54)

Attachments don't really mess with one another, they're completely independent so not a clear reason I can think for this off the top of my head. If you could send a repro project/scene to support(at)virtualmethodstudio.com I'll be glad to take a closer look.

And btw, just want to say that I really appreciate how active you are on this forum helping people out. It's great to see such good support.

Thanks, I try my best!

kind regards,

[ShawnF]

So just to double check - any advice for getting smoother / less "realistic" swinging without the hinge? I'd be nice to keep it all on one system (just the rope), but of course the top priority is making it feel right from a gameplay perspective.

If you could send a repro project/scene to support(at)virtualmethodstudio.com I'll be glad to take a closer look.

Depending on your answer above, it's looking like I'll probably end up sticking with the hinge direction, in which case I won't need to resolve this issue. But let me know if you'd still be interested in investigating this for its own sake and I can send something over.

[josemendez]

So just to double check - any advice for getting smoother / less "realistic" swinging without the hinge? I'd be nice to keep it all on one system (just the rope), but of course the top priority is making it feel right from a gameplay perspective.

You could programmatically create a tether constraint between the particle the character is grabbing and the one at the top (see this page for info on adding constraints manually: http://obi.virtualmethodstudio.com/manua...aints.html)

The problem with this is that since ropes do not simulate torsion, the character would freely spin along the rope's axis unless you additionally constrain his facing direction (for instance, using his velocity to determine if he should face left/right).

It's probably simpler to use a hinge since the results will be the same with either method: both constrain the character directly to the top of the rope, and the rope just follows along for cosmetics.

kind regards,

[ShawnF]

Okay, thanks. I'll stick with the hinge, then, since I already have it up and working and it sounds like the end result will be basically the same.