Having issues with collision

[TDM]

I recently started working on a platformer game, i added all the basic scripts like player movement and camera movement. but when i tried to make a level,i noticed when my player character collides to the edges of platforms, it sticks to them. Can anyone help me out? Thank you in advance

[juansimat]

Hello, this topic has a solution for those problems related with collision.

Hope it helps you.

[TDM]

Thank you so much fam, this was really helpful

[TDM]

Hello, this topic has a solution for those problems related with collision.

Hope it helps you.

The topic you showed solved my collision problem. However, the technique used in that method works for stationary actors like platforms. When i tried to make a moving platform/lift , it no longer works for me. can you please take a look at it and help me out? thank you in advance

[lcl]

The topic you showed solved my collision problem. However, the technique used in that method works for stationary actors like platforms. When i tried to make a moving platform/lift , it no longer works for me. can you please take a look at it and help me out? thank you in advance

You can fix it by only using a simple Collision -> Top side of Lift (repeat: Yes) -> Script Editor:

Code: Select all

PhysicalResponse(MOVE_EVENT_ACTOR_ONLY, USE_CALCULATED_MASS, 1.000000, 1.000000, 0.000000, 0.000000);

Here's also some other tips that may come in handy when dealing with the moving platforms.

The way your lift movement currently works is much more complicated that it has to be. I see that you're using a variable (lstate) to determine whether the lift should be moving up or down, and changing that variable when the lift collides with Lift_top or Lift_bottom.

Well, so far it seems like there's nothing wrong with the system, but try adding a new lift. If you just clone your lift actor and the limiting top and bottom actors, you'll notice that things don't work right anymore. Both of the lifts now change their direction when either one of them touches a limiting actor. This is because there's only one variable that both of the lifts are using, so when one lift changes it, it changes the behavior of the other lift, too. The simplest fix would be to make the variable into an actor variable. Currently the variable is a global variable, meaning, there's only 1 variable and it can hold only 1 value. An actor variable is unique to every actor in the game, so every actor can have their own value for it, just like an actor's x or y coordinates.

But, even if changing the variable to an actor variable fixes the problem, there's still an even better way to make the lifts, one that doesn't require any custom variables!

What you can do, is to only have 2 actors - one for the lift and one for the limits, and then clone those to your hearts content!

The lift actor only needs 2 events.
The first event needed is the Create Actor -event, where you give it a vertical velocity using the yvelocity actor variable:

Code: Select all

yvelocity = 3.0; // For example. You can obviously use any number you like.

And the second event is Collision with the limiting actor. This should be with the settings Top or Bottom side, repeat: No.

Code: Select all

yvelocity = -yvelocity;

The way that code works is that every time the lift platform collides with a limit actor, it's yvelocity is reversed. So, if it's 3 it'll become -3. And if it's -3 it'll become 3. This way there is no need to make any difference between the top and bottom limit actors.

Here's a demo of making the lifts the way I suggested:

liftPlatforms.zip

(1.46 KiB) Downloaded 103 times

[TDM]

Thank you for helping me out with the lifts mechanism. but the reason i didn't use normal collision for lift tops is as shown in the picture. The player actor gets stuck in the air when the lift goes downwards. It does not update until i press a key. when any of the movement keys are pressed, it updates itself and starts to fall. i had tried this before and it didn't work, so i thought someone from forums would know what to do.

I really liked how you explained the lift mechanism thank you

hope you help me with this problem too.

[lcl]

I see that you copied your Collision Top side of Platform_01 to the collision event with lift, as that bug you mentioned doesn't happen if there's only a PhysicalResponse call in the collision event. The problem is caused by the if condition:

Code: Select all

if (Player_base.yvelocity > 0) // <-- this!
{
    // here's the rest of the code
}

The whole collision event is executed only if the player's yvelocity is greater than 0, i.e. when the player is falling. So, the event will only work if the lift you are riding is going downwards. When the lift starts going upwards, the collision event is executed for 1 last time, and InTheAir gets set to 0, as does the player's yvelocity. Now, the collision event is not executed anymore, because the player's yvelocity is less than or equal to 0, i.e. not greater than 0. And the reason the player remains stuck in the air until he's not colliding with the lift anymore is the way CollisionFree works.

What CollisionFree does is to check whether the actor would have a collision with any actor if it was moved to the given coordinates. In the Draw Actor script of the player there's this:

Code: Select all

if (CollisionFree("Player_base",x,y+1) == 1)
{
    InTheAir = 1;
}

The code checks if the player would be free of collisions if it was moved 1 pixel down. And when the player gets stuck in the air and is still in contact with the lift CollisionFree will return 0, telling that the player would not be free from collisions even if it was moved 1 pixel down. This goes on until the lift has moved up so that it's only colliding with the player by its lowest line of pixels. That's when CollisionFree returns 1, because now moving the player 1 pixel downwards results in him not colliding with any actors. And it is only then when the variable InTheAir finally gets set back to 1 and the player starts falling again.

The simplest fix is to just remove the condition. But doing so still leaves another problem. When the lift is going downwards, the player constantly changes between falling and not falling and it makes his lift ride look jumpy. And beside the visual annoyance, there's a much more severe problem - the player can only jump when he's not falling. And when he's constantly changing between falling and standing it's out of pure luck if the player manages to jump.

So here's a suggestion for fixing both problems.
If both, the lift and the player are moving downwards set the player's yvelocity equal to that of the lift after processing the PhysicalResponse. That way the both of them will move at the same speed and the player will remain standing and able to jump.

Code: Select all

double TempXvelocity = Player_base.xvelocity;
double TempXcoordinates = Player_base.x;

if (collide.yvelocity > 0 && Player_base.yvelocity > 0)
{
    PhysicalResponse(MOVE_EVENT_ACTOR_ONLY, USE_CALCULATED_MASS, 1.000000, 1.000000, 0.000000, 0.000000);
    Player_base.yvelocity = collide.yvelocity;
}
else
{
    PhysicalResponse(MOVE_EVENT_ACTOR_ONLY, USE_CALCULATED_MASS, 1.000000, 1.000000, 0.000000, 0.000000);
}

Player_base.x = TempXcoordinates;
Player_base.xvelocity = TempXvelocity;
InTheAir = 0;

There's still a single moment where the player is unable to jump, though. That's at the moment when the lift changes direction from going upwards to going downwards. The player's collision with the lift stops for a few frames and the CollisionFree goes on to set the InTheAir variable to 1, thus disabling jumping. It's a small window, but still can cause problems for players.

For fixing that problem one way to go is by using a different variable for determining whether the player is allowed to jump or not. That variable could be named CanJump, for example. Then you'd just set the variable to 1 in any Collision Top side of Platform / Lift events, and adjust the jumping code to check for CanJump == 1 as well as setting it to 0 after jumping. Then the last addition would be to add code like this to the player's Draw Actor script inside the CollisionFree check:

Code: Select all

if (Player_base.yvelocity > 7)
{
    CanJump = 0;
}

This would make the player unable to jump when falling, but only a little after he's started falling. By adjusting the value in the condition it is possible to eliminate the window of no-jumping when the lift changes direction. But this method also makes players able to jump a little after they've already walked off a platform. Some games do this intentionally. For example the original Crash Bandicoot games gave the player a little extra time for jumping even if they were not standing on the ground anymore. But this can be a difficult thing to balance, because if it's too noticeable, it just feels like the game is broken. So, I'm not sure if this is the best way to go for fixing the little no-jump window, but I can't come up with anything else right now.

The way to test for the no-jump window is to set the game's fps limit to 10, for example, and then wait for the moment where the player loses contact to the lift upon the lift changing direction, and then trying to jump just before the player lands on the lift again. It really is a small window, and not very likely to happen often when playing the game normally at normal fps. But it can happen, and it would not be a very nice way to possibly lose a life. Other possible solutions may involve partially redesigning the collisions and gravity of the game. It's up to you to decide what to do. I can also try to take a look at some of my older games to see if they have this problem or if I've managed to circumvent it.

I hope this Wall of Text™ was helpful in some way.

[TDM]

sorry but can you make a quick .ged , because i didn't understand what should i do.
i did understand that:

1. if player and the lift are moving at different velocities, player actor starts to vibrate/jump and it messes up the InTheAir variable. which makes jumping mechanism sort of stop working properly.
2. when the player gets stuck in air after lift collision ends, it is because the player script is only triggered when the yvelocity is greater than zero.
3. coyote time would be great

Thank you for helping me out

[lcl]

I pretty much gave you the answer already. This is the Collision on Top Side of Lift, (repeat: Yes):

Code: Select all

double TempXvelocity = Player_base.xvelocity;
double TempXcoordinates = Player_base.x;

if (collide.yvelocity > 0 && Player_base.yvelocity > 0)
{
    PhysicalResponse(MOVE_EVENT_ACTOR_ONLY, USE_CALCULATED_MASS, 1.000000, 1.000000, 0.000000, 0.000000);
    Player_base.yvelocity = collide.yvelocity;
}
else
{
    PhysicalResponse(MOVE_EVENT_ACTOR_ONLY, USE_CALCULATED_MASS, 1.000000, 1.000000, 0.000000, 0.000000);
}

Player_base.x = TempXcoordinates;
Player_base.xvelocity = TempXvelocity;
InTheAir = 0;

The line Player_base.yvelocity = collide.yvelocity sets the player's yvelocity to be the same as the lift's is. Lift is the Collide Actor in that event.

Here's a demo anyway. I made it so that on collision with lift the CanJump variable is set to 2 to distinguish from normal land. Then coyote time is only applied if it is a lift the player is jumping off. This allows fixing the problem without affecting all jump timings.

[TDM]

thank you so much for .ged and deep explaination.
i had problem understanding the lift collision fix. but now i understand what you were trying to say thanks to the .ged

I didn't use 'collision free' because when we get at the top of our lift, there is the lift_top actor which causes 'collision free' to stop functioning the way how we want it to function. it tricks the code to think player is still in collision with something (which technically is true) but the player does not update itself because of it. which causes him to hover in air.

never mind i will find a way out like using paths instead individual actors.

thank you soo much for helping me out. i'm not that good at programming

[WalkerHS30]

Thanks for the tutorials and explanations!

I've actually been able to implement non-"lethal" collision mechanisms in the game I'm working on: it's a shoot'em up about model planes dogfighting in a house, so hitting some pieces of furniture like sofas or plants isn't necessarily a game over.