GameMaker [SOLVED]Object changes direction once before doing what it's supposed to do.

I'm working on the AI of a new enemy. It's a long way from done but the things I've made so far is working except for one highly annoying thing:

Short background:
When the enemy is in the state "moving" it's.. just moving and if the player gets into its line of sight it'll change state to "init_attack" where it should run towards the player and then change state to the "attack" state.

EDIT: All tiles and most sprites are placeholders. I do however apologize for the "enemy" which is a placeholder for the placeholder.

The problem:
When the enemy "sees" the player it instantly changes to the opposite direction, runs to a wall and then it runs towards the player and does what it's supposed to do.

If you look at the GIF below you'll see that as soon as the player jumps over the wall (that's when the enemy "sees" him) he changes direction and hits the far wall before running towards the player.


The code:
This is the MOVING-state in the machine
Code:
show_debug_message("MOVING")

alertTimer = 0;

if (inLos)
{
   counter++;
   if (counter >= 10)
   {
       counter = 0;
       state = enemyAI.ALERTED;                           // Change state if SEEN by enemy
   }
}
else counter = 0;

      
scrAICollider();                                           // Call collision script
And this is the INIT_ATTACK-state
Code:
    show_debug_message("init_Attack");
   hsp = runsp;
  
  
   if (!inLos)                                       // When not seeing player, init state change
   {
       counter++;
       if (counter >= runSuccess)
       {
           counter = 0;
           recentlySeen = true;
           state = enemyAI.SEARCHING;              
       }
   }
   else counter = 0;                          

       if (collision_line(x, y, target.x, target.y, objWall, true, true) = noone) // If nothing between player and NMY...
       {   
          
           if (collision_circle(x, y, 32, target, false, false))
           {
               state = enemyAI.ATTACKING;
           }
          
        }

  
eAI_IA_Collision();
There's two different collision checks called from the different states. Here's both of them:

Collision check from the MOVING state:
Code:
// Behaviour

   vsp = vsp + grv;
// Don't walk off ledges (Shaun Spalding)
if (grounded) && (vertigo) && (!place_meeting(x + hsp, y+1, objWall))
{
   hsp = -hsp  
}
// Colliding horisontally?


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





// Colliding vertically?
if (place_meeting(x, y+vsp, objWall))
{
  
   while (!place_meeting(x,y+sign(vsp),objWall))
   {      
       y = y + sign(vsp);
   }
  
   vsp = 0;

}
y = y + vsp;


And this is the collision check called from the INIT_ATTACK-state
Code:
// Running into walls?

if (place_meeting(x+runsp, y, objWall))
{
   while (!place_meeting(x+sign(runsp),y,objWall))
   {
   x = x + sign(runsp);
   }
   runsp = -runsp;
}

x = x + runsp;

All thoughts, tips, tricks, help would be immensely appreciated!!
<3
 
Last edited:

Slyddar

Member
Whats the difference between runsp and hsp? Why not just use hsp and leave your runsp as a constant from the create? You enemy has no facing direction at the moment due to the sprite. Maybe add a facing variable and use that to determine the movement speed, i.e hsp = runsp * facing, and set hsp to -hsp when colliding with a wall.
There might be a mix up and at the point it's moving the wrong way it's because it's using an old positive value. Try adding a breakpoint and stepping through to monitor what happens.
 
Whats the difference between runsp and hsp?
Why not just use hsp and leave your runsp as a constant from the create?
HSP = walksp; most of the time. When the enemy is supposed to run HSP = runsp;
Both walksp; and runsp; is initiated on create.
(Having some problems with it though, hence me not using the HSP consistently yet.)


You enemy has no facing direction at the moment due to the sprite. Maybe add a facing variable and use that to determine the movement speed, i.e hsp = runsp * facing, and set hsp to -hsp when colliding with a wall.
There might be a mix up and at the point it's moving the wrong way it's because it's using an old positive value. Try adding a breakpoint and stepping through to monitor what happens.
This is good! I'll try this. Thank you!
EDIT 1 : actually.. it has a facing directiong. Look at it's mouth changing when he changes direction. I still think your tip is valid though, 'cause how I made it work. So I'll try it for sure!
EDIT 2 : (actually it's facing the player in certain states but I haven't made it so that the sprite changes direction when hitting a wall. It must be this! Again, thank you! Now I'll try to fix it :)
 

Slyddar

Member
HSP = walksp; most of the time. When the enemy is supposed to run HSP = runsp;
Both walksp; and runsp; is initiated on create.
(Having some problems with it though, hence me not using the HSP consistently yet.)
Just have a walkspd, runspd and spd and set spd to whatever it needs to be, depending if you need to run or walk. That way you can set hsp = spd * facing and always use it for calculations.
 
M

mamacato

Guest
I might be wrong but where is the x, y coordinates on the enemy sprite. Spr_movingman, or whatever.


By the way and probably my main point: that game looks weird... (´・` ) thích !
 
Just have a walkspd, runspd and spd and set spd to whatever it needs to be, depending if you need to run or walk. That way you can set hsp = spd * facing and always use it for calculations.
Yeah I changed it and made it work using your suggestions earlier. Many thanks for taking the time!

I might be wrong but where is the x, y coordinates on the enemy sprite. Spr_movingman, or whatever.


By the way and probably my main point: that game looks weird... (´・` ) thích !
So your main point in this thread was "that game looks weird"?
I appreciate your highly constructive input.
Apart from the sprites being placeholders I guess you're right though... it is weird.
Guess there's no better way of decribing playing as a fart than.... weird.
Read more about the weirdness here.
 
M

mamacato

Guest
So your main point in this thread was "that game looks weird"?
I appreciate your highly constructive input.
Apart from the sprites being placeholders I guess you're right though... it is weird.
Guess there's no better way of decribing playing as a fart than.... weird.
Read more about the weirdness here.
Indeed. As stated. I put an emoji that seems to be deriving pleasure from something (your game) and I wrote thích, which means 'like'.

Edit: lol, nice webpage!
 
Last edited:
Indeed. As stated. I put an emoji that seems to be deriving pleasure from something (your game) and I wrote thích, which means 'like'.
Never heard of it. I thought you had some sort of keyboard epilepsy fit in the moment of typing. Guess I'm too old (and/or uneducated in the lingo) to get it. :)

Edit: lol, nice webpage!
<3
 
Top