• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!
  • Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Question - Code How to prevent AI from going back to an inactive state?

Y

YuriNikolai

Guest
Hello, i'm sorry for this silly question but i have just begun studying GMS2 and don't know much about it yet. I am using the following code on a Step event to get enemies to chase the player if he gets too close to them:

if (instance_exists(obj_player) && distance_to_object(obj_player) <400)
{
move_towards_point(obj_player.x,obj_player.y,spd)
}

However, whenever the player leaves that range, the enemies stop chasing him. This is one example of an issue i've been having on many areas: I need a Step detection to trigger an event, but how can i get it to continue playing even if the conditions stop being true?
 

Slyddar

Member
Many times you will need to create variables that give you control over the states you require. In this case you could create a variable called "chasing", and in the create event set it to false. Your code would then be:

Code:
if (instance_exists(obj_player) && distance_to_object(obj_player) <400) || chasing
{
  move_towards_point(obj_player.x,obj_player.y,spd);
  chasing = true;
}
This would mean they would never stop chasing the player. If they fall out of the distance you could also have a counter that counts down and if they are outside the radius too long they will set chasing to false again, if you like.
 

JackTurbo

Member
Firstly game AI is a big area of programming and there are many many approaches. What works best will depend on your style of game and your current code base.
For most projects a finite state machine (switch statement) approach would be sufficient. If you're not too versed in those I'd suggest you read up on them.

Secondly (and this is just what I've learnt from coding my current AI) as your AI grows more complicated it becomes best to separate out your decision making code from your performing actions code.
In addition to creating a cleaner easier to debug code base this also allows you to choose when to run the decision making code. As your enemy's number of possible actions increases chances are you'll be having to evaluate many more variables about the scenario which can lead to this portion of code being quite heavy on performance (especially if lots of enemies are active). So it can be best to only do this relatively infrequently.

The Ai in my current project for example has it's decision making portion in an alarm that is set to irandom_range(10, 20), meaning it is only ran once every 10-20 frames (one sixth to one third of a second at 60fps). This is randomised to ensure that not too many AI's perform decision making on the same frame (which could cause a stutter). This has the added benefit of giving my enemies a realistic feeling reaction time.
The actual performing actions code is of course in the AI's step event so it continues to act between making decisions.

Looks like your issue is solved, but as your game develops you'll probably want to refactor your AI in the future so hopefully this might still be helpful down the line :)
 

HayManMarc

Member
On top of what TheSly said, you can make a state machine.

I use a simple variable 'state' for this. Decide what your states will be, for example: 0 = idle, 1 = wander, 2 = chase player, etc.
Then, you can make your proximity check and change the state variable to '2' if you want it to chase the player. Then, when you check the state, you will only be running that code.
Example:
Code:
if state = 0
{ //do nothing/idle code; }
if state = 1
{ //wander around code; }
if state = 2
{ //chase the player code; }
// (etc for additional states.)
I hope I explained that well enough. Good luck!
 

Slyddar

Member
Glad it worked for you. As the other guys have said, once you have played with the method you are using you will start to see shortcomings. This is where you need to look into state machines. Lots of tutorials on youtube about implementing them. They are really useful, but when starting out, personally I feel you need to get there after experimenting with other methods so you can really appreciate the freedom they give you code.

Good luck!
 
Top