[Suggestion] Same-same collisions with var checks

Discussion and feedback on Construct 2

Post » Fri May 10, 2013 4:00 pm

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.



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. ThanksChrisAlgoo2013-05-10 16:00:53
B
17
S
4
G
4
Posts: 143
Reputation: 4,004

Post » Fri May 10, 2013 5:04 pm

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...
As long as I can move left, right and fire, I'm Happy...
B
42
S
15
G
11
Posts: 655
Reputation: 12,260

Post » Fri May 10, 2013 5:16 pm

@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.

https://www.scirra.com/tutorials/361/understanding-uid-iid-health-cards-and-rocket-smoke-trail
ImageImageImageImageImageImage
B
93
S
19
G
12
Posts: 1,209
Reputation: 18,357

Post » Fri May 10, 2013 5:50 pm

@ChrisAlgoo - the workaround in your post looks perfectly reasonable.
Scirra Founder
B
359
S
214
G
72
Posts: 22,951
Reputation: 178,578

Post » Fri May 10, 2013 8:38 pm

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.

I hope this helps everybody.
B
30
S
6
G
8
Posts: 232
Reputation: 6,119

Post » Fri May 10, 2013 8:53 pm

I normally use the family trick:


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.
Scirra Employee
B
129
S
45
G
15
Posts: 705
Reputation: 15,413

Post » Fri May 10, 2013 9:34 pm

@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.cacotigon2013-05-10 21:42:02
B
30
S
6
G
8
Posts: 232
Reputation: 6,119

Post » Fri May 10, 2013 11:31 pm

@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.Animmaniac2013-05-11 00:39:52
Scirra Employee
B
129
S
45
G
15
Posts: 705
Reputation: 15,413

Post » Sat May 11, 2013 12:15 am

@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.

cacotigon2013-05-11 00:16:48
B
30
S
6
G
8
Posts: 232
Reputation: 6,119

Post » Sat May 11, 2013 12:32 am

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.Animmaniac2013-05-11 00:45:05
Scirra Employee
B
129
S
45
G
15
Posts: 705
Reputation: 15,413

Next

Return to Construct 2 General

Who is online

Users browsing this forum: Televangelist, TRMG and 5 guests