Boolean condition

Containers are useful for objects that exist together. For example - Enemy, EnemyShadow, EnemyHealthBar.

They save you a hassle of creating/destroying each object separately.

Also, all three instances of these objects are logically linked. So when you pick one enemy in an event, you can refer to its shadow and health bar in the same event without the need to pick them by EnemyID.

No, replacing "wolf" sprite with "wolf" family makes no sense... Will wolf be the only enemy type in your game? I guess not. So your family should be called Enemies. And your wolf sprite should be called Wolf. If you add Bear, Goblin etc, you add them to the Enemies family and they will inherit all Enemies instance variables and behaviors.

Have you followed that tutorial and moved wolf's instance variables and behaviors to the family level?

https://www.dropbox.com/s/d8ixyngt11aoo ... .capx?dl=0

Looks ok, but change the names - the sprite should be named Wolf and the family should be Enemies.

Do the same with Player and NPC, add them to Friendlies or Allies family. But only move instance variables and behaviors that both Player and NPC have (and future allies will have). For example move Mana and Health to the family, but ScrollTo behavior should remain at Player sprite.

After you do that, you should be able to remove the whole WolfAttackNPC group and maybe optimize lots of other events in your project.

https://www.dropbox.com/s/cm0enqevtlec1 ... .capx?dl=0

So because the wolf AI got too complicated and kinda out of control so I just disabled it, and put down a quick code for pathfinding to the "Allies" Family. I put what behaviours I could into the Allies family, and the Enemy family is complete with all of the wolf instance variables and behaviours(and renamed them). I made all events that refer to a layouts layers named instead of by numbers.

I ran into a few issues I cant figure out with the change though, you said I could possibly remove the PlayerReach/NoticeRange/AttackRange by using a distance event and instance variable but I cant seem to find any condition that would work for that. I thought there was a "within distance of" but yeah, I couldn't find it. And then there is the wolves, when my player attacks them I cant just select the enemy(ies) thats overlapping the AttackRange for some reason, I tried a few things but they didn't work. And then there is picking up Items. I put all the PlayerReach/NoticeRange/AttackRange in a container and to spawn on all allies, because I cant find a "within distance of" condition when I pick up an item its only on the condition of "is overlapping PlayerReach" when the NPC reach circle is overlapping one it will pick it up too. Of course this could be fixed by just using seperate circles like I was before, or using the within distance of condition that I cant find.

Other issues include the NPC animation not working(I tried so many thing I dont know what Im doing wrong), the Wolf AI still being funky, it seems that my players attack escaltes to higher number the longer I attack(Or be in the negatives and add health to the enemy but I have no idea why. I cant always reproduce it either so it may be fixed), I thought I fixed that by resetting the base attack to 10 every time you attack, but it may not function correctly.

Oh, and let me know if you want to stop helping me out with this! Im not trying to take advantage of you or anything, I seriously appreciate the help, Ive not had anyone yet help me as much as you have. Thank you.

Good job with the families! I know it's an annoying task converting objects to families, but it will pay off later.

A few more things you can improve -

If you are planning to have more allies, move pathfinding and LOS behaviors to the Allies family.

You can disable them specifically for the player sprite on start of layout.

Also, you can add AllyType variable, so you could use code like this:

Allies have LOS to Enemies

and Allies.AllyType not equals "player" -> (attack enemy)

Same with Enemies family, you can add EnemyType if you need to differentiate your events slightly for different enemies. Say, some enemies can fly over obstacles, others don't etc.

Regarding Reach circles - there is no point in adding them to a container without the player/NPC/enemy.

Unfortunately, you can't add a family to the container.

If you want to use variables instead of these circle sprites, you can try something like this:

On every tick

For each Enemies

.... Pick Allies by evaluating Distance(Enemies.x, Enemies.y, Allies.x, Allies.y)<NoticeRange

On a second thought, a much better solution would be adding several LOS behaviors, name them LOS_Notice, LOS_RangedAttack, LOS_MeleeAttack ect.

Set different range for each behavior, different obstacles.

Here is an example of a very simple AI:

For each Enemies

...If Enemies has LOS_MeleeAttack to Allies -> (melee attack)

...Else If Enemies has LOS_RangedAttack to Allies -> (ranged attack)

...Else If Enemies has LOS_Notice to Allies -> (move closer)

...Else (patrol)

Your NPC animation speed is 0, maybe that's why it's not playing. Open NPC sprite, select animation, you can change its speed in the properties bar on the left.

It's hard to say what's wrong with your AI code as almost all events are disabled.

I recommend you start with a simple AI and then gradually add more features to it.

How would I keep all the behaviours/LOS events from all going off at once though?

Not sure what you mean.

If this was my game, I would probably use Timer a lot.

Run a recurring timer on each enemy, say for random(1,2) seconds.

So every 1-2 second on timer event I'd check different LOS (attack, notice etc) and adjust enemy's current action if something has changed since previous timer event.

For example if this enemy is attacking, check LOS_Attack, if it's true, continue attacking. Otherwise check LOS_Notice, if it's true, stop attacking and start chasing. And so on..