Passing Values to other objects possible?

crestwoodgames

I have read around and looked, but can't seem to find much.

Is it possible to pass a value based on an action.

For example.

On my scene, I have 2 boxes. They are both spawned from the same prototype. I also have bouncing balls. If a ball hits a box, the health on the box is decreased by 1 and the ball bounces away and works fin. Usually you could just have a rule in the box:

If collide with ball, change health to health -1. In 99% of the case, this works fine.

The problem arises with multiple balls, anything over 10, being trapped between a box and a another object. The bounces happen very fast, and the box thinks it is always in contact with a ball and quits registering hits.

The only solution I could come up with is to either have many rules in the balls based on the box it hit, and feed the collision to a table subtracting the health of the box. But, this will put a lot of rules in each ball. There can be over 100 balls on the scene.

Not sure what to do.

Any suggestions?

Braydon_SFX

Are you decreasing the health value in the box actor or the ball actor? You're going to want to do it in the ball actor, since there are many of those instances on scene. If you choose to do it in the box, which I assume you are now, the box can only detect so many collisions at a time, and sometimes miscalculates.

crestwoodgames

It's the box that needs to decrease in health. I could do this with different boxes. But there are up to 28 on scene. This means the ball would have 28 rules just for collision.

Trying to figure an elegant way to collide with the boxes and store the box I'd value in the ball, then run a table rule to subtract the health. Not sure it is possible. Any way I try this, I end up having a ton of rules.

I have coded in other SDKS and upon collision you can store what you collide with. Not sure if box2d/ Lua can do this. Will read more on it.

Braydon_SFX

I'm confused. So there are multiple boxes and multiple balls?
You could store each box health in a table cell and reference that in your rules?

crestwoodgames

Lets say I have a scene with 5 boxes all spawned from the same prototype. They each have 10 health. There are 10 balls on scene bouncing around. If a ball hits a box, the box loses 1 health.

The problem is when multiple balls hit a box at the same time. It is then registered as 1 collision and the box only loses 1 health.

Hopscotch

@crestwoodgames, considering the amount of actors on the scene, and that you want the health of the boxes to be tracked, I would prevent having too many rules in the balls.

You are right that multiple collisions of the same actor will count as one. So, as a trade-off, you could spawn 4 different types of ball (but identical looking), then put the 4 separate collision rules in the boxed (since you have less boxes than balls).

This will not eliminate the possibility of duplicate collisions, but reduce the chance by 4.

Even increase this number if needed if performance is good.

crestwoodgames

@Hopscotch This might be a work around. Although, there are times when up to 100 balls can be on scene, but i could have 10 unique balls. Hopefully this could eliminate some of the double hits.

I will try this out and let you know how it goes

The_Gamesalad_Guru

I agree with @Hopscotch this is the best way. You would only have to add the new ball types to your rules.

crestwoodgames

Works 100x better! Out of 20 tests, I had 1 issue where the collisions stopped registering all together for a few seconds. I wonder if this was just a viewer issue and would probably not show up on the actual device.

The_Gamesalad_Guru

As we said you will get overlap of collisions but it will be less likely by adding ball types. Won't be 100% but better.

imjustmike

Is this really the best way? Feels really clunky to have to have loads of different actors with the exact same rules. Not saying that I can think of a better way, just that it's a shame that the engine can't detect collisions in this way. It'd be useful to know how many collisions from the same type of actor were happening, so you could just multiple the damage by that amount. i.e. 3 ball collisions at the same time = 3 health removed.

crestwoodgames

I know it could be possible to store the actor you collided with as a variable. GS requires you to have a rule per collision or tags. It would be nice to just detect any collision and store the object collided with as a variable. After that, you could determine what you want to do with it.

This way you could then easily reference a row in a table based on the collided actors name or number all with 1 rule.

Maybe a feature request in the future.

tatiang

I know it's just semantics at this point but a lot of this comes down to how you build and organize your project file. If you create a single actor, give it a collision rule tied to a table cell using attributes for the row/column, and then copy or spawn that actor a bunch of times, you've only created one rule. The fact that you have 4 balls or 40 doesn't really matter from a coding standpoint because it's the exact same amount of work from you.

It might seem more organized or efficient to detect collisions in one place (one actor) but it's still just one rule to edit assuming you spawn actors or copy actors within a scene (instances).

crestwoodgames

The issue I have is a bunch of bouncing balls, and a bunch of objects that need to detect each hit.

For example. I could have 30 bouncing balls spawned onto a scene. All from the same prototype. I also have 10 blocks on scene. Each block needs to register a hit any time a ball bounces on it.

I currently have to use 10 different prototype balls to make sure the blocks register a hit. This seems to work well, but could have been easier.

If I was able to store the collision, I could then simply have the ball register the hit, pass the hit to a table, and move on.

Same thing would work with a game that had a lot of different enemies and bullets. The bullet would detect the hit, store the collison object I'd in a variable, pass it to a table.

I know there are several different ways to do things. Just an observation that might help out performance even more.

tatiang

Why do you have to use ten prototypes? Is that because multiple (duplicate) actors colliding with a box only trigger a single collision?

The idea of a single actor that detects collisions for all other actors would still require ten prototypes unless the whole collision detection routine is rewritten by GameSalad, inc.

Not trying to be abrasive... just genuinely interested in thinking through what you're attempting to do. Sometimes I can offer a suggestion that simplifies things greatly and sometimes I learn something new (and sometimes I have no idea what I'm talking about ).

crestwoodgames

No problem at all. Good discussions.

Yes, I have the 10 prototypes to help with the collision detection.

As for not having a bunch of rules per collision. I could be wrong, but I thought with box2d when you collide with an object that is set up for collisions you could store the object id.

So let's say I have my ball flying around. I have 3 different actors on scene. Box1,Box2,Box3. As of now I have a rule in each box that states If collide with Ball, subtract health. This works fine. But if I have a lot of balls on scene and they hit the box at or close to the same time it registers as 1 hit as stated before. Creating 10 prototypes helps solve this issue, but now I have 10 rules in each box.

Or I could have 1 rule in the ball prototype. If collision occurs, store the object I'd of the Box I collided with. Then using the id as an index reference subtract health from cell value in a table.

Something like that maybe.

tatiang

Yes, I agree that those are the two options you have.

imjustmike

Without unlocking actors, is there a way to do this?

For example, if I'm building a castle defence game, I will have a castle with health. In that castle I'd have a rule that every time an enemy hits it, remove health. The issue is that if multiple enemies are touching the castle it only detects one. So, a simple solution is to use a global attribute for castle health and move the collision rule to the enemies themselves.

But if the game is more complex and I'm able to build walls in front of the castle to protect it, I'd having be multiple versions of the same actor that still need collision detection, this gets a little messier. Especially if the walls are actually spawned during the game - now global attributes are out - unless I have a huge amount of attributes left empty and somehow assign them during the game. Or I use tables. And have a global attribute wall_number that increases by one each time there is a new wall built so I can assign the wall health to a row. Then I'd have to have a rather long table set up with lots of empty rows ready to store, or build it so that when a wall was destroyed that id (and corresponding row) becomes available to use again.

Which all seems a little complicated. Maybe.

Hopscotch

@imjustmike said:
...it's a shame that the engine can't detect collisions in this way.

@imjustmike said:
Which all seems a little complicated. Maybe.

No matter what tool/language, in principle you would need to do the same.

GameSalad, in its way, has the same capabilities to realize what you want/need to do.

Tables are the equivalent of multi dimensional arrays in other tools or languages. It even offers some added functionality, like quickly searching for a value to find an empty row.

The_Gamesalad_Guru

Why do you have ten rules? Why didn't you just add the different overlaps and collide with the new actors to the original rules conditions? Just set it to any.

crestwoodgames

@Lost_Oasis_Games I guess I could do Any, I am not sure how the collisions will react. I will test and let you know how it works. Like I said before, I usually don't have any issues except when the bouncing balls get in tight areas. Its rare, but the user would notice it and it would not be optimal.

I will have my block with 10 collision statements and use the Any option and see how it goes.

But if I could store a collision as a variable, I would just need 1 rule and be done.

So for example, I could have a rule in my ball actor.

If Collision Detected
change self.attribute Collided to Collide.id (how ever you want to name it)
change table value @ the index of the self.Collided

Something like that. At that point I would then need to make several different block actors instead of just 1.

To me it is a trade off. You either have to have a bunch of rules in 1 actor detecting all the balls. This would be fine for a slower paced game with not a lot on scene. But if you have a fast paced game with a lot of actors on scene, the less rules in the actors the better.

The_Gamesalad_Guru

If you are using ten actors with ten names that is the same. The ID is the name of the actor. So you only need one rule.

Rule
Any

Overlaps and collide with actor a
Overlaps and collides with actor b
Et......

Change attribute health to health -1

Armelline

I haven't read this thread thoroughly as I'm annoyingly busy right now, but the simplest solution would surely be to just do this. I threw it together very quickly so it can probably be greatly improved.

Edit: Uploaded wrong version... correct one coming momentarily.

Armelline

Correct one.

Edit: No this was the wrong one too. You'll get the idea, though. Just a redundant attribute being used.

Armelline

Found it!

crestwoodgames

@Armelline This is optimal for 1 box. I have over 20 boxes with their own health. Each box is spawned from a prototype.

Armelline

@crestwoodgames said:
@Armelline This is optimal for 1 box. I have over 20 boxes with their own health. Each box is spawned from a prototype.

Same principle but using a table, each box assigned to a row.

Edit: Sorry, didn't properly read the question. That will be trickier.

crestwoodgames

Using the Any rule with all the balls listed works. I just think it would probably be better to just record 1 collision.

Thanks for looking into this. It's always fun to try and figure out different ways to do things.

Armelline

@crestwoodgames said:
Using the Any rule with all the balls listed works. I just think it would probably be better to just record 1 collision.

Thanks for looking into this. It's always fun to try and figure out different ways to do things.

No thanks needed, I did this a bit ago. I needed to solve a similar problem and had downloaded your game earlier that day so I did my testing using bouncing balls (rather than protruding spikes which was my ultimate aim). Just unfortunate it couldn't be more helpful!

crestwoodgames

I only posed this question because in Box2d when a collision occurs, set & getUserData is information that can be changed or used. Not sure how this could be implemented into GS though.

The_Gamesalad_Guru

I think the issue is with box2d and gamesalad having that level of collision detection seems to slow the frame rate way down. 1.25 will have a more efficient collision detection but they said using that option, which one can check on or off, will come at the expense of processor usage.