Artificial Stupidity

[dandymcgee]

I had this big ass post written up when halfway through I realized I was just recreating a post Falco made to me a year and a half ago. I recommend you both of the following topics a thorough read and come back with any specific questions you might still have.

Original topic:
http://elysianshadows.com/phpBB3/viewto ... f=6&t=4130

Corrected code:
viewtopic.php?f=6&t=4255&p=49381&hilit= ... lap#p49381

[lotios611]

My problem (at least in my mind) has nothing to do with collision. I'm simple trying to get the AI's x and y to the gem's x and y.

[dandymcgee]

My problem (at least in my mind) has nothing to do with collision. I'm simple trying to get the AI's x and y to the gem's x and y.

I thought you had already accomplished that and were having trouble getting it to stop when it reached the gem (a.k.a. collided with the gem)?

[EccentricDuck]

My problem (at least in my mind) has nothing to do with collision. I'm simple trying to get the AI's x and y to the gem's x and y.

The issue is that, so long as you increment more than one base unit every update call there's a chance of overstepping your target (throw floating point values into the mix and you're almost certain to overstep your target). It's the nature of computers, but everything happens in discrete steps. If you're moving from 0 to 31 on the x axis, for example, and your movement interval is in units of 3, you'll never land exactly on your target. You'll eventually reach 33, then bob back and forth between 30 and 33.

To correct for that you need to change how you do collision detection. The simplest way would just be to say if a character is within 2 units then it's a collision. I'm not sure if 1 unit is an entire sprite tile or if it's a much smaller amount, but if it's a much smaller amount you could make your collision radius even higher.

[Rebornxeno]

Actually, what I believe is going on is that his AI is stupid. Hehe, I had a similar problem in a game I made to learn programming with. I had a player that could shoot bullets, and the bullets would know when to die because they would hit the x,y that the mouse was aiming at. I used the same thing the OP used in terms of moving the bullet, and what I found was that it died sometimes, and others times it did not, and got stuck etc etc... It turns out that just doing x++ x-- and y++ y-- depending on the position is not always enough. The computer will "miss". What you need, is to determine the angle at which your computer needs to move. It has to move a certain amount of Y per X, so to speak, so that it hits precisely where the gem's position is located. This link will help you in this regard, ***http://www.dreamincode.net/forums/topic ... g-bullets/***

However, taking a look at the game of "pickin sticks" I see that is not necessarily a problem of accuracy of your AI, but a matter of your collision detection. With the gem, pinpoint accuracy of 1pixel is not needed. You should make a bigger box around the gem that the game checks for collision against, so that your AI does not need to be so accurate, and your AI walking "over" your gem will pick it up. If your still confused, instead of doing:

if (AI.x == gem.x && AI.y == gem.y){
}

do:
if (AI.boundingbox.intersects(gem.boundingbox()){
}

Sorry if I interpreted your problem wrong, if I did feel free to steer me in the right direction so that we can get you to back to programming.

[EccentricDuck]

It has nothing to do with the AI being stupid. It's a simple AI that does what it's designed to do. The issue is that the collision, as you also pointed out, isn't being calculated because of the precision of detection relative to the step size of the AI. It keeps stepping over the object and collision detection is limited to only the tiniest point in the centre of the object.

[lotios611]

Alright, I fixed my problem by adding a few if statements that checked to see if the AI was less than 2 pixels away from the gem, and if it was, only move one pixel (if I wanted to, I could abstract it so that it would check to see if the gem was less than x pixels away from the AI (x being however many pixels the AI normally moves each frame) and if so, find the distance in pixels away from the gem, but in this case, one is the distance away).

Thanks for the help guys! I'm almost done version 1 of Pickin' Gems, and when I finish, it will be the first game I make. I only need to fix one more thing (when the gem is right at the bottom of the screen, the AI just keeps trying to bring it's x position to equal the gem's x position, but it can't because I made it so that the player can't exit the screen) NVM, it turns out to be a non-issue because my AI adjusts it's x before it's y. It would be an issue if it adjusted it's y before it's x though. I just need to make some menu graphics and the gem picking sound, and it will be done!

[EccentricDuck]

Awesome, sounds good. With the way you're doing it, it means your movement always has to be tied to the collision distance of an object on screen. It adds complexity to every AI routine you might develop rather than to your collision system. That's not necessarily a bad thing, but it is a choice. The important thing is that it works with what you're trying to do now though

[lotios611]

I don't think you're understandng my problem. Just as an example, imagine that the AI's x and y both start at 0 and the gem's x and y are 201 and 448.The AI would start increasing it's x by 2 because it is less than the gem's x. Once the AI got to 200, 0, it would increase it's x to 2, but then on the next frame, it would decrease it by 2 because the AI's x position is greater than the gem's. It would keep going forever in a loop of inreasing and decreasing.

[EccentricDuck]

I don't think you're understandng my problem. Just as an example, imagine that the AI's x and y both start at 0 and the gem's x and y are 201 and 448.The AI would start increasing it's x by 2 because it is less than the gem's x. Once the AI got to 200, 0, it would increase it's x to 2, but then on the next frame, it would decrease it by 2 because the AI's x position is greater than the gem's. It would keep going forever in a loop of inreasing and decreasing.

I get that, but what I'm saying is that instead of having to add the correction code for that into your AI to move it in a smaller increment, you could implement that in your collision detection and have it do the same thing. There's really nothing wrong with doing it either way in the context you're talking about - I'm just outlining another option and why someone might do it that way.

If you were to get to frame 200 and you had your collision detection routine detect collision within a range of 1 then you could achieve the same thing, eg:

Code: Select all

// Calculate the distance between the positions
int delta = (int)player2Pos.x - (int)gemPos.x;
// Change the distance into an absolute value
if (delta < 0) {
    delta = -delta;
}
// Check if the difference between the players is smaller than or equal to a particular value (in this case 1)
if (delta <= 1) {
    COLLISION = true; // put however you handle a collision in here
}

It's not wrong to handle it the way you handled it, especially for Pickin' Sticks since the way you're doing it accomplishes your goals (which is the the most important thing).

This is just feedback if you wanted to try taking a similar approach elsewhere. The main issue is that the AI needs to specifically home in on a particular small point on an object in order to initiate a collision. This is fine if the AI initiates all movement itself, but as soon as you throw anything like basic physics or random behavior into the mix you suddenly make it very hard for the AI routine to manually home in on that one very specific point. By doing it more generally by checking it in your collision detection routine you make it so that any force that makes your AI agent bump into an object will initiate a collision without skipping past that small point. Once again though, it's a non-issue if your approach is constrained to Pickin' Sticks and there's no other way to manipulate the AI agent's movement (like having your player push them).

[lotios611]

I don't think you're understandng my problem. Just as an example, imagine that the AI's x and y both start at 0 and the gem's x and y are 201 and 448.The AI would start increasing it's x by 2 because it is less than the gem's x. Once the AI got to 200, 0, it would increase it's x to 2, but then on the next frame, it would decrease it by 2 because the AI's x position is greater than the gem's. It would keep going forever in a loop of inreasing and decreasing.

I get that, but what I'm saying is that instead of having to add the correction code for that into your AI to move it in a smaller increment, you could implement that in your collision detection and have it do the same thing. There's really nothing wrong with doing it either way in the context you're talking about - I'm just outlining another option and why someone might do it that way.

If you were to get to frame 200 and you had your collision detection routine detect collision within a range of 1 then you could achieve the same thing, eg:

Code: Select all

// Calculate the distance between the positions
int delta = (int)player2Pos.x - (int)gemPos.x;
// Change the distance into an absolute value
if (delta < 0) {
delta = -delta;
}
// Check if the difference between the players is smaller than or equal to a particular value (in this case 1)
if (delta <= 1) {
COLLISION = true; // put however you handle a collision in here
}

It's not wrong to handle it the way you handled it, especially for Pickin' Sticks since the way you're doing it accomplishes your goals (which is the the most important thing).

This is just feedback if you wanted to try taking a similar approach elsewhere. The main issue is that the AI needs to specifically home in on a particular small point on an object in order to initiate a collision. This is fine if the AI initiates all movement itself, but as soon as you throw anything like basic physics or random behavior into the mix you suddenly make it very hard for the AI routine to manually home in on that one very specific point. By doing it more generally by checking it in your collision detection routine you make it so that any force that makes your AI agent bump into an object will initiate a collision without skipping past that small point. Once again though, it's a non-issue if your approach is constrained to Pickin' Sticks and there's no other way to manipulate the AI agent's movement (like having your player push them).

Alright, I understand your side now. Thanks for the info, I'll take that into consideration next time I have to program AI.