So I am working on a arcade game in Unity, one of the problems I am having is that there is just too many projectiles and it is dropping the frame rate.

Because it is an arcade style game where players can dodge projectiles, I need slow moving projectiles that can detect collision on it's own. The problem is that there are hundreds of these just flying around.

Normally I would just result to ray tracing but it won't work here because projectiles are slow and not instant. I already have a limit for projectiles each ship can have, that isn't working.

I feel like I am missing something obvious here.

I'm not familiar with unity but surely there is some quadtree tool? Usually the trick is to subdivide your collision detection into many smaller area. I'm not super knowledgeable in the subject but this is usually pretty straightforward to implement. 

Are your projectiles 3D or 2D images? And how many projectiles are we talking here?

1 hour ago, FFA702 said:

I'm not familiar with unity but surely there is some quadtree tool?

Unity already optimizes collisions, to the point where they don't even allow cylinder collisions. I don't think the collisions is really the problem, it looks more to be the objects.

1 hour ago, Awoken said:

Are your projectiles 3D or 2D images? And how many projectiles are we talking here?

3D objects. Around 150 projectiles on average on screen at a time. Say 1500 at max.  Yes I know that 150 shouldn't be dropping my frame rate but it is. I will do some test with sprites and see if it improves.

Maybe use the particles for this? I don't even know if Unity particles can detect if they hit a collision box.

Things that make projectiles slow:

1.  Having them on a layer that intersects itself, they should be on their own layer that doesn't self intersect.  If player bullets can intersect enemy bullets, then use two layers -- but they should still not self intersect.

2.  Have them using a expensive collision primitive.  Use a sphere or a circle.

3.  Using an expensive to render mesh / sprite

4.  Not using object pools, and instantiating a new projectile every time one is fired.

Those are the usual gotchas.  Failing those, I'd profile it and see.  The built in unity profiler is easy to use.

edit:  One last one, if you have increased your physics rate, or messed with solver iterations

Profiling is important.  Not knowing anything about your project, it could be the way you are using your code, it could be the relatively high number of objects in the scenes.  It could also be the code itself, such as inadvertently relying on reflection or relying on other relatively slow operations. It could be related to the things you are drawing, for example, maybe an artist used blendshapes to make models that could deform or be easily animated, not realizing the cost of rendering and processing; a few isn't an issue, hundreds or thousands will bring machines to their knees. High density model, a high number of draw calls, and many more things besides can all slow down the system.

Profile first. Find the hostpots. Then profile after and ensure the hotspots are gone.

11 hours ago, ferrous said:

Things that make projectiles slow:

Thanks for this it provided me with good focus points. Time is a scarce resource.

9 hours ago, frob said:

Profiling is important. 

Yes, I fully agree. In the end it is the most effective way of finding problems.

11 hours ago, ferrous said:

3.  Using an expensive to render mesh / sprite

So after some profiling I learned Unity batched the first few projectiles to save performance, then around the 40th projectile it just stop batching them. With sprites this didn't happen; it batched all of them.

After digging around in the manual and online I discovered that Unity's animated batching works best on meshes with +/- 200 vertices. I was using the Unity sphere primitive as the code is still in early testing. Changing the sphere to a cube proved that indeed the projectiles was too high poly.

Because the game is mostly from a top down view I can make only the top half of a projectile and projectiles won't need that many vertices. 200 would be more than enough. I will maybe even use sprites, for the projectiles that will have huge numbers.

At the moment I am even considering particle collisions, because it looks like this is a possible option, but I don't know if I will have the time to learn it.

yeah, that is a common thing, the sphere is relatively expensive to render of the default primitives.  there is a lo poly primitive asset pack, or you can make your own.

Adding to previous post that you also should consider pooling.

2 hours ago, Peter Karam Talaat said:

you also should consider pooling.

I am already object pooling some objects but the problem with projectiles for me is that there is too many of them.

For now the average is around 150 projectiles, but if I pool all of them then it will mean that there will always be +/- 1500 projectiles with most just inactive. I will need to do some tests to see if this is really any better.