Platform Collision (part time)

[d-soldier]

I've been experimenting with different ways of having platforms which act much as normal collision maps (physical response enabled) but also allow you to fall through or jump up through. Much like the level1 boss from Contra 3, where you have three levels of platforms to jump on (see pic)... I've tried using a physical response JUST on the top side of these platform collision maps, but the transition from being under it, jumping, and then being placed above it (in accordance with the topside physical response) is sketchy with the movements to say the least... Has anyone tackled this problem before? Would a variable (activated on the jump keydown) which temporarily disabled the collision events for the platforms be the best way? I can see this being just as sketchy once a timer puts the event back in place if the player is half-way through the object though... anyone?

[Rux]

D-E-M-O

DEMO!

Left and right move, up jump through platform. Down fall through top platform.

P.S This is my first post in the advanced topics forum.

[d-soldier]

Thanks for taking the time to make a demo Rux, but it's having the same response I was getting when I tried using timers. It works great IF (and only if) the higher platform is that high up, if it's higher, or midway, or if you press down, then up right after, the collision state can enable mid-jump, and the physical response forces the player up, which makes for sketchy movement... If this is the best way to accomplish it, I may not use the feature in the game...

[Fuzzy]

Two things that I can think of that might help are

1. Track the trend. Use some variables to track which way the actor is moving, or has been moving. If the actor is heading up(jump), and the player presses down... too bad. you are going up, at least for a little while.

Code: Select all

// actor variables
int YTrend;
int MoldY;
int SmellY;
int CrustY;

// each draw, or keypress or whatever..
CrustY = SmellY;
SmellY = MoldY;
YTrend = y-CrustY - SmellY - MoldY;
MoldY = y; // Do this one After the YTrend to set it for next draw
// Decide what to do based on the trend.
// Something like this anyway. You could use directional_velocity as well.


The resultant number should indicate which way the actor has been heading for the last few draws.

The second method is that if collision is not working... get rid of the collision. When the player enters an area, near some platforms, have him pass and silently trip a collision with a filled actor that sets some variables indicating the heights of the nearest platforms. Then you manually check the actors height compared to those variables and decide what to do.

This is probably more intuitive overall, and gives you more exact control.

An interesting third thing to investigate would be to not have player controls at all; Keys are bound to an area, so that when the players actor is within visibility(colliding) the area remotely controls the actions of the actor, allowing area specific effects.

Lately, I have been considering friction. I think thats easiest of all, overall, but I dont have anything to say on it as of yet.

The problem from my perspective is that past actions have no effect on current actions. You need to accomodate that. IF they are heading down, they simply cannot start heading up again. Remove the collision detection out of the realm of the key press.

[DocRabbit]

Hey D,
Maybe you are on the track, just not looking in the right place. If your player's normal jump has enough to get him above it before he starts coming back down, at some point his velocity crosses the zero line. Have that trigger your collision back on and your jump button press turn it off.

So the sequence would be: press jump button, toggle collision off, draw character through jump phase, when character reaches 0 velocity, turn collision back on. The downside of this would be he would have to be clear before turning it back on, else he'll never trip the collision.

I borrowed the caveman animation here, to save time.

[d-soldier]

So I tried to re-activate the collision event when the player's yvelocity came to zero, and it never re-activated... If the player's draw actor event always has it's yvelocity set to .8 (for gravity) then would it really ever reach zero, if thats a constant draw-actor script??? Regardless, the collision events never re-activated, even after I was back on normal ground...

[DocRabbit]

They should cross it, calculated on frames and amount of gravity versus your jump acceleration. You may have to test for a peak point range instead. I put a demo up that works, if you want to take a look at it. I used a draw actor event on the platform for testing actor velocity. Maybe that was why yours didn't work.

[metal_pt]

I didn't quite undestand your problem but have you tried something like this?

Code: Select all

if(yvelocity<0)
    CollisionState("Event Actor", DISABLE);
else
    CollisionState("Event Actor", ENABLE);

[d-soldier]

I demo does seem to work very well in that situation... Heres the thing, my player isn't able to jump three times his height, so most the platforms (at least the first) are going to be at about mid-waist level, which in using only topside for collision/physical response, forces him on top of it when he walks through it before even jumping. If all sides have a physical response, then many jumps seem to end early and as the physical response is activated, he is suddenly jerked out the side of the platform... Wouldn't it be easier if there was a way to have the topside of the platform do things "after" colliding with the BOTTOM SIDE of the player?

[Thanx]

If you want it to do things after it collided bottom side, then add action-> Collision on Bottom side of platform -> Script, and not phisical response. When you collide with the platform's bottom side, then enter the code that reactivates the collision, or whatever...