Optimization 101: Collision checks and Groups

5

Stats

8,144 visits, 11,431 views

Tools

License

This tutorial is licensed under CC BY 4.0. Please refer to the license text if you wish to reuse, share or remix the content contained within this tutorial.

Published on 27 May, 2016. Last updated 19 Feb, 2019

This tutorial covers several techniques to improving performance when you have when you have lots of objects such as enemies and bullets.

If you have hundreds of sprites such as enemies or bullets which reference various triggers (such as collision of bullets with enemies, and timers) you will notice performance will suffer even if collisions aren't happening. This is compounded exponentially if you are doing collision checks between two families! While Construct 2 does not check for collisions with objects that do not exist in a family, it will check to see if they and each opposing object exists per tick.

For example: If you have 50 enemies in one family and 20 bullets in the other and you're doing a collision check between them, it will be doing a "does it exist check" for each enemy times each bullet object type per tick which can turn into a massive inefficient use of cpu resources! 400 enemies X 50 checks X 20 bullets equals 400,000 checks even when the bullets aren't present and no collisions are even happening!

Two possible solutions which work together to avoid this is would be having a variable which tells the game which weapons could possibly exist and then check for each one individually and also disabling the group if it's not in use (i.e. no bullets present). For example, I have a weapon variable which if set to 1 will then only allow collision checks with that specific weapon to ever happen.

Now this will solve only part of the problem, what you still need to do is disable the group on start and only enable it on bullet creation. You then want to disable it again when the bullet count drops to 0 so that it doesn't use up resources all the time. (Note: All of my bullets are in the family called "weap")

When I made these changes I immediately noticed a 25% drop in cpu use, and even while the bullets are firing I only notice a small 3% increase. THIS IS HUGE! So I decided it was time I write a tutorial and let everyone know about this.

Taking this group disabling technique a little further; It's a good idea to disable groups for features that your enemies may not be currently using. If there are a lot of collision checks or even timers, You may want to disable those groups if the collision or timer in them isn't being used. Triggers still use up some resources just by existing and this compounds with the amount of objects you have currently in your layout.

For instance: I had a health bar that would appear above an enemy if you hovered the cross hair over it. This collision check would happen for every enemy in the collision cell which was using up 8% cpu. I decided the smallest enemy in the game just didn't really need a health bar since only a few bullets would destroy him anyway. I disabled the group if the larger enemies are not present thus gaining 8% cpu back!

Not shown above is the events which simply state: enemy on create=>if armor is set to "light" disable health bar group, If armor is set to heavy enable it

One final tip I would like to share is "every dt*2 seconds" technique. For things that happen regularly but don't need to be precise, you can reduce cpu usage by utilizing dt (which essentially means the time it takes to draw a frame) and multiplying this by 2. This will basically make the event conditions check every two frames thus cutting cpu usage in half.

In the above image I use this technique to redraw the width of a sprite representing the enemies health every other frame as to save cpu resources. The applications for this technique are far reaching, however, be careful when using it for things that require precision such as bullets.

It's sometimes best to just take the hit to cpu resources for important game play elements.

In conclusion: You can vastly improve performance by overcoming certain nuances in Construct 2's collision system by disabling and enabling groups only when you need them and avoiding doing collision checks between families of sprites. Remember to use only the cpu something needs by repeating a check less often with dt*2 or if it's really imprecise, every second. If your not using it, don't waste resources on it!

Best of luck to you all! This is my first tutorial, I felt compelled to share this information as I found these techniques extremely useful!

Austin Morgan (SunTanK)

variagames.com

  • 0 Comments

Want to leave a comment? Login or Register an account!