Huge Families

I'm a bit curious about a specific scenario.

Let's pretend you have two families; "playerProjectile" and "enemies". Now, let's also pretend each of those families have over 200 objects in each of them. When you do a "for each" loop on say, <is playerProjectiles overlapping enemies>, does it have to check for every single instance of that family even if 99% of the sprites aren't even in the layout?

If this is still the case (I believe it was in C2, hence my asking), what would a way around this be without having to manually do overlap checks (or other random things)?

Conditions only check the instances picked by previous conditions. So you can use a condition to filter down the picked instances to just a few, and then the next conditions will only run on those instances.

Testing overlaps is actually a good way to filter down instances, because it uses the collision cells optimisation to avoid even checking far-away instances. So it can even scale to enormous layouts with thousands of instances and stay efficient.

Conditions only check the instances picked by previous conditions. So you can use a condition to filter down the picked instances to just a few, and then the next conditions will only run on those instances.

Testing overlaps is actually a good way to filter down instances, because it uses the collision cells optimisation to avoid even checking far-away instances. So it can even scale to enormous layouts with thousands of instances and stay efficient.

I've been kind of nervous for a while wondering if I was doing something wrong by using overlap checks a lot

Good to know it's efficient!

Conditions only check the instances picked by previous conditions. So you can use a condition to filter down the picked instances to just a few, and then the next conditions will only run on those instances.

Testing overlaps is actually a good way to filter down instances, because it uses the collision cells optimisation to avoid even checking far-away instances. So it can even scale to enormous layouts with thousands of instances and stay efficient.

So does that mean, in theory, if I do a for each enemies, I should create a Boolean that says “Exists” and check that first before the for each? (And Exists would always be true, but it would stop the for each from checking objects that don’t exist)

Hopefully that makes sense? I’m only asking because I remember seeing a tutorial on the subject (that I would have to do some digging for) that stated that checks with families checked for every sprite in the family even if they didn’t exist in the layout.

So does that mean, in theory, if I do a for each enemies, I should create a Boolean that says “Exists” and check that first before the for each?

Do you mean comparing a boolean instance variable? That doesn't seem to make sense, because the object still exists even if you set that to false...

Anyway, normal conditions do an internal for-each loop along the lines of "for each instance, if it matches the condition, pick it". So if you have 1000 instances, starting with a "compare boolean" condition for example would still iterate 1000 instances, so it doesn't avoid the problem of checking lots of instances. Only "is overlapping" has the special quality of being able to entirely skip far-away instances via collision cells.

Checking a boolean instance variable first might help if later conditions are particularly slow, and it's much faster to first filter by a boolean, but I think such cases are rare.

I remember seeing a tutorial on the subject (that I would have to do some digging for) that stated that checks with families checked for every sprite in the family even if they didn’t exist in the layout.

That's incorrect, because objects that don't exist, don't exist. Events can't pick nonexistent objects and run actions on them. So I guess the tutorial you read was wrong.

NetOne

That’s what Ashley is making it sound like. In theory that makes sense, too. The alternative would be a ridiculous waste of resources.

So it dosent matter how many family members there are?

If by "family member" you mean "object type added to the family", then no. Families work in terms of instances, not object type members.