In my game the player shots bullets that have a trail. This trails are done with sprites and they batch nicely. My bullets are pooled (pre created) and the trails are too. I mean nothing is created when playing (No GameObject.CreateIntance). As everything is pre created, at first I disable them with gameObject.active property and when they are required they come back to live setting active to true. I have noticed some slowdowns when shooting my bullets so, a question comes to mind, Is this a good way of doing things? Is gameObject.active an slow operation?.
Well, the only thing I can think of, is sending everything off screen far, far away, and bring them into place when needed. This solution comes with a big problem too, bullets have a fixedupdate funcion to check collisions (I do my own collisions in 2D) and it will be called no matter the bullet is been used or not. Instantiation is not an option here, because trails would be around 5 sprites, So for every bullet there will be 6 created bullet gameobjects in a row will all its components.
Have to try it, but I think I recall monodevelop throwing an error about being a deprecated member and suggesting to use just GameObject.active. I could be wrong anyway.
By the way Jessy I guess it won’t be a good option getting all components in the bullet gameobject and enabling/disabling it as needed. I have no real data but I think it will be slower than just calling active=false on the gameObject, that I’m pretty sure internally does the disabling of monos.
One important thing here is that I’m not using any physics. I undestrand ativating or deactivating gameObjects can invalidate Scene manager volumes for collisions but I’m not even using unity colliders, just a 2D version of my own.
In profiler I have found high peaks in cpu-player, that I think are produced by the bullets thing. Anyway have to dig a little more.
I’m finding pretty hard to make things smooth using unity for a simple 2D game.
I think you’re remembering trying to call component.active. .enabled turns off the FixedUpdate loop. But if you’re not using physics, don’t use FixedUpdate, anyway.
For me this is like try to kill a fly with a cannon, unity3d is a 3d engine perfect for 3d games, too excesive for 2d at least for me, even if other devs out there used to make good games.
This is like use photoshop to resize a photo, when there are tons of programs for that thing without use the heavy photoshop.
Regarding to your questions I move the objects outside the screen and stop them with the classical enemy.disable = YES; enemy is a class to handle enemies not the gameobject
I think you’re wrong. I mean, yes, if you use built-in collision system, etc… it could be overkill for just a 2D game. But I have written my own one, and it is as fast as a 2D collision system can be. The problem here is the target you’re aiming and of course the way unity handles the creation of scene objects. It doesn’t matter if it is 2D or 3D.
It is true there are other frameworks/engines that could give you instant tools for 2D game dev out there, but this doesn’t mean unity is not capable of doing it. More, all the tools I have coded for the game won’t have been possible to code in just one week in other languages C++/ObjC, etc… well I think I will have to correct myself, I wouldn’t have been able to code them in such a little time.
I think the problem is that for some type of games if you’re aiming low end devices, the way unity handles some things is not suitable IMO.
About your answer, yes, I could do that but what about if you have more than one mono running in the bullet? You have to dissable all components an it will be slower for sure than a gameObject.active=false, where game object can internaly acces its componets.
Yep, I’m used to do logic in fixed time steps, anyway you caught me moving to Update :).