efficient collisions...all on player or on each enemy?

P

pSouper

Guest
Hi all,

For game efficiency, is it best practice to code all the 'kill player' collisions on the player for each enemy OR on each enemy for the player?
*given there are more enemies on screen than players

e.g:
player > collision > enemy1
player > collision > enemy2
player > collision > enemy3

or

enemy1 > collision > player
enemy2 > collision > player
enemy3 > collision > player
 

Bingdom

Googledom
Parent the enemies into one main object.

Let the Player run the collision. That way, there's only one collision code been executed (although it's still iterating through all enemy instances, so probably a very tiny performance difference. Likely faster than calling the function multiple times).
 
P

pSouper

Guest
sounds great thanks.
although... i didn't add (and definitely should have) that there were multiple rooms, each with different enemies. Would GMS2 run collision checks for enemies that have no instances live? would that be a really quick test or similarly slow? would that change your recommendation (over calling the same 'kill_payer' script from each enemy instance?
 

kburkhart84

Firehammer Games
GM won't check for collisions on objects that aren't actually live so don't worry about the performance there.

I also parent things when possible. All the enemies that I can would be parented to a single object. For what the player does, I put the collision event there. Then, I ALSO make the collision event on the parent enemy object itself, at least if all enemies do something based on said collisions, such as losing health. Then, if any enemies have something special that they do upon collision, for example if I had a ninja enemy that warped somewhere, or any number of things that would depend on the game itself, I would put a collision event on that specific enemy object. That event would call the inherited event(event_inherited()) and then do whatever else it needs to do that is special.

If I'm doing a game that has weapons, I like to do the same things for those. All the projectiles the player can shoot would be parented to a single object, and then the enemy parent object could check collisions with just that parent object(parent on parent).

Another consideration...there is nothing wrong with having wildly different objects parented to the same object. Commonly, you can use variables to handle it all. For example, my player's weapon's projectiles could have different damage values. The parent object could set a default value in the create event. Then in the create event of all the other bullets, you would make a create event, use event_inherited() to make sure all the defaults are there(in case some don't change), and then set the variables as you need(for example, changing the damage value). Then, in the enemy parent event(that checks for collision with the parent projectile), you can use the damage variable to decide how much health the enemy would lose when it hits the bullet. And note that you can still use the parent on parent collision events for this.

Last mention, this applies to all objects, not just players/enemies. A common thing is to make a parent GUI button. The mouse events could make changes to colors, scaling, etc... for mouse_overs and clicks. You could put a couple variables to make differences between buttons. I would have one variable for the text to draw, and another for the script to run when the button is clicked. Then, you could use the "instance create" event to define those variables. Then the parent object's draw event would use that variable to draw text on the button, while the click event would the script in the variable too. This let's you have only a single object for the buttons, yet have them do all the different things. The only catch is that you wouldn't see the text drawn while designing the rooms because the text only draws at runtime.
 
P

pSouper

Guest
@kburkhart84, super massive thanks for this. it not just answers my Q but explains a working method very well. Thanks v.much for this.
I am sure this will help a fair few others too.
 
Top