I’ve just read http://unity3d.com/support/documentation/Manual/Instantiating%20Prefabs.html, which goes on at great length about how great Prefabs are and how they’re so much better than defining objects in code.
I don’t think I’m buying it. The sensible comparison is:
- Defining your object in the Unity editor, making a Prefab out of it, and instantiating it in your script with one line of code.
- Defining your project in a script function, and instantiating it with one line of code.
The key difference, as far as I can tell, is that in approach 1, creating or modifying your object requires a lot of poking around in the IDE, twisting open disclosure triangles, popping up menus, etc.; whereas with approach 2, you just type or edit some code. Another difference is that approach 2 is very svn (or other version-control) friendly, whereas approach 1 is not.
But I’m still new to Unity, and use it in odd ways that haven’t required me to face this particular task much. I suspect that as soon as I get beyond creating primitives (cubes, ovoids, etc.) and need a real 3D model, then I have to use a Prefab. If so, then that is a good reason to use them, even if all the arguments in the above document are not.
Can anyone confirm or deny that requirement? Or have other thoughts to share on Prefabs vs. defining objects in code?
using prefabs does not prevent you from modifying the objects in code once instantiated. the prefabs just give you a standard behavior (like a default constructor does). the values attached in code always overwrite the values from the ide (which can be annoying when you dont know what you change in code).
prefabs can be customized by non-coding members of a team also without having to crawl through code.
many time is spent with balancing and it is faster to adjust a variable in the editor and hit play for testing than searching the position in code, change it, compile your scripts and hit play.
so the prefabs offer some convenience but still allow you to do it the “programmer way”.
Thanks for your thoughts. Your point about non-coding members of the team tweaking the prefabs is an especially good one; I hadn’t thought of that.
Best,
If you can make it in code, you should make it in code. But…
What does your level designer do? hand-edit it all in code? add scripts to a light bulb prefab that flickers gently? how does he add an enemy complete with scripts and AI?
That is the power of prefabs. You can drag and drop complete “classes” of objects with connected code into the world, like doors, monsters, effects and so on. You simply can’t do that in code in any reasonable timeframe.
You use prefabs where they make sense, you don’t use them because they exist.
It also depends on what you will be adding to that procedurally-created gameobject or prefab -
in cases where you are building/re-building a mesh on the fly, then the script doing it is likely on something other than that object/prefab, etc, and a prefab may not make as much sense. Also, your code can easily add a lot of the necessary components on the fly, as you noted.
but as you develop complex behaviors in scripts that are intended to be attached to the other objects, it might be most convenient to attach those scripts to prefabs ahead of time, and instantiate the prefabs. Prefabs can in turn instantiate more prefabs, and so on.
so not only the custom modeling and animation might call for setting up a prefab, but attaching (multiple) script behaviors specific to that object ahead of time also builds up a set of assets ready to drop into the scene.