Multi-target enemy state machine AI

0 favourites
  • 4 posts
From the Asset Store
State Machine
$10.99 USD
State Machine is a great tool for managing the state of anything in your game.
  • My project is maybe slightly out of the scope of Construct 3, but I'm wondering if anyone else has attempted this or something like it with success.

    Basically I have a state machine that worked well when I had all the enemies targeting the same thing (the Player object). My previous state Machine looked like this:

    EnemyMob 'EnemyType' var =Goblin

    EnemyType 'State' = Idle

    Do this stuff

    EnemyType 'State' var = Wander

    Do this

    etc.

    This seemed to work okay but recently I have been trying to expand it a bit and make it capable of not just attacking any nearby target in the "Ally" family.

    My main issue however is that now that I'm attaching a 'TargetUID' var to the Enemies and making them target a 'MobAlly' with a specified UID, they kind of run each others code a lot of the time. It works fine when there is only 1 enemy I am testing but be the more I add the buggier it gets and the more they stutter around, switching from their target to another Enemy's target.

    I'm looking for a way to make these enemies trigger their own events, but I know construct can be a bit limited in the way that it is set up.

    Things I've tried:

    - Making everything timer based, random(.05,.3) so that the mobs triggered their events somewhat staggered { this helped somewhat but there will still stutters the more enemies were added }

    - Making the enemies call Functions that run the code and sending over the UID fingerprints of the Enemy running the code and their 'TargetUID' var {the limitation with this being (as I am understand) you can only run a function once at a time.}

    - I've tried some stuff with "For Each" loops but it seemed to make things stutter more often.

    Any ideas would be welcome, I have been trying to get a solid foundation for AI in my game leaving it open ended for me to create any allies/enemies, but I've been at a bit of a roadblock for the last 2 days.

    Tagged:

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Edit: This seemed to work okay but recently I have been trying to expand it a bit and make it capable of not just attacking **the player but** any nearby target in the "Ally" family.

  • Hmm... maybe give the enemies a instance variable called targeted and the machines line of sight and also a instance variable attack. Then you can do if machine has line of sight set attack to true. If machine attack is true then you can have it do whatever and also set targeted true for the enemy if machine is in line of sight and maybe that way you can have it set so if machine is in line of sight and enemy is set to targeted then it won't attack that enemy. It will wait until an enemy comes into that isn't already targeted. You obviously don't have to do it exactly like this but it might help you come up with a fix.

  • Seems like you've got everything right - a state machine based on instance variables and timers, families, functions etc. That's how games with multiple enemies are made in Construct.

    Don't use top-level events like "Enemies state=attack : do something", this is bad practice and bad for performance.

    Use Timer behavior to change enemy states and to switch targets. Use LOS and Pathfinding behaviors to look for targets and chase them.

    There are lots of ways to pick targets. You can, for example, do something like this if you don't want all enemies to attack one target:

    Enemy On "pick_new_target" Timer
    Enemy Pick Allies in LOS
    
    .. For each Allies
    .... Enemies pick All
    .... Pick Enemies that are already targeting this Ally -> Save their count in an instance variable Allies.targetedBy
    
    .. Pick Allies instance with the lowest targetedBy value 
    

    If you are new to C3, one of the most important concepts is picking. Once you understand how instances are picked in events (and in nested events), it all starts to make sense.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)