I need to know if a sprite is within range (circle or square doesn't matter) around the player. If the sprite is, let's say, 100 blocks away from the player, I will disable it. This wouldn't be too much of an issue, just compare positions and you're done. However, my game is a tile based game and I want the world to be as big as possible, which will result in millions of sprites.

I could also add a overlapcicle2D, but the problem is this these objects can't have a collider, since they could be walkable.

So how can I check if the millions of sprites are in range of the player, without lowering performance?

Alternatively, I could add occlusion culling. But how do you do this with sprites?


2 Answers 2


You may not need to include Occlusion Culling for a 2D game in Unity.

Unity has a thing called FrustumCulling that hides any object not in view of the camera. In a 3D game, this isn't always ideal because the frustum doesn't account for distance, meaning that the game would still do things like render rooms behind doors that you can't technically see. However, in a 2D game, you don't need to worry about that, because it's 2D, there's literally no distance to worry about. So, assuming that "100 blocks away from your player" actually means "Outside of the camera view", they're possibly already being culled anyway.

  • \$\begingroup\$ Okay, but when I want to make a game with millions of sprites, it will take a few hours to generate the world. How can I make it so it doesn't take that long? \$\endgroup\$
    – FlorisdG
    Commented Jul 10, 2016 at 12:27
  • \$\begingroup\$ Why do you think it will take a few hours, as opposed to a few seconds? Have you tried generating a map with millions of sprites? \$\endgroup\$ Commented Jul 11, 2016 at 8:56
  • \$\begingroup\$ @VellosFree That's not what your question asks and that's an entirely different problem altogether. (You need to look into procedural generation and you need to generate your tiles at runtime, then save the changes made to a file so that the game can load the same changes when it's next loaded) \$\endgroup\$ Commented Dec 26, 2016 at 8:01
  • \$\begingroup\$ Note that frustum culling will only save the sprite from being rendered - it will still run any scripts attached to it, whether it's in the frustum or not. You will have to disable the object manually if you want the scripts to not take up CPU time when the characters are not nearby. \$\endgroup\$
    – BMac
    Commented Sep 26, 2017 at 16:05

If you're simply trying to minimize resource impact, @DisturbedNeo is right on the money. If there are other reasons you'd like to do this, you could always use a VERY large collider and check for objects inside of it that meet a certain tag criteria.

  • \$\begingroup\$ The trouble with them using a collider or trigger zone on their player is that, for gameplay reasons, the sprites need to be "walkable", so they don't have colliders. Which means that they wouldn't trigger a large collider attached to the player. \$\endgroup\$ Commented Jul 11, 2016 at 8:53
  • \$\begingroup\$ If trigger colliders are used, I'm not sure why "walkability" would prevent it from working? \$\endgroup\$ Commented Jul 11, 2016 at 12:45
  • \$\begingroup\$ Hm, I don't think I know enough about Unity's 2D physics. I do know that two ordinary trigger zones don't "collide" with each other, though, so messages don't get sent. I believe that in order to achieve that, at least one of the two objects with triggers needs to have a Rigidbody. \$\endgroup\$ Commented Jul 11, 2016 at 13:06
  • \$\begingroup\$ Or a kinematic collider, I believe. It's worth looking into as it offloads a lot of the heavy lifting to existing routines. \$\endgroup\$ Commented Jul 11, 2016 at 13:06
  • \$\begingroup\$ A kinematic and a trigger collider that is. No rigid body involved. \$\endgroup\$ Commented Jul 11, 2016 at 13:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .