Platformer Woes [Good for now...]

#1 Interesting first choice for help on the forums. About to check it out.

#2 First, the appearance of your demo is so similar to my first foray into platformers that I was spooked, though I soon saw the slopes and I still don't support those. But this week, I was about to start working on those.

The most disturbing problem is the whole getting stuck between the slope and flat ground. Your in demo comment regarding that doesn't make a lot of sense to me.

Also, don't know if you noticed, but if you jump (once) from the floating square near the start to the joint between the steep slope and upper flat ground, the character gets bumped up for no reason. That's actually more disturbing than the first thing I said.

In my own platformer development, I've had to fudge many things. My basic strategy is to mount "sensors" on each side of the player (and more for things like ledge hanging)


The white rabbit is a player, the yellow is a npc.

I obviously have bounding box debugging on. I also have my own custom debug visualization that sets triggered sensors to be transparent red (see the bottom sensor and walk sensor)

I was thinking of adding bottom corner sensors to start supporting slopes. I will switch gears from dialog to slopes in order to help you sooner. (PSK does slopes well, so it must be possible).

#3 Sorry for the massive triple post, but thought I should explain the bounding boxes a bit more - So the large box around the white rabbit is the camera mount (it has nothing to do with movement). The white rabbit has its own bounding box (but it's hard to see). Then all the boxes around the white rabbit are sensors that are mounted and stay with the rabbit at all times. His forward sensors are jumbled because the upper two are for ledge hanging. There's two on the bottom to enable walking which automatically stops before hurtling off the edge.

Also, my website: shells.myw3b.net/~syreal/

#4 I had nothing to lose so I figured "Why not share my project?".

Thanks for trying it out. That slope jump problem you mentioned in your second post, 3rd paragraph is what I was trying to convey with my confusing message. You can see that when it jumps the object up (on the slope you had an issue with) if you extended the slope it would exactly meet the objects lower right corner.

You see, I thought that maybe a bunch of sensors (which I have tried an idea or two with them) was 'cutting corners' and would severely hurt performance.

I thought of the PSK and how "Surely the PSK setup wouldn't use triggers.". But now I'm thinking that, I'm not using the PSK so I can do whatever I want. I happen to have a smallish white-board that I plan on using to help decide which sensors I need and where they should go.

BTW that's a nifty website you have there. I want one...

#5 Yes, I feel very similarly many times about sharing my project. Whatever helps people.

I experimented and I think you will find that this works much better for the catching the corner problem:

function Character::initCollisions(%this)
{
	%this.setCollisionCallback(true);
	%this.setCollisionDetection("FULL");
	%this.setCollisionGroups("0");
	%this.setCollisionActive(true,true);

        //i think this helps because it "puts into perspective" the
        //force that that pesky little corner would actually exert.
	%this.setCollisionPhysics(true,true);

	%this.setCollisionResponse("CLAMP");
	%this.setCollisionCircleSuperscribed(true);
}

Using a top sensor would fix the problem on the steep slope. (If there's something touching my head, I can't jump!)

I briefly went over your code, and it appears that you are using a lot of fudge factors like manually adjusting position. That's almost certainly causing some part of your confusing paragraph's subject. I still do not understand that paragraph. ;P

Thanks! I just put it up a week ago.

#6 Good to see I'm not the only person putting sensors around my character to detect things. I have 8 little squares, 2 on each side (up near corners) for corner detection. I mostly use it for climbing, not planning to use slopes right now. I did make a slope in Game Maker once... not sure how transferable that is, but if I recall you just subtract from Y with every step while touching the slope. Have a variable turn on when you hit a slope that makes this happen. Haven't tried it myself in Torque, but it might work.

And sorry, if it wasn't obvious I didn't read this whole thread or play the demo.

#7 I would add this to your Character::initCollisions() method and tweak it to see if it helps:

%this.setCollisionMaxIterations(2);

Hopefully that will help with "stickiness" and other little weirdnesses.

#8 The weekend is going to get in the way. I might have had a bit of a breakthrough but I'll give an update later when I can.

#9 A bit of an update. I think it might be working enough for me to rewrite it CLEANLY... and add slopes going the other way which is mainly copy&pasting&tweaking code.

Thank you so much Kevin for your help so far.

BTW, I'm not sure if increasing the collision iterations helped or not. I'll do some testing later but I'm having trouble understanding what it does. Does that make Torque call the onCollision function for the specific object twice in one frame or what?

#10 Just to finish this thread up, here is a link to the mostly working slope base.
www.filedropper.com/platformerbase
If anyone finds this helpful before the link expires, great! Hopefully sometime later I could make a resource out of this if I can clean it up a bit more and make it more "foolproof".

#11 The iteration will help with all objects testing for collision. When you run it again you get a chance to see if you are colliding against something else as a result of a position correction. The higher number of iterations should make the collision more accurate at the cost of speed.

#12 Huh, good to know. To bad it couldn't really rely on the end users computer power. Since it's a vital engine component that makes it a need, not a want.