Listening for collision responses outside of the two colliders

Questions
#1

Is it possible to accomplish this? I’m trying to lower the active-script count so that I can control many game-objects under a single script instead of many game objects having their own script. A problem I am facing though is trying to handle collision logic in a controller-like system but I can’t seem to find any way to “listen” for collisions other than attaching a script module to a game object.

In the meantime, are there any writings I may have missed on practical ways to lower script count?

#2

No, the physics engine sends one message to each participant in a collision. That’s currently not possible to change.

When you say lower script count, are you talking about instances or files?

#3

What I was attempting to accomplish was optimally maintain the number of active scripts at a minimum to prevent the script limit from being reached.

In this case, I’m referring to instances with script components attached.

#4

One thing I’ve found is that it’s often not necessary to have scripts on both of the colliding objects. Example:

  • A player game object and many bullet game objects.
  • The bullets are spawned with a collision component and a sprite and then animated using go.animate() when spawned. No script on the bullets.
  • The player on the other hand has a collision component and a script to detect collisions. When the player script detects a collision with a bullet it deals with all of the logic, ie applying damage and removing the bullet.

A worse approach would be to have a script on each bullet and let the bullet start its animation and then delete itself when it collides.

Now, it all really depends on the kind of game you’re creating. Maybe you need to have scripts on every game objects that has a collision component, but I doubt it.

2 Likes
#5

Thanks for the replies guys!
I was actually using my projectiles under go.animate, and hence that is why I was looking for a way to handle collisions under one controller instead of the projectiles itself. I was thinking the only way around this would probably be just handling all of the collision in other objects, but then that will mean I have a whole bunch of ai objects which I could/should probably try controlling under one script as well.

Is there maybe a way to separate collision objects into a collision controller game object and individually update the positions on the collisions of that component? I can’t seem to find a way to manipulate a collision object directly.

My other idea, which doesn’t sound great, would have the controller have it’s own collision shape, and jump to each position it’s checking at. But I don’t think this is very reasonable, and I don’t think the jumping would be even noticed by the physics loop.

#6

You need to ask yourself if your current solution is a problem? Are you experiencing performance issues? If not then maybe you’re optimising something that there’s no need to optimise? Scripts by themselves aren’t expensive, it all boils down to the code in the scripts. Remove any lifecycle function that isn’t used (particularly update). Collision handling is perfectly according to the Defold philosophy of letting the engine do the work and react on engine events in Lua.

#7

I’m too stuck on thinking about there being a cap and making sure I never have to worry about it instead of focusing on actual problems. You’re right! I do envision a game with a ton of enemies at some point though, possibly 500-1000+. I’ll have to see in the future I guess