Skip to main content
added 1 character in body
Source Link
Philipp
  • 123.2k
  • 28
  • 264
  • 345

Two common patterns for implementing simple AI behaviors like you saw them in the classic 2D Zelda games are:

  • State Machines. State machines are a general architectural pattern in software development with great potential for senseless overengineering. So if you ask 10 programmers to implement a state machine, you get 20 different solutions. But a simple one is to give every enemy a variable that says in which state it currently is (moving, turning, attacking, etc.). Your _process / _physics_process would then be a if/elif chain with separate code for each possible state to perform whatever the enemy is supposed to do during that state and checking the conditions to switch to a different state.
  • Behavior Trees. Another common pattern for simple enemy AI. The main difference between BT and SM is that a behavior tree doesn't remember which state itsit's in but rather determines the state again on each frame. You can express that logic using a data-driven approach as explained in the article I just linked. Or you can do it the simple way using an if/else tree checking all the relevant information and then behaves according to the result.

Two common patterns for implementing simple AI behaviors like you saw them in the classic 2D Zelda games are:

  • State Machines. State machines are a general architectural pattern in software development with great potential for senseless overengineering. So if you ask 10 programmers to implement a state machine, you get 20 different solutions. But a simple one is to give every enemy a variable that says in which state it currently is (moving, turning, attacking, etc.). Your _process / _physics_process would then be a if/elif chain with separate code for each possible state to perform whatever the enemy is supposed to do during that state and checking the conditions to switch to a different state.
  • Behavior Trees. Another common pattern for simple enemy AI. The main difference between BT and SM is that a behavior tree doesn't remember which state its in but rather determines the state again on each frame. You can express that logic using a data-driven approach as explained in the article I just linked. Or you can do it the simple way using an if/else tree checking all the relevant information and then behaves according to the result.

Two common patterns for implementing simple AI behaviors like you saw them in the classic 2D Zelda games are:

  • State Machines. State machines are a general architectural pattern in software development with great potential for senseless overengineering. So if you ask 10 programmers to implement a state machine, you get 20 different solutions. But a simple one is to give every enemy a variable that says in which state it currently is (moving, turning, attacking, etc.). Your _process / _physics_process would then be a if/elif chain with separate code for each possible state to perform whatever the enemy is supposed to do during that state and checking the conditions to switch to a different state.
  • Behavior Trees. Another common pattern for simple enemy AI. The main difference between BT and SM is that a behavior tree doesn't remember which state it's in but rather determines the state again on each frame. You can express that logic using a data-driven approach as explained in the article I just linked. Or you can do it the simple way using an if/else tree checking all the relevant information and then behaves according to the result.
Source Link
Philipp
  • 123.2k
  • 28
  • 264
  • 345

Two common patterns for implementing simple AI behaviors like you saw them in the classic 2D Zelda games are:

  • State Machines. State machines are a general architectural pattern in software development with great potential for senseless overengineering. So if you ask 10 programmers to implement a state machine, you get 20 different solutions. But a simple one is to give every enemy a variable that says in which state it currently is (moving, turning, attacking, etc.). Your _process / _physics_process would then be a if/elif chain with separate code for each possible state to perform whatever the enemy is supposed to do during that state and checking the conditions to switch to a different state.
  • Behavior Trees. Another common pattern for simple enemy AI. The main difference between BT and SM is that a behavior tree doesn't remember which state its in but rather determines the state again on each frame. You can express that logic using a data-driven approach as explained in the article I just linked. Or you can do it the simple way using an if/else tree checking all the relevant information and then behaves according to the result.