[Suggestion] Same-same collisions with var checks

Sorry for the less than descriptive title, I ran into the character limit. Anyway, it's currently very inelegant if you want to do variable checks where two instances of the same type collide. A game that uses this mechanic is Osmos, where every object is essentially the same. When they collide, the smaller object is absorbed by the larger.

Below is code that someone provided for me when I asked how to do this.

<img src="https://dl.dropboxusercontent.com/u/12667027/Construct%202/IdenticalObjectCollision/MonstersExample.png" border="0">

You can also check out the comments in the thread that spawned this suggestion - the posters make a number of good points about how this is an issue that needs to be worked around.

Link to topic

I'm not sure what the solution is (maybe allowing us to pick instances in our Conditions?), but I hope there is one. Thanks

I don't really see a problem here, all objects are essentially the same, just graphical blobs with numbers attached, colliding or moving these blobs changes values of it, or other blobs...

C2 does the picking for you...

Seems very elegant to me... <img src="smileys/smiley1.gif" border="0" align="middle" />

ChrisAlgoo

Don't use this way...

Use FOR EACH.

Also, giving an instance variable for each individual monster can give you a powerful tool for events.

scirra.com/tutorials/361/understanding-uid-iid-health-cards-and-rocket-smoke-trail

ChrisAlgoo - the workaround in your post looks perfectly reasonable.

Hey guys,

I've decided that this question is fairly important and hits a lot important concepts that are crucial to understanding how Construct 2 works, so I've written a tutorial to help explain:

Understanding Picking with Respect to Families

The tutorial not only covers how to distinguish between identical objects within single events, but why it's important from a modular design standpoint.

Ashley, I'd love to get your feedback about it, particularly if I've made any mistakes in my explanations. <img src="smileys/smiley36.gif" border="0" align="middle">

I hope this helps everybody.

I normally use the family trick:

<img src="https://dl.dropboxusercontent.com/u/7871870/construct/family-trick-01.png" border="0" />

You just add the object to a family and check for collision between the object and the family. Then referencing the object will pick the first instance and referencing the family the other.

The only inelegant part is the cases where you need to create a family for this sole purpose, but I guess it's not a big deal.

Animmaniac

Couple things.

1. An overlap combined with trigger once is basically the same thing as an On collision.

2. You would have to duplicate that collision event for every monster type in MonsterFamily if you wanted something similar to happen for each one. Granted, you can simplify the action component through a common function but still.

3. To further elaborate on 2, ideally you want to consolidate collision checking into as few check events as possible to avoid unnecessary duplicate collision checking and keep things as performant as possible. Doing a Family check against Family allows us to reduce collision checking to a single event.

cacotigon

1. For most cases yes, but for this one specifically it has different picking behaviors. Take a look at this example:

Family Trick Example 01

2. Yes, if you need to check a whole family with different objects in it. I was just addressing ChrisAlgoo's doubts of how to check collision on two instances of the same type.

3. I think performance would be almost the same on both approaches. If you check separately every object type of a family against an entire family, or check an entire family against itself you would be performing the same amount of collision checks, just spreading the same computing job over more events.

I would say that if all objects behave the same when colliding with themselves the "family vs family" approach is more convenient. However if they behave differently, by doing "object vs family" you can spare a lot of collision checks if not all object types will be affected by the actions.

Animmaniac

I'm sorry but it would increase the number of unnecessary checks, let's break it down item by item. Maybe if collision checks between objects were cached, but as Ashley has confirmed in a previous thread of mine, they are not.

Let's say you have a family with three objects X, Y and Z, and one of each object in your layout.

Using your system of checking object to family collision, you would have three events:

X On Collision with Family: This would internally run two separate collision checks: X-Y and X-Z

Y On Collision with Family: This would internally run two separate collision checks: Y-X and Y-Z

Z On Collision with Family: This would internally run two separate collision checks: Z-X and Z-Y

Making for a total of 6 collisions

Not let's see what would happen if we used Family to Family collision:

Family On Collision with Family:

Checks X-Y, X-Z, Y-Z

X-Y is the same as Y-X

X-Z is the same as Z-X

Y-Z is the same as X-Y

So in your example, you perform 2x the number of collision checks. You can imagine that for 100s of objects in a game, this just wouldn't scale well.

Maybe you are right, but I'm not currently aware if C2 does this optimization of not checking already checked pairs in reverse order.

I used to believe it just did two nested loops checking every instance from Family1 Vs every instance of Family2, since the most usual cases of use doesn't involve checking the same instances.

In this case 'Family On Collision with Family' would check X-X, X-Y, X-Z, Y-X, Y-Y, Y-Z, Z-X, Z-Y, Z-Z.

I'm in doubt now about what really happens under the hood.

Animmaniac

As I understand it, the way the engine is setup it can't really do a single nested loop for all collisions internally, because the user can setup all kinds of different collision detection wherever they want (even between events/actions that could change the positions of objects) in their event sheets.

EDIT: Ignore this next paragraph, I'm clearly tired as this would very much *not* address the order problem that I just described, aka events which change positions of objects.

(In order to do something like that, it would have to "read-ahead" for all possible collision checking events, aggregate them, filter for the distinct checks and remove duplicates, run the collision detection against this unique set, and finally store this in some kind of temporary Game Loop Cycle CollisionMap which any Collision events would just internally map against.) -- Bla bla bla

EDIT: Resume reading here. :)

Out of curiosity, I just did a profiling test of the two approaches:

Object to Family

Family to Family

Family to Family is about ~1.5-2x times more performant.

Benchmarking Capx