In my top-down game, I have several enemies which turn around when in collision with various objects (colliders, other solid objects, etc). In a YouTube video I was recently watching, the developer mentioned that having too many collision detection checks is hard on the game engine (all of them, not just GDevelop) and might have a negative impact on game performance.
Since I have several conditions checking for collision and separating these kinds of enemies from solid objects that they ‘bounce’ off of, I was wondering if this could have a negative effect on game performance as I add more enemies with the same events. See the code screenshot below:
For this enemy, I’m checking collision with certain “solid” objects that it is to be separated from (not able to pass through). However, the way I’ve done it is to make several collision checks inside an ‘Or’ statement. I’m starting to think this might be hard on the engine and affect game performance later on. What is a good way to optimize these collision checks without affecting game performance? Looking at the code, do you have any advice you can offer, or if these kind of checks being present for each similar enemy in the game could be bad for performance? I’m looking for any information you guys can give me here, and it’s greatly appreciated! Thanks!
Checking for collisions can be a bit taxing(especially on a lot, like 500+, as i know from experience not to do that). One altenative is to check to see if the distance is below a certain value. Hoever, a hundred collisopn checks at once wont be too much, but it will slow it down a bit.
To make sure I understand what you’re saying, should I use an event to check (in the code example above, first line in the ‘Or’ statement) the BlueOctorok’s distance from SolidColliders (let’s say we make the condition that the distance is below 5 px), then as a sub event to that, have the collision check/separate action? Then repeat this for each of the other solids you want to check collision with?
Would it? According to the source files the collision test checks the distance first. It seems like checking the distance seperatly first would cause the distance to be checked twice. Although, since the distance check would only pick the ones within a certain distance then only the closer objects would actually have their distance or collision checked a 2nd time. So, it would mostly cancel out any extra checks except for a few.
I think you would need a lot of objects for the collision condition to be an issue.
I’ve read that since the seperate object checks for collisions first that it doesn’t need any conditions. Otherwise the collision is being checked twice. Although again, it would only be the objects that were picked with the conditions that would be checked twice.
Example with 10 objects
Distance check picks 5 out of 10 objects
Collision check picks 2 out of 5 objects
Seperate objects checks the collision again for 2 objects and seperates them
Or
No condition with Seperate objects checks the collision for all 10 objects and splits the colliding objects
One last tip. If you put all of the obstacles in a group then you can seperate them using the group name as in seperate player from obstacles only player moves.
Thank you for all of this info. Reading the documentation, I wish some of this would have been in there.
I plan to eventually add all those objects to a group once I continue to add more objects to the game. I just have to be careful and plan it out well since there are certain enemies which are flying enemies and will therefore be able to “fly over” the objects with which ground enemies will be separated from…that kind of thing.
Question about your suggestion for the Separate objects action with no condition. If there is no condition, wouldn’t the check be running on every frame and therefore affecting performance? That’s why I had the collision check conditions in the code example I posted…because I thought the Separate action should only be applied when a collision is detected. Can you elaborate on this? Thank you!
The separate objects does its own collision test before separating objects. Doing a collision test first would cause the matching object to be checked twice.
It’s normally good practice to use a condition(s) to narrow the pick list before a more complex condition or action but in this case the collision and separate objects do basically the same thing. So, it’s more efficient to just do the separate objects actions.
