A.I. Collision

Emberex

Member
I have tried my best to figure this out, and maybe I don't quite understand collisions as well as I thought. I have these "Humans" wandering around in the wander state. I need them to know collisions not to run into. Here is my most recent attempt. What am I not understanding?
GML:
``````    case hStates.wander:
//Wander Mode
wanderCounter += irandom(5);
if(wanderCounter >= 3*room_speed){
if(place_free(x + hSpeed,y + hSpeed)){
speed = hSpeed;
}
if(wanderCounter > 5*room_speed){
wanderCounter = 0;
}
}``````

Nidoking

Member
You seem to be using the "hSpeed" variable as hspeed, vspeed, AND speed. That's... not how geometry works. Triangle Inequality, Pythagorean Theorem and all that. If you're going to use place_free to check for collisions, you might as well just update x and y directly and not use direction and speed at all. Also, it looks like you're randomizing the direction (wanderRadius) but then waiting some random amount of time before actually applying it. In short, I have no idea what it is you don't understand, but there's a lot of fundamental Game Maker stuff among it. You might want to do some basic tutorials that teach movement.

Emberex

Member
You seem to be using the "hSpeed" variable as hspeed, vspeed, AND speed. That's... not how geometry works. Triangle Inequality, Pythagorean Theorem and all that. If you're going to use place_free to check for collisions, you might as well just update x and y directly and not use direction and speed at all. Also, it looks like you're randomizing the direction (wanderRadius) but then waiting some random amount of time before actually applying it. In short, I have no idea what it is you don't understand, but there's a lot of fundamental Game Maker stuff among it. You might want to do some basic tutorials that teach movement.
The hSpeed stands for Human Speed, as I will have different races in the game. Their movement is simply based on choosing a random direction and moving that direction with hSpeed. I am trying to get them to not collide with the MainHall.

Nidoking

Member
The hSpeed stands for Human Speed, as I will have different races in the game. Their movement is simply based on choosing a random direction and moving that direction with hSpeed. I am trying to get them to not collide with the MainHall.
Okay, but there is still a difference between "hSpeed to the right and hSpeed up" and "hSpeed in a random direction". Pythagoras again, as well as the most basic trigonometry. You're assuming that every angle has a sine and cosine of 1, and I don't believe that's true for any angle at all. You need to get the horizontal and vertical components of your movement if you want to do collision checks. You also don't appear to be doing the collision check until the counter gets to 3 * room_speed, so your instances have three seconds to wander through objects before they even bother to check whether that's what they've done.

Movement tutorials. What you don't understand is "everything about movement" apparently.

Emberex

Member
Okay, but there is still a difference between "hSpeed to the right and hSpeed up" and "hSpeed in a random direction". Pythagoras again, as well as the most basic trigonometry. You're assuming that every angle has a sine and cosine of 1, and I don't believe that's true for any angle at all. You need to get the horizontal and vertical components of your movement if you want to do collision checks. You also don't appear to be doing the collision check until the counter gets to 3 * room_speed, so your instances have three seconds to wander through objects before they even bother to check whether that's what they've done.

Movement tutorials. What you don't understand is "everything about movement" apparently.
I see what you're saying but I didn't ask for some smartass. I understand movement. My "humans" are moving exactly the way I want them to. I was trying yo figure out a way to stop them from colliding with the main hall. If you don't know the answer to my code, then simply say so. Asking for help, not someone to down what I've learned so far.

chamaeleon

Member
Your `x+hSpeed` and `y+hSpeed` cannot represent a downward/left or upward/right diagonal or horizontal or vertical relative test from the instance due to the same sign being used for both expressions. It can only test the same position (hSpeed is zero), left and up (hSpeed is negative), and right and down (hSpeed is positive). You need to use two different variables for this. When you use and set `direction` and `speed`, those values are available as `hspeed` and `vspeed` with their independently signed values.

Nidoking

Member
What am I not understanding?
This is the question you asked. I just answered it. The answer is basic math and movement in GML. I can't help it if the correct answer to your question sounds condescending to you.

I understand movement.
The code you posted suggests otherwise. But you have a choice. You can be petulant and waste your time defending a broken game, or you can fix the problems and have a game that works. I just think that based on what you've shown us, your understanding of the underlying concepts you're trying to use is so fundamentally flawed that you would be best served by replacing your knowledge, such as it is, with correct knowledge. Some good tutorials or a trigonometry course would be my recommendations.

Emberex

Member
This is the question you asked. I just answered it. The answer is basic math and movement in GML. I can't help it if the correct answer to your question sounds condescending to you.

The code you posted suggests otherwise. But you have a choice. You can be petulant and waste your time defending a broken game, or you can fix the problems and have a game that works. I just think that based on what you've shown us, your understanding of the underlying concepts you're trying to use is so fundamentally flawed that you would be best served by replacing your knowledge, such as it is, with correct knowledge. Some good tutorials or a trigonometry course would be my recommendations.
I don't believe that you understand. The code is working. The humans move randomly, I even jave them to return near the Main Hall if they stray. Everything works just fine, I just need a collision for their movement, to stop them when they collide and choose another way to go.

And what you said isn't the problem, it's how you are saying it. You're being an ass and telling me to go back to the beginning to learn, yet as I have told you, my movement is working just fine.

Emberex

Member
Your `x+hSpeed` and `y+hSpeed` cannot represent a downward/left or upward/right diagonal or horizontal or vertical relative test from the instance due to the same sign being used for both expressions. It can only test the same position (hSpeed is zero), left and up (hSpeed is negative), and right and down (hSpeed is positive). You need to use two different variables for this. When you use and set `direction` and `speed`, those values are available as `hspeed` and `vspeed` with their independently signed values.
I understand, but the movement works just fine, so their must be a way to collision check with it right?

chamaeleon

Member
I understand, but the movement works just fine, so their must be a way to collision check with it right?
The collision test is not movement, hence movement may work correctly while collision testing fails. See my post as to why you only check upper left corners and bottom right corners, not upper right, down left, straight up or down, or straight left or right. Movement is handled implicitly for you by setting direction and speed. Given direction and speed you need to use two independent values in your collision test for x and y respectively not one value, hSpeed.

Emberex

Member
The collision test is not movement, hence movement may work correctly while collision testing fails. See my post as to why you only check upper left corners and bottom right corners, not upper right, down left, straight up or down, or straight left or right. Movement is handled implicitly for you by setting direction and speed. Given direction and speed you need to use two independent values in your collision test for x and y respectively.
So I tell the "Human" to move at a random X value and random Y value?

Nidoking

Member
I don't believe that you understand. The code is working. The humans move randomly, I even jave them to return near the Main Hall if they stray. Everything works just fine, I just need a collision for their movement, to stop them when they collide and choose another way to go.

And what you said isn't the problem, it's how you are saying it. You're being an ass and telling me to go back to the beginning to learn, yet as I have told you, my movement is working just fine.
No, your code is broken and just happens, coincidentally, to be doing something that looks very like what you want it to do. If it were working correctly, then you wouldn't be asking for help with collisions that are not working correctly. If you can't understand the problem when it's been explained to you, then you won't have a working game, ever. Call me what you want, but my instances move AND check collision properly.

chamaeleon

Member
So I tell the "Human" to move at a random X value and random Y value?
I'm not even sure how to interpret this comment, so I'm out. If you use speed and direction, use hspeed and vspeed (with that capitalization) to access the exact amount the instance would move in x and y respectively the next time those values updates. Those offsets makes an excellent first point to test for collision.

Emberex

Member
No, your code is broken and just happens, coincidentally, to be doing something that looks very like what you want it to do. If it were working correctly, then you wouldn't be asking for help with collisions that are not working correctly. If you can't understand the problem when it's been explained to you, then you won't have a working game, ever. Call me what you want, but my instances move AND check collision properly.
Either way, I'm getting real help with kindness from another. I'm done with your replies. I appreciate the help but you're an ass and therefore not worth talking with.

Emberex

Member
I'm not even sure how to interpret this comment, so I'm out. If you use speed and direction, use hspeed and vspeed (with that capitalization) to access the exact amount the instance would move in x and y respectively the next time those values updates. Those offsets makes an excellent first point to test for collision.
I'm not using hspeed and vspeed. hSpeed is my own variable(capitalization in S) I need to change it being it's too close. I don't use built-in variables if I can help it.

chamaeleon

Member
I'm not using hspeed and vspeed. hSpeed is my own variable(capitalization in S) I need to change it being it's too close. I don't use built-in variables if I can help it.
But you are using the built-in variables when you set direction and speed.... hspeed and vspeed will be computed by GMS as a result, and you are free to use or ignore them as you wish. But if you do use speed and direction, why wouldn't you use them? hSpeed cannot represent the information you require. The information you require is contained in hspeed and vspeed, if you wish to test a position the instance will move to the next step. The information is computable as well using sin and cos, or lengthdir_x and lengthxdir_y using directions and speeds, but why bother, when GMS does it for you. If you forgo the use of direction and speed (because you don't want to use built-in variables), you'll need hSpeed and vSpeed variables.

Emberex

Member
But you are using the built-in variables when you set direction and speed.... hspeed and vspeed will be computed by GMS as a result, and you are free to use or ignore them as you wish. But if you do use speed and direction, why wouldn't you use them? hSpeed cannot represent the information you require. The information you require is contained in hspeed and vspeed, if you wish to test a position the instance will move to the next step. The information is computable as well using sin and cos, or lengthdir_x and lengthxdir_y using directions and speeds, but why bother, when GMS does it for you. If you forgo the use of direction and speed (because you don't want to use built-in variables), you'll need hSpeed and vSpeed variables.
Okay, I am posting this to thank you and for future people needing help. I finally got it by evaluating what you all were saying. Here's what I have and it seems to be working!
GML:
``````    //Wander Mode
wanderCounter += irandom(5);
if(wanderCounter >= 3*room_speed){
if(place_meeting(x + hposX,y,oMainHall)){
while(!place_meeting(x + sign(hposX),y,oMainHall)){
x += sign(hposX);
}
hposX = 0;
}
if(place_meeting(x,y + hposY,oMainHall)){
while(!place_meeting(x,y + sign(hposY),oMainHall)){
y += sign(hposY);
}
hposY = 0;
}
x += hposX;
y += hposY;
if(wanderCounter > 5*room_speed){
wanderCounter = 0;
hposX = 0;
hposY = 0;
hposX = choose(-0.5,0.5);
hposY = choose(-0.5,0.5);
}

}``````
Thank you so much! I believe this has given me a better understanding of how it all works and I can implement this into future projects.

Nidoking

Member
You're welcome.

But I recommend keeping the thread open so that when you discover that your instance will happily walk right into the oMainHall if it hits the corner exactly, you can come back and ask how to fix it. Also, in case you want to know why your instance moves twice the distance in one step when it actually collides with the oMainHall. Maybe that's not noticeable when you're only moving half a pixel per step. And you've cut down the movement of your instance to only four possible directions, which are all diagonal. Is that what you wanted?

See, I still don't think you understand how it works. You've just come up with a less functional method that doesn't exhibit the same problem the old one did most of the time.

Emberex

Member
You're welcome.

But I recommend keeping the thread open so that when you discover that your instance will happily walk right into the oMainHall if it hits the corner exactly, you can come back and ask how to fix it. Also, in case you want to know why your instance moves twice the distance in one step when it actually collides with the oMainHall. Maybe that's not noticeable when you're only moving half a pixel per step. And you've cut down the movement of your instance to only four possible directions, which are all diagonal. Is that what you wanted?

See, I still don't think you understand how it works. You've just come up with a less functional method that doesn't exhibit the same problem the old one did most of the time.
I thanked everyone out of kindness, I still prefer you not to reply anymore. You're rude and haven't showed anything to show that you even know what you are talking about. Do you have any finished games?

TsukaYuriko

š
Forum Staff
Moderator
This is a support forum, not a battlefield. If this ends up in a fight, I'll have to lock this topic. So please keep things on topic and relevant to helping to resolve the issue presented in this topic - if there is any place for personal insults, this is not it.

Emberex

Member
This is a support forum, not a battlefield. If this ends up in a fight, I'll have to lock this topic. So please keep things on topic and relevant to helping to resolve the issue presented in this topic - if there is any place for personal insults, this is not it.
Thank you so much.

Joe Ellis

Member
Is the thing you want to happen that they plan to move to a certain spot, and if it's free and they're able to walk there they will?

The wandering angle can be set randomly, if they bump into a wall they'll change the angle to at least 90 degrees away from the wall (cw & ccw) Also with the planning, say it has the angle, then it'll check along the line they'll walk and see if there is any collision within a certain amount, if there is it'll choose a new angle until it has a clear path to walk for a few meters

Emberex

Member
Is the thing you want to happen that they plan to move to a certain spot, and if it's free and they're able to walk there they will?

The wandering angle can be set randomly, if they bump into a wall they'll change the angle to at least 90 degrees away from the wall (cw & ccw) Also with the planning, say it has the angle, then it'll check along the line they'll walk and see if there is any collision within a certain amount, if there is it'll choose a new angle until it has a clear path to walk for a few meters
I want them to walk randomly and freely around an instance, without bumping into it. I have that now and they are working, thank you.