I only put the "health" on the family because there is no way to get to the "myhealth" on the family member, but that means all family members have the same "health" value, its global to the family and not independent to the family member.

That is incorrect.

All family members will share the variable name, however each value is separate to each instance.

Example:

Family members: Mom, Dad, Son

Family Variable: "Health" = 0

In the properties menu of:

Mom > Instance Variables > Heatlth = 90 ; Dad = 100 ; Son = 60

Event: Family gets hit by a brick; Action: subtract 20 from health

Which ever member is hit will lose 20 health relative to there own health

Lets say Dad and Son gets hit, Dad now has 80 health and Son has 40.

To get the Son's health simply request son.health

The fact that the authors of the engine arrive logically does not make their decisions correct. All these clone applications that are made on Construct...

Oh but it does, they calculate how much effort it's going to take to maintain and grow the engine and put an offer on the table.

Clones are made on all types of engines, people tend to make what they can comprehend.

Ashley consciously makes this choice. He understands what he is taking on board, and what he leaves behind. Those who see all this marketing struggle for a place under the sun, understand that conversations here will not help.

Yes he does, and he does a pretty good job at it.

The conversation is 'Why Construct 3' hence the tittle. There're counters relating to marketing, so that's were the conversation goes.

If all of the enemies have the same Instance variable names with the same intentions then use family variables. You can still set them separately. Family variable are the same as instance variables, they just make building your logic go a little faster and keeps the event sheets clean.

There should not be any difference in how you call them. The only difference is how you can call events and set actions, it should not change how you reference them with the syntax either.

I believe it is how images are drawn to the canvas.

I'm not a tech expert so the best way I can explain it is when you are working with in an image editor you are manipulating pixels, that's why that software exists.

Game engines take an image and project it on a canvas, I hope someone with some real knowledge can explain it better, all I know is I had stuff like this happen in other game engines.

That's not a Construct isolated thing.

For your sprite issue, did you try clicking on the crop button at the top of the animation editor is a button called crop transparent edges. This should fix that mutation.

Persistence pays off:

indeed it does.

I think that C3 is good for its creators only. To me (and all users I've talked to) it was completely unnecessary to make a new Construct instead of putting all these new features on existing C2 engine.

As true as this may be I doubt it. Software can get out of hand, from what I understand the Gullen brothers were probably in their 20's when building C2, I'm sure mistakes were made. All of the wisdom in the world wouldn't get you to build the perfect modular piece of software.

I wouldn't use the else, that may be stopping the loop if you are only spawning one character.

Create a new save so you can easily go back to your method if you want to build from there.

What I would do is this. Create a local variable number leave 0, I'll call it "EnemySpawned"

Create an action that sets EnemySpawn to 0 after the GroupSize action is set to the random number.

Contain your random with an int so there can't be decimals, int(random(x,x))

Delete loop condition.

New condition, System compare - "EnemySpawned" !=(not equal to) "GroupSize"

change your else condition to - "EnemySpawned =(is equal to) GroupSize"

add another condition - Trigger once while true

Start from there, you should be able to take care of the rest but I'll keep an eye on the post.

Okay, use a sub event of the loop, every X seconds.