# Unity3D: collider performances on mobile iOS devices

I'm experimenting with Unity3D and colliders. Unfortunately I still don't have Unity Pro version and I can't use the profiler.

Consider the following situation:

• mobile devices (ios, iphone 3GS).
• an infinite runner game (consider something like agent dash or temple run). The player run along its path collecting bonuses and possibly hurting obstacles.
• the number of objects along player's path is very high.

The first simple approach is to use a rigidbody with a collider attached to the player (let's say it could be even a shere collider) and use a collider for each object in the scene (coins, obstacles, bonuses,...) .

AFAIK, using hundreds of colliders could have a serious impact on performances,specially on mobile devices, am I right?

So here's some questions:

• In the situation described above, is that feasible use collider to detect objects collectable by a player running along a path?
• Could be a better idea to store the location of the collectables objects inside some kind of data structure and completely avoid to use Unity collision detection?
• What's a reasonable average number of RigidBody/Sphere Collider that can be used in a single scene on a mobile device?

Does anyone has implemented something similar? Could you suggest me the right way to go?

• Only check collision whith that you see, nothing else. especialy in an "Infinite" level. you cant have an unlimited amount of collision chekcs every frame. you have to generate it from what you have on screen. and how you store that information is probably not so important as this will generate more of a cpu overhead rather than memory. – Tordin Jan 15 '13 at 10:34
• @Tordin: could you clarify a little bit? – Heisenbug Jan 15 '13 at 10:42
• For the tempel runner idea, You only have to check collision ten feet ahead, or even less. And not even more than one feet behind the character. and you can even free the collision when it´s one feet behind the character, since you are never going back there again, ever. So you can then use thos to create new collision objects from the geometry in your game. – Tordin Jan 15 '13 at 10:50
• @Tordin: the data struct I use for eventually sort the object have impact on the CPU too, since I have to iterate over it. I don't think I can create colliders at runtime, because it will affect the collider tree structure causing performance issues, am I wrong? – Heisenbug Jan 15 '13 at 10:52
• Not necessarily, you could have a pool of say, 100 collision objcets, that you just reuse over and over again. Same thing with your objects, when they are out of screen, you just "move them" to the top of the level. And i am not sure how unity solves it collision and how the performance impacts are with unity. – Tordin Jan 15 '13 at 10:55

Before I answer this question here's a quick idea of how I would go about implementing an infinite or endless runner.

I have worked on a couple of endless runners and they have both worked in the same way. This isn't necessarily the only way to do it but it is a way that has been proven to work.

You can create generic sections of a level that contain geometry (such as the ground, maybe some buildings and so on). These sections will also contain a spline (path) fragment. In Unity these would probably be saved out as prefabs and placed in Asset Bundles or under the Resources directory.

At runtime you would then create a number of these sections and stitch them together. (Some pieces might not fit with each other so you will need some way of recording which pieces can fit with whichother pieces - this would be some sort of offline process in the editor). Once your character has cleared a section that section will be destroyed and a new one will be created at the end of the currently loaded sections.

In the situation described above, is that feasible use collider to detect objects collectable by a player running along a path?

It would be perfectly feasible to do this yes, provided the number of objects is not stupidly high. If you have followed the previous setup then objects the player can interact with can be placed randomly in each of the sections that gets generated on the fly. Usually these sections would have some predefined areas marked up for where to spawn these objects so they do not get spawned in silly places. As there are only going to be a few sections loaded at any one time and only I would imagine 10s of object at the most in each section this should perform just fine and in fact this approach has been used on a couple of games I have worked on for mobile devices.

Could be a better idea to store the location of the collectables objects inside some kind of data structure and completely avoid to use Unity collision detection?

You certainly could do this. You could store a data structure containing a position and a radius for the circle/sphere collision or some other appropriate data if you wanted to use another kind of collider. My guess though would be that its not really going to perform any quicker than the Unity collision system. So long as you don't have a silly number of objects and you know that it's not causing you any bottlenecks I'd stick with that.

What's a reasonable average number of RigidBody/Sphere Collider that can be used in a single scene on a mobile device?

Well this number is going to change wildly depending on which platform you are talking about and how much other stuff you have going on in your game. In an empty scene on a low end device you could probably chuck in a few hundred colliders and keep a nice framerate.

On iOS iPhone4 is the lowest device most developers target these days and that device is pretty poor. At the studio I work we haven't targeted the iPhone 3GS at all in any project over the last 2 years or so so I cna't comment on that particular device but needless to say its capabilities will be less than the iPhone4.

I would suggest that your bigger problem would be rendering the geometry for all of these items the player can interact with. But under a 'normal' level I guess you could probably have a good 30 odd colliders. This is a bit of a guesstimate based on working with the platforms before so don't read too much into these numbers. It will depend very much on how much stuff your game is rendering to screen and how complex your game logic is.

On Android you're going to have to deal with devices that perform even worse than that though and Windows Phone also has some really low end devices so its hard to give an exact number with so many unknown variables.