r155 Collision Cells

Discussion and feedback on Construct 2

Post » Mon Jan 06, 2014 1:31 am

After reading the beta post for r155 about Collision Cells it seems to me this would also make a very useful Picker Condition... for example if I have a very large level / layout as is described in that post I would also like to do AI logic less often the further away an NPC is from the player cell without doing a distance check on every single NPC in the layout... there are probably other such things where game devs could reduce work based on these cells.
B
21
S
5
Posts: 195
Reputation: 1,972

Post » Mon Jan 06, 2014 5:44 am

I like the cells. I wanted Quadtree, but this is still vastly better than brute force and imporantly the factor of implementation.

I would also like to determine the cell size. I have a game where the entire concept is LOTS of objects. being able to set the cell size would be very helpful as the game takes place on one screen.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,013

Post » Mon Jan 06, 2014 12:21 pm

I could possibly add a "pick objects in same cell" type condition so you can make similar kinds of efficiency gains in events as well. However it would only have an effect when it's the first condition - the blog post I made about the optimisation covers why.
Scirra Founder
B
387
S
230
G
88
Posts: 24,251
Reputation: 192,454

Post » Mon Jan 06, 2014 8:11 pm

It is rarely true that logic can only be coded one way. So if I know that I can get larger performance gains by architecting the events so that they start off with picking by cell then doing other picking down below then that is how I would do it.
B
21
S
5
Posts: 195
Reputation: 1,972

Post » Mon Jan 06, 2014 8:25 pm

Not to just keep piling on (however if it would require about the same amount of work on your side...)

It might be logical to want to know what objects are in your current cell plus all the cells adjacent ... so you can spin up their AI (or whatever) as the player is approaching.ggibson12014-01-06 20:25:43
B
21
S
5
Posts: 195
Reputation: 1,972

Post » Mon Jan 06, 2014 9:12 pm

"Is on screen" maybe, or would los behavior work?

A simple distance() behavior would be nice.
Image ImageImage
B
168
S
50
G
164
Posts: 8,236
Reputation: 105,591

Post » Mon Jan 06, 2014 11:00 pm

Onscreen would probably just limit to the already established cell collision. If not it would still brute force.

As for distance() i'm 90% that would still run on only brute force as distance isn't part of cell collision.

"It is rarely true that logic can only be coded one way"
True, but I suspect this is based on archetictual limits. Requireing some changes would probably require some fundamental low level changes which could have some serious repurcussions.

but I agree, being able to the cell object list and *cough* cell resize would be great :)
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,013

Post » Tue Jan 07, 2014 1:37 pm

@ashley, two questions about collision cells:

will the top level+first condition requirement for using the cells always be true?

also, in many cases I am filtering to one specific instance before doing a collision check (with another filtered single instance of another object).. am i right in thinking that in this case, there's no 'brute forcing' and as such, there is no advantage to trying to make them top level conditions in order to use the collision cells.keepee2014-01-07 13:39:01
B
28
S
8
G
1
Posts: 469
Reputation: 4,683

Post » Tue Jan 07, 2014 3:00 pm

@keepee - it will probably always be true, yes, because once another condition has filtered some instances you can't look in collision cells any more since the cells contain all instances.

You might still want to put collision checks at the top, even with other conditions. It depends on your project. If you have 1000 instances, a condition that filters down to a single instance still has to check the condition against all 1000 instances. The collision cells optimisation is unique in that it has the ability to only check the instances that happen to be in the same cell (assuming they're all fairly spread out), which could be a lot less, and then the next condition only needs to check those meeting the overlap condition. But the overlap condition could be more expensive if a lot of poly checks are being done.

Overall I'd advise it's probably best to still put collision/overlap conditions at the top. When you get to very large numbers of instances, they are actually a lot more efficient due to not even having to check many instances, which can save you having to run ordinary conditions on lots of instances too.
Scirra Founder
B
387
S
230
G
88
Posts: 24,251
Reputation: 192,454

Post » Wed Jan 08, 2014 1:19 am

So instead of doing a scan potentially across 1000 objects with the "Pick instance with UID" condition looking for a matching UID... you would only scan for a matching UID on the objects in that Cell.

B
21
S
5
Posts: 195
Reputation: 1,972

Next

Return to Construct 2 General

Who is online

Users browsing this forum: RoboticPhoenix and 5 guests