Grabbing onto a ledge (to pull yourself up/drop down)

#1 Sounds like a pretty simple problem. If it were me, I would reinvent it :p

#2 I seem to recall there being a "max step height" (something to that effect) variable in the player datablock. It goes to reason that you could check for stepheight (again, something to that effect) and play an animation based on its height (totally off the top of my head).

#3 I pretty sure that in order to add a new animation, you need to call it in the player.cc file. Im not a programmer though, so how one would do this is beyond me.

There is a resource that shows you how to add crouch, crawl, prone, and swim positions/motions... I think that might be a good thing to explore.

#4 Ok, I guess I mis-stated what I wanted to know. I don't need to know how to add new animations. That's trivial. I'm going to look into the max step height stuff, to see if some of that code can be used for what I'm trying to do, or if I can integrate this into that code, thanks for the suggestion Teck.

What I think is probably non-trivial is basically intuitive (for the user) detection of the fact that, you're jumping through the air, hit a ledge, and know "I want to hold onto this ledge". Once we've done that we can transition to a hanging state, and allow them to drop off the ledge, climb up on it, or move from side to side (haven't decided if we're actually going to do side-to-side).

What I'm thinking is doing a check when colliding for whether the object is a "platform" that can be held on to, and whether it's near the top of the player model, but only if the player is facing it. However, this seems like one of those things you have to play around with a lot to get right, and so I was wondering if anyone has done it and has any tips.

#5 I created an invisible model that I could detect and utilize. It was a simple pole that I could orient as necessary. I didn't mount it, I just used it to change the animation and made sure that the areas where the climbing happened blended with the animation correctly. It was a kludgy method, but it worked. I didn't do any long-range jump testing, though. It was simple climbing. But, depending on whether your feet are colliding with something or not, you could create a "fling-up" animation ala Kingdom Hearts.

#6 David:
That sounds rather intriguing. Could you expand on that explanation a little? I'm curious what exactly you mean by using the invisible object to work the animation.

#7 I created a "crawling up" animation (no crawling down, though). If there was a collision with the "edge" (pole I created) and the player pushed the action button, it would play the animation and move the character accordingly much the way jumping works naturally, but with much more limited horizontal movement. I took what I had naturally with Torque and tried to figure out how to do it without creating edge detection algorithms (the concept I was working on was a more linear level design than something like Tomb Raider which needs a wide variety of ledges and nooks and crannies. Mine was closer to Ratchet and Clank or Jak and Daxter (the original, not Jak II or 3).

What got me thinking about it was a level in Soldier of Fortune that takes place on a train. The way it was done was keeping the train stationary and animating the level around the train. To the player, the illusion was complete, but to me as a developer and designer, it was extremely interesting to see uncommon processes working with common problems. I loved seeing how the designers thought around the problem and that's what I tried to do. Since I had a more linear versus open level-base, it worked pretty well in that context. I don't think I would have done it that way in a more open-ended level base because it would have been extremely annoying to keep track of that many edges. Insane more than annoying.

Since I was also researching a load/unload chunk scheme, it would have added a huge amount of complexity outside of the simple mission-based levels that I was working with when I came up with it. Loading interior chunks and their associated DTS's and managing them would have been pretty hairy. I never got to that point, though. And I haven't had time to get back to anything similar.

#8 I see what you mean now. That's actually pretty cool. Definitely thinking outside the box. :) I, too, loved the idea of the "moving train" type of levels. Necessity is the mother of invention, or something to that effect. :)

#9 Likse said before, detecting edges can be tricky, and can easily go out of control. Edge grabbing can probably be solved faster and without much hurdles using triggers to mark grab'able edges/poles and some state switching.

I found it to be pretty straightforward to re-use the existing state system in Torque to add extra moves to the player., since you won't even need to add extra data in the packet writes/reads.

#10 Manually generating triggers would be possible, but extremely time-consuming for us (we have tons of floating platforms throughout our level). Autogenerating them could be an option though; I'll look into that.

The pole idea seems like it could work for us pretty well, though not exactly how you did it David. There would need to be a lot of conditional checks whenever it hit something (is the player moving downward, is he at the top of the object he hit, etc.) but it seems doable.

#11 Maxstephieght is probably still going to be your best solution, and may even be the easiest. I've looked over the code in player.cc before, and it looks quite trivial. Upon bumping into a vertical plane, the hieght is checked against the script variable, and if okay, the player is tossed up top. Adjusting it to your needs, provided it works as it appears to, would only require 1-2 additional checks. Step height, climb height, jump to climb height, etc. It would probably require a little bit of thinking in how you layout your obstacles, but thats true in any 3d platform style game, including the lara croft series.

#12 I see where maxStepHeight is compared to collisionList.maxHeight in player.cc:

// Try stepping if there is a vertical surface
         if (collisionList.maxHeight < start.z + mDataBlock->maxStepHeight * scale.z) {
            bool stepped = false;
            for (U32 c = 0; c < collisionList.count; c++) {
               Collision& cp = collisionList.collision[c];
               // if (mFabs(mDot(cp.normal,VectorF(0,0,1))) < sVerticalStepDot) 
               //    Dot with (0,0,1) just extracts Z component [lh]- 
               if (mFabs(cp.normal.z) < sVerticalStepDot) 
               {
                  stepped = step(&start,&maxStep,time);
                  break;
               }
            }
            if (stepped)
            {
               continue;
            }
         }

Does anyone know how Torque arrives at "collisionList.maxHeight"? Does it represent the height of the nearest plateau in the direction the character is facing? Is it the highest point of the face the character's bbox is currently intersecting with? Where in the code does this value get generated? (I know I should just search for it but you know for the discussion's sake.)

phong.