Having issues with collision

Learn how to make certain types of games and use gameEditor.

Having issues with collision

Postby TDM » Fri Feb 08, 2019 5:20 am

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 :D
Attachments
Screenshot (5).png
Platformer.rar
(56.7 KiB) Downloaded 108 times
TDM
 
Posts: 7
Joined: Thu Feb 07, 2019 4:42 am
Score: 0 Give a positive score

Re: Having issues with collision

Postby juansimat » Fri Feb 08, 2019 2:17 pm

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

Hope it helps you.
̿̿¯̿̿¯̿̿'̿̿̿̿̿̿̿'̿̿'̿̿̿̿̿'̿̿̿)͇̿̿)̿̿̿̿ '̿̿̿̿̿̿\̵͇̿̿\з=(๏̯͡๏)=ε
User avatar
juansimat
 
Posts: 152
Joined: Sat Dec 19, 2009 8:23 am
Score: 27 Give a positive score

Re: Having issues with collision

Postby TDM » Sat Feb 09, 2019 5:14 am

Thank you so much fam, this was really helpful :D
TDM
 
Posts: 7
Joined: Thu Feb 07, 2019 4:42 am
Score: 0 Give a positive score

Re: Having issues with collision

Postby TDM » Thu Feb 14, 2019 5:04 am

juansimat wrote: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 :D
Attachments
Platformer 2.rar
(6.9 KiB) Downloaded 110 times
TDM
 
Posts: 7
Joined: Thu Feb 07, 2019 4:42 am
Score: 0 Give a positive score

Re: Having issues with collision

Postby lcl » Fri Feb 15, 2019 5:47 pm

TDM wrote: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 :D

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. :D

Here's a demo of making the lifts the way I suggested:
liftPlatforms.zip
(1.46 KiB) Downloaded 103 times
User avatar
lcl
 
Posts: 2339
Joined: Thu Mar 25, 2010 5:55 pm
Location: Finland
Score: 276 Give a positive score

Re: Having issues with collision

Postby TDM » Sat Feb 16, 2019 4:19 am

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 :D

hope you help me with this problem too.
Attachments
Screenshot (10).png
TDM
 
Posts: 7
Joined: Thu Feb 07, 2019 4:42 am
Score: 0 Give a positive score

Re: Having issues with collision

Postby lcl » Sun Feb 17, 2019 1:17 pm

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. :P

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. :lol:
User avatar
lcl
 
Posts: 2339
Joined: Thu Mar 25, 2010 5:55 pm
Location: Finland
Score: 276 Give a positive score

Re: Having issues with collision

Postby TDM » Mon Feb 18, 2019 4:37 am

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
TDM
 
Posts: 7
Joined: Thu Feb 07, 2019 4:42 am
Score: 0 Give a positive score

Re: Having issues with collision

Postby lcl » Tue Feb 19, 2019 4:59 pm

I pretty much gave you the answer already. This is the Collision on Top Side of Lift, (repeat: Yes):
lcl wrote:
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. :)
Attachments
PlatformerLCLfix.zip
(497.07 KiB) Downloaded 109 times
User avatar
lcl
 
Posts: 2339
Joined: Thu Mar 25, 2010 5:55 pm
Location: Finland
Score: 276 Give a positive score

Re: Having issues with collision

Postby TDM » Thu Feb 21, 2019 7:13 am

thank you so much for .ged and deep explaination. :D
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. :D

thank you soo much for helping me out. i'm not that good at programming :P
TDM
 
Posts: 7
Joined: Thu Feb 07, 2019 4:42 am
Score: 0 Give a positive score

Re: Having issues with collision

Postby WalkerHS30 » Tue Mar 26, 2019 8:36 am

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.
WalkerHS30
 
Posts: 4
Joined: Tue Oct 23, 2018 3:24 pm
Score: 1 Give a positive score


Return to Tutorials

Who is online

Users browsing this forum: No registered users and 1 guest