SOLVEDCollisons Not working once I go airborne

Clockwatcher

Member
Hey guys, n00b here trying to get into Game Maker during the bajillionth COVID lockdown. Any help is super appreciated!

Was following along with Shaun Spalding's Complete Platformer thing and thought it'd be funny for the gun to launch you in the air. Managed to get it working but unfortunately when the gun sends me airborne I fly through walls and off the screen. Not sure what to do because when I'm jump and move normally, the collisions work fine.

I posted code below. Already copied and paste my horizontal and vertical collisions into the mouse check (while changing vsp/hsp to my airbornerecoil value) but it wouldn't work.

Apologies if this is painfully obvious or dumb. If you take a glance at this thread, thank you

Code:
// Horizontal Collision

if place_meeting(x + hsp, y,obj_wall){
while (!place_meeting(x+sign(hsp), y, obj_wall))
{
x = x + sign(hsp);
}
hsp = 0
}

x = x + hsp

// Vertical Collision

if place_meeting(x, y + vsp,obj_wall){

while (!place_meeting(x, y+sign(vsp), obj_wall))
{
y = y + sign(vsp);
}
vsp = 0
}

y = y + vsp

// Gun Kick

airbornerecoil = 20
KickDirection = (obj_gun.image_angle +180)

if mouse_check_button(mb_left)
{
x = x + lengthdir_x(airbornerecoil, KickDirection)
y = y + lengthdir_y(airbornerecoil, KickDirection)

}

CryptidProductions

Member
Your gun seems to adding to the player location manually instead of manipulating hspd and vspd to engage movement so the collision is trying to do math with 0s when you you're moving from it

That could mean flying through barriers before the collision can register

Tyg

Member
Just a suggestion
There is a wonderful physics system built into gamemaker
you can make each object use it or not
if you check solid it wont go through
you place an impulse so the gun kicks back
and im not trying to come down on you
but people keep trying to re-invent the wheel and then asking to debug their code
if you would like some help setting it up then i will help you

but as for your code the same problem again,
if your speed is too fast it steps past the wall before another collision is checked
your hsp, vsp and airbornerecoil have no limit
to solve this you can clamp your speed or lower your stepping

Last edited:

RefresherTowel

Member
@Tyg There's several reasons why people recommend not using the things you suggest. To begin with, I'm unsure what you mean by "physics system". If you mean the in-built Box2D physics system that GMS uses, then there's absolutely no reason to use that for a platformer, and doing so will lead to a much harder time developing a game unless you have very specific requirements and you fully understand the implications of using the physics system (something which most beginners have no idea about). A popular YouTuber once used the physics system for a top-down action RPG tutorial and it led to what was probably a few hundred (if not more) problem topics here, all of which the answers basically amounted to "don't use the physics system for this". I'm not saying it's impossible to use the physics system for these types of games, but it most certainly is not beginner material, and saying that people are "reinventing the wheel" by programming basic deterministic movement/collision for their game instead of using the physics system is not really what I would consider true.

Secondly, you suggest using the solid feature. This can cause a lot of problems when combined with any form of custom collision checking (which is usually needed at some point). When you mark an object as solid, GMS auto handles collisions, including moving instances automatically. Once control is taken out of the hands of the programmer, all sorts of chaos can ensue; problems can become very hard to debug, specific design requirements for the games can become impossible, people can come away with a very flawed understanding of how to actually program a game, etc, etc. I'm of the opinion that GMS shouldn't even have these "in-built" variables and instead should provide better onboarding tutorials that explain how to implement these basic features from scratch. It is not a hard thing to do and would lead to a much healthier understanding of how programming games actually work for people as they are learning. However, as it stands, I think it's unlikely that they will be removed, so all I can do is point out that letting GMS auto handle things is a common cause of bugs and it's generally better to maintain direct control by using "custom" variables, which only do things exactly when and where you want them to be doing things.

CryptidProductions

Member
@Tyg There's several reasons why people recommend not using the things you suggest. To begin with, I'm unsure what you mean by "physics system". If you mean the in-built Box2D physics system that GMS uses, then there's absolutely no reason to use that for a platformer, and doing so will lead to a much harder time developing a game unless you have very specific requirements and you fully understand the implications of using the physics system (something which most beginners have no idea about). A popular YouTuber once used the physics system for a top-down action RPG tutorial and it led to what was probably a few hundred (if not more) problem topics here, all of which the answers basically amounted to "don't use the physics system for this". I'm not saying it's impossible to use the physics system for these types of games, but it most certainly is not beginner material, and saying that people are "reinventing the wheel" by programming basic deterministic movement/collision for their game instead of using the physics system is not really what I would consider true.

Secondly, you suggest using the solid feature. This can cause a lot of problems when combined with any form of custom collision checking (which is usually needed at some point). When you mark an object as solid, GMS auto handles collisions, including moving instances automatically. Once control is taken out of the hands of the programmer, all sorts of chaos can ensue; problems can become very hard to debug, specific design requirements for the games can become impossible, people can come away with a very flawed understanding of how to actually program a game, etc, etc. I'm of the opinion that GMS shouldn't even have these "in-built" variables and instead should provide better onboarding tutorials that explain how to implement these basic features from scratch. It is not a hard thing to do and would lead to a much healthier understanding of how programming games actually work for people as they are learning. However, as it stands, I think it's unlikely that they will be removed, so all I can do is point out that letting GMS auto handle things is a common cause of bugs and it's generally better to maintain direct control by using "custom" variables, which only do things exactly when and where you want them to be doing things.
Yeah

Most devs skilled in the Game Maker Engine would advise against using to many of those complex built in features because they're basically a black box that's doing stuff where you can't see and can cause all kinds of unwanted behavior. It's always better to code physics and collisions yourself.

Tyg

Member
@Tyg There's several reasons why people recommend not using the things you suggest. To begin with, I'm unsure what you mean by "physics system". If you mean the in-built Box2D physics system that GMS uses, then there's absolutely no reason to use that for a platformer, and doing so will lead to a much harder time developing a game unless you have very specific requirements and you fully understand the implications of using the physics system (something which most beginners have no idea about). A popular YouTuber once used the physics system for a top-down action RPG tutorial and it led to what was probably a few hundred (if not more) problem topics here, all of which the answers basically amounted to "don't use the physics system for this". I'm not saying it's impossible to use the physics system for these types of games, but it most certainly is not beginner material, and saying that people are "reinventing the wheel" by programming basic deterministic movement/collision for their game instead of using the physics system is not really what I would consider true.

Secondly, you suggest using the solid feature. This can cause a lot of problems when combined with any form of custom collision checking (which is usually needed at some point). When you mark an object as solid, GMS auto handles collisions, including moving instances automatically. Once control is taken out of the hands of the programmer, all sorts of chaos can ensue; problems can become very hard to debug, specific design requirements for the games can become impossible, people can come away with a very flawed understanding of how to actually program a game, etc, etc. I'm of the opinion that GMS shouldn't even have these "in-built" variables and instead should provide better onboarding tutorials that explain how to implement these basic features from scratch. It is not a hard thing to do and would lead to a much healthier understanding of how programming games actually work for people as they are learning. However, as it stands, I think it's unlikely that they will be removed, so all I can do is point out that letting GMS auto handle things is a common cause of bugs and it's generally better to maintain direct control by using "custom" variables, which only do things exactly when and where you want them to be doing things.
Well i use it for mini games within a game and it works perfectly fine
the problem is most people dont know how to use it or misuse it
it does not mean you are limited to it once you start down that road
im not saying its one or the other but you add to it for your requirements
using the physics system doesnt take control from the programmer
each object can use it or not so how are you stuck in this "black box"?
and you can definately use custom physics if the object requires it
but saying its buggy is more inaccurate than accurate
most of those problems are the programmers misuse using phys vars without the system engaged
i certainly would like to see an example that is not programmer error
i use it for 2D and 3D games successfully, sorry i go with proven code that is made to work with the environment

sorry clockwatcher hope that helped

Last edited:

CryptidProductions

Member
using the physics system doesnt take control from the programmer
Yes it does because you're then telling the engine do large amounts of things automatically with very little direct control from the programmer. Coding such things manually will always give you more control and cause less headaches down the road because you know exactly how everything is setup to work.

and question why you are even using gamemaker if you feel everyone should go back to c++
There's more to GMS than it's built-in systems that would cause people to want to use it.

• Easy asset management
• A simplified language
• A simplified GUI
• Easy porting to other platforms
• Easier compiling of applications once everything is setup

Slow Fingers

Member
im not saying its one or the other but you add to it for your requirements
It's either all physics, or no physics at all. You have to plan it from the get-go.
And yes, it is harder. Maybe not for *SOME* stuff (say maybe a Pool game, or a thing like The Incredible Machine, and even then), but certainly for a platformer.
You cant use things like hsp if you're to use the physics engine, so you can already forget it unless you want to start over.

RefresherTowel

Member
@Clockwatcher To answer the topic question at hand:

If you look at your code, you are using x+hsp and y+vsp to calculate collisions. The hsp+vsp is the only movement vector that you are calculating collisions for, movement that doesn't involve those variables will not have proper collision detection applied. You can move your object directly like you are doing with your x = x + lengthdir_x(airbornerecoil, KickDirection); and corresponding y lines, but that doesn't affect your hsp or your vsp vectors and thus won't be involved in your collision detection at all. One potential solution is instead of directly moving your player when you want the kickback, you set the hsp and vsp variables to the kickback amount you want. Think of it as the kickback being like a special case of pressing a movement key.
Code:
airbornerecoil = 20;
KickDirection = (obj_gun.image_angle +180);

if mouse_check_button(mb_left)
{
hsp = lengthdir_x(airbornerecoil, KickDirection);
vsp = lengthdir_y(airbornerecoil, KickDirection);

}

// Horizontal Collision

if place_meeting(x + hsp, y,obj_wall){
while (!place_meeting(x+sign(hsp), y, obj_wall))
{
x = x + sign(hsp);
}
hsp = 0;
}

x = x + hsp;

// Vertical Collision

if place_meeting(x, y + vsp,obj_wall){

while (!place_meeting(x, y+sign(vsp), obj_wall))
{
y = y + sign(vsp);
}
vsp = 0;
}

y = y + vsp
By moving the kickback code to before the collision checks and setting hsp and vsp to the kickback amounts, instead of moving the player's x and y directly, you are naturally inserting the kickback into your already existing collision detection. As a sidenote, ending lines with a semi-colon ; is a good habit to get into as there are situations where a line ending without a semi-colon will behave differently than a line with one. I've gone ahead and inserted the appropriate semi-colons into your code.

EDIT: Wow @Tyg I wasn't trying to have a go at you, I was literally just pointing out some problems with what you were suggesting. Chill out dude.

Nocturne

Friendly Tyrant
Forum Staff
Moderator
I've tidied the topic a little to remove posts that really had nothing to do with the initial problem... I've left the start of the discussion on physics and "solid" as it's semi-relevant. Guys, please, keep discussions like this to topics where it's relevant or status updates, and don't take someone saying "I don't agree" as a personal attack. This is a community where it's okay to be told "you're wrong" as long it's done politely and with a descent amount of reason/logic/evidence to back it up. Doesn't mean "You're a bad person" or "you're stupid". It's OKAY to be wrong and it's okay to tell someone they're wrong (even if they're not and you're wrong! ). So, yeah, let's keep this on topic and help the OP like @RefresherTowel has.

Tyg

Clockwatcher

Member
Refresher Towel and Cryptid were indeed right, once I tied my kickback to hsp and vsp the collisions started to read. Huge thanks to everyone who replied tho, lots to think about for future stuff!

Thanks so much @RefresherTowel for posting that example! I didn't realize something as simple as reshuffling the kickback code so that it's infront of the collision checks would mean that the collisions would read "faster!" I was kind of on the right track of changing my kickback to vsp and hsp after @CryptidProductions suggestions but had no idea why the collisions still weren't reading. Was at a total loss!

And thank you so much @Tyg for the offers to help. I really really appreciate it!

CryptidProductions

Member
Refresher Towel and Cryptid were indeed right, once I tied my kickback to hsp and vsp the collisions started to read. Huge thanks to everyone who replied tho, lots to think about for future stuff!

Thanks so much @RefresherTowel for posting that example! I didn't realize something as simple as reshuffling the kickback code so that it's infront of the collision checks would mean that the collisions would read "faster!" I was kind of on the right track of changing my kickback to vsp and hsp after @CryptidProductions suggestions but had no idea why the collisions still weren't reading. Was at a total loss!

And thank you so much @Tyg for the offers to help. I really really appreciate it!
No problem.

Sometimes it turns out to be really silly things that break entire systems, especially when you're first getting started and not 100% sure how everything interacts. I had a similar issue of completely borked collisions early on because I didn't handle how movement values were being manipulated right.

And yeah, order of operations can be really important when coding in the step event so you don't things firing before other things in a way that breaks the game

Clockwatcher

Member
No problem.

Sometimes it turns out to be really silly things that break entire systems, especially when you're first getting started and not 100% sure how everything interacts. I had a similar issue of completely borked collisions early on because I didn't handle how movement values were being manipulated right.

And yeah, order of operations can be really important when coding in the step event so you don't things firing before other things in a way that breaks the game
Ha yeah I always knew there would be lots of things to learn for coding but I'm constantly suprised at all the things that I have to constantly keep in mind. As someone who never really had a great relationship with maths or any "logical" subjects in school, it's hard af, but really rewarding when you figure something out!