I’m trying to find some solutions to have cheap movement of different vehicle types. The one I’m specifically thinking about is my flying units. I intend to have perhaps up to 1,000 of these in a scene. I’ve been trying to find the optimum way to have these move without affecting the processor too much.
Ideally with flying units you’d use the physics engine, but having even 100+ units flying causes havoc in the profiler, and the fps rate (dropping to 15fps on my overclocked beast). An alternative could be to cut down on physics engine use, by setting useGravity = false, and simulate that part myself, but that seems to use way too much as well. The last alternative could be to create my own physics engine. My main concern is I’d need to recognise collision and height from the ground. With it being kinematic and needing to know how far from the ground to be, it’d need to rely on raycasts, which again are expensive. Especially on movement, where raycasts may have to be performed often.
What sort of game are you making? Having a thousand flying units in an RTS game is a different proposition from having a thousand flying enemies in a FPS.
With a thousand units in play, you are going to have to fake something. But what depends on exactly what you need these units to do.
It’s faster to call methods to fixed update than it’s for objects to receive fixed update messages. You could make a single script to your code that receives FixedUpdate and runs CustomFixedUpdate on all your vehicles reducing the number of objects receiving messages such as FixedUpdate and Update.
Secondly you could reduce the amount of fixed updates from the Unity Timer Manager by increasing the fixed time step value.
Also make sure you’re not using GameObject.Find, GameObject.FindObjectOfType, GameObject.GetComponent or FindGameObjectWithTag (or anything like those) from your Update and Fixed Update portion of code. Also creating new instances with New in Update can quickly overload the GC with unused objects which is common cause for performance issues. Lastly if you’re updating animator from your update or fixedupdate you should hash the animator property strings with Animator.StringToHash and use that instead of a string.
It’s also good idea to try to avoid doing raycasts or complex linq / other queries in your update or fixed update on every update.
If this doesn’t help, what does Unity Profiler show you?
All valid and good comments. But I think the problem needs to be defined better first. No point optimizing the living daylights out of individual GameObjects if the solution is to use a particle system. No point fixing FixedUpdate if the solution is to turn of physics. And so on.