How to Reduce CPU & Collision Checks with Large # of Objects

0 favourites
  • 6 posts
From the Asset Store
Welcome! I-Spy (Hidden objects) is an educational puzzle that is more than just seek-and-find activities.
  • Hello!

    I'm working on a rather large-scale shoot-'em-up which will have an increase in enemies (and other related objects) that grows exponentially. I'm noticing in the debug that my CPU is topping out at around 95% (more or less) and dropping to 12 fps. Even after adding some checks that disable collision checking on non-essential objects, I'm still seeing upwards of 50,000 collision checks per tick with only 2500 objects.

    I was hoping I could get some tips on how to better manage (and lower) collision checks and speed up the game even when there is a lot of activity going on.

    If it helps, here is the .c3p file to review:

    Some things to note about what I have so far:

    - One enemy type generates up to 144 small sprites that fade away after a few seconds and destroys.

    - All enemy types can "replicate" themselves, which is how there will be so many very quickly.

    - A second enemy type will use another object to navigate a path it should take. This object that accompanies the enemy type uses pathfinding behavior. At present, I have not instructed the pathfinding to do anything, but it is enabled.

    - The layout is 8100 x 8100.

    - I'm using mostly sprites that range from 30 x 30 to 900 x 900 (and other variances of sizes along these values).

    - I have mostly 9patch objects for wall obstacles.

    - Movement behaviors are mostly limited to 8Direction, TileMovement, and Bullet. The aforementioned object that uses Pathfinding will be used in as limited a capacity as possible.

    Any thoughts or suggestions I could work on to reduce the CPU demand with so many objects and lower the collision checks even with a growing number of enemies?

  • It's difficult to help after the fact. Ideally regular performance testing would identify the particular change that caused a slowdown. It also does not appear conclusive from what you've said that collision checks are the cause of the slowdown. It's possible they're perfectly fast and something else has slowed it down. The only way you can really narrow this down is by trial and error - turn things off and see if it stays fast, and aim to find the one thing that slows things down. Then you can either optimise that, or if you think that Construct is handling it inefficiently, isolate it in a minimal project for further investigation.

  • A task, in of itself, for sure.

    I understand the difficulty in trying to help me isolate the issue but I'll see what I can do from what I've learned. Thank you, as always! :)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Ashley - Perhaps this will help me further understand the inner-workings of C3 so I can better manage how I set this game up...

    What are the - oh, let's say - five most CPU-demanding features of C3? Such as the use of Families, For Each, Picking, etc.

    There was a post by one Eleanor who was quite vocal about their opinion on what aspects of Construct worked faster (eg: Picking an object specifically by UID versus Pick All). So, I'm wondering if, however remote, this could help me refine my approach to large scale numbers of objects all running on one very large layout.

    It has been my understanding, further, that For Each literally runs through each instance of an object during that tick it is called on. Naturally, with hundreds, or even thousands, of objects, whether by Family (or perhaps more so because of Families), that's going to demand more CPU. But then again, generally speaking, For Each might not be so demanding. ... That's just an example of my weak understanding of things "under the hood" of this engine.

    I would estimate that this list, if you can provide me with such, won't always be objectively that way - it may shift depending on how the event sheets are set up and other factors. So, I'd expect such a list may be "on average".

    (I'll post this in the Discord channel, too, just in case you're not able to get back to me right away. I know you're quite busy and I always am grateful for your responses.)

  • What are the - oh, let's say - five most CPU-demanding features of C3?

    It's impossible to answer that question because it depends entirely on what your project does.

    For example 'For each' will be fast if it runs through 5 instances, and slow if it runs through 100,000 instances.

    Ordinary conditions already check every instance to pick the ones that meet the condition. So 'For each' with 5 instances could easily be faster than a simple standard 'Is visible' condition that has to check 100,000 instances.

    Some important points about performance are already documented in the Performance Tips manual entry, but those tend to be things beginners do because they don't understand how much work things take. The key is regular testing to catch anything particularly slow that was accidentally introduced, and guiding your changes solely by actual measurements.

  • That makes sense. Thank you, sir. I'll try to keep that all in mind. Hopefully I'll figure out something creative to manage the higher number of instances.

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