koobas.hobune.stream
Instantiate vs caching GameObject in scene
Was just wondering when would be a worthy time to even use Instantiate?
I understand how it works and its convenient to bring about GameObjects into the scene like Prefabs, but couldn't one simply just either Instantiate it once at run time or simply have the object in your scene before it is ran.
Same with Destroy. They are said to be expensive with repetitive calls, so I figure just move your GameObject far away from the scene as possible and deactivate the component and only re-position and reactivate when needed.
Is there a "good" reason to prefer Instantiate/Destroy over the methods I have provided and possibly others?
Yes there is! You are correct if you know you are going to use something then by all means preload it. But sometime you need the extra overhead to not preload everything. You can also gain some memory back by unloading the object. Now for an example.
Say you have a game like a MMO with an inventory system for your weapons. I wouldn't want to instantiate/preload every weapon you could possible use at the load of the level. You would only load the weapon the player is currently carrying.
ah good point, but how about the case of an open world environment? I guess you could put item spawn points at given locations and if a player is near by, instantiate the desire object, assu$$anonymous$$g the spawn point has a reference to the desired object, but if there are many items this feels like it could get messy quick. Any thoughts?
Well it depends. If it's a problem you could do a Borderlands style and have treasure boxes and you don't know what you get until you open it. At that point it's a design decision.
Using instantiate/destroy reduces update calls on certain objects that you are not currently using. Say you have a gun that needs to shoot 100 bullets in your scene - you would not want all of those bullets to be constantly updating when you are not even shooting your gun. Besides, do you really want to have all those bullet prefab copies crowding up your Hierarchy in the editor?
Some objects may want to log how many frames they were active for or their change in time. Your objects start() method may want to get the current time/frame and begin from that time. If you create the object at the beginning of your scene, the start() method for it's component may run unless you are sure the component script was properly disabled before it was called.
You may also want some objects that have the same tag active at different times. For example, you have Objects A, B and C that share Tag "MyObject". You may want Objects A and B to be active, while Object C is disabled which you only moved out of the view for your scene. Ideally, you might want to call findObjectsByTag("MyObject") and get/set some variables in your attached component scripts. You would then have to loop through each object to check if it's component script is enabled or disabled, which may be very slow depending on the number of objects you found. You do not need to handle this if Object C does not exist because it was never instantiated or was already destroyed.
So to sum up, I would use instantiate/destroy if you don't want to constantly update or find those objects, which is useful when trying to speed up overall performance.
Additional tip: If you want to initialize objects/scripts before your game ever starts, you can use the Awake() function, which runs before the Start() function. This is described more in the following links from the scripting reference: http://docs.unity3d.com/Documentation/ScriptReference/MonoBehaviour.Start.html http://docs.unity3d.com/Documentation/ScriptReference/MonoBehaviour.Awake.html
This is a somewhat related problem. I've several thousand trees and bushes that need placed (procedurally, of course) when a game starts. Currently, timing checks indicate that 13 seconds of the 16 seconds that it takes to build a simple level are in the section that's Instantiating the tree/bush/mushroom game objects. Is there any way to create the pool in the editor mode so it's already available when game starts. Unless I misread Awake, it's still going to run at the time I click on my game to start. The pre-allocation isn't going to help in this case.
