Performance Questions

From the Asset Store
[ C3 ] Firebase-Performance support C3 build service iOS | Android.
  • Hello there!

    I have some questions about performance.

    1) Am I right that it will result in a better performance if I let the player object check if it is colliding with one of the hundreds of trees in my game instead of letting hundreds of trees check if they collide with the player object?

    2) For the tree falling animation I use the spin behavior and check if the tree is 1° to 90°, if so change it to a laying tree object so it will stop spinning. Am I right that it will have a better performance if I swap this tree to another unique tree object before the spinning part so that the eventing will only need to check trees that are actually falling instead of also checking all the hundreds of other trees degrees that are not currently effected from chopping? Or is it more demanding to destroy an object and let another spawn on its position?

    3) I use player to tree collision checking to make the tree 50% opaque if the player is behind. For setting the tree back to 100% opacity I use "on every 0.2 seconds -> tree set opacity 100%". But this affects every tree. Is there a more elegant way to achieve this?

    4) If I set an object to anothers child, it has better performance if I unselect as many of the "child-syncing" options as I can, right? Or do these only really take up performance if their parents are moving or changing their angles?

    Thank you in advance!

  • 1 narrow it down with like "is onscreen"

    2- swap it out

    3- Yes eleanorjmorel.itch.io/test-sp-newstuff (drag and drop)

    4- Test it yourself instead of taking my word for it

  • Hello there!

    I have some questions about performance.

    1) Am I right that it will result in a better performance if I let the player object check if it is colliding with one of the hundreds of trees in my game instead of letting hundreds of trees check if they collide with the player object?

    There is no difference, the number of collision checks (which you can see and test yourself in debug preview mode) remains the same. As mentioned above, optimize performance by using other conditions to narrow down the number of objects that need checking, by using within distance or is on screen or something similar.

    2) For the tree falling animation I use the spin behavior and check if the tree is 1° to 90°, if so change it to a laying tree object so it will stop spinning. Am I right that it will have a better performance if I swap this tree to another unique tree object before the spinning part so that the eventing will only need to check trees that are actually falling instead of also checking all the hundreds of other trees degrees that are not currently effected from chopping? Or is it more demanding to destroy an object and let another spawn on its position?

    I would use an instance variable to keep track of the state of the tree (0 for stationary, 1 for falling ect.).

    3) I use player to tree collision checking to make the tree 50% opaque if the player is behind. For setting the tree back to 100% opacity I use "on every 0.2 seconds -> tree set opacity 100%". But this affects every tree. Is there a more elegant way to achieve this?

    Use an "Else" event after an is overlapping event to set oacity to 100.

    4) If I set an object to anothers child, it has better performance if I unselect as many of the "child-syncing" options as I can, right? Or do these only really take up performance if their parents are moving or changing their angles?

    Not familiar with this, but the golden rule is that if you can't measure a difference yourself, its not worth worrying about!

    Thank you in advance!

  • There is no difference, the number of collision checks (which you can see and test yourself in debug preview mode) remains the same. As mentioned above, optimize performance by using other conditions to narrow down the number of objects that need checking, by using within distance or is on screen or something similar.

    That was the case in Game Maker. Because the engine would focus on one object to check its collision instead of check all hundreds of objects and their possible collisions. It was recommended to check the collisions of the objects with fewer counts. And if I narrow the objects down with distance or is-on-screen wouldn't that also need the engine to check each objects x and y etc.?

    I would use an instance variable to keep track of the state of the tree (0 for stationary, 1 for falling ect.).

    I did not do that because I assume that the engine would need to check each of the trees instance variables first.

    Use an "Else" event after an is overlapping event to set oacity to 100.

    Wouldn't this set all the trees opacity to 100 every tick? That could cost a massive amount of performance.

    Not familiar with this, but the golden rule is that if you can't measure a difference yourself, its not worth worrying about!

    For now I do not have enough of the gameplay ready for testing the childs performance loss. So I wanted to ask before.

    Thank you for the reply.

  • As the blog oosyrag linked to mentions, there is one golden rule in performance: use measurements. If you can't measure a performance problem, you don't have a performance problem. Trying to fix a non-existent performance problem will simply waste your time that you could be better spending making your game.

    One thing I will add though: Construct's collision cells system means collisions already automatically only check nearby objects, which massively reduces the performance impact of collision checks with lots of objects. So you probably don't need to worry about that either.

  • Thank you Ashley and oosyrag for the clarification.

    For now I do not have all of the demanding systems implemented like real time shadows, cone of view limitation, fog and so on. I had these questions beforehand so that I can learn how I use the eventing system efficiently so that I will not need to rewrite later.

    But I see, the code/eventing part is rarely the limiting part.

    Construct's collision cells system means collisions already automatically only check nearby objects

    That is extremely good to know. Makes me worry a lot less about that forest! :D

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I had these questions beforehand so that I can learn how I use the eventing system efficiently so that I will not need to rewrite later.

    Even experienced engineers find it difficult to predict where performance bottlenecks will be. It's best just to get on with designing your game, and if you have measurements indicating a performance problem, use those measurements to investigate and improve it.

  • Okay I will do exactly that. Thank you. :)

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)