I heard over a million people use Unity? That's ... crazy. There's a million game developers in the world? 1 out of 5000 people is a game developer? I wonder how many people who play my games are also game developers. Maybe writing articles on game development is fairly user-facing after all. So here we go.
I taught a class at DigiPen earlier this year where I made the students use Unity to illustrate various game-tech concepts like shaders, physics, lighting, audio, etc. So I've now got a list of a few things they typically didn't do that you really should if you want to be productive / effective / cool with Unity. I'm still a Unity rookie (been using it for less than a year) but here's stuff I wish someone had told me (or my students) when we were starting out.
- Prefabs, prefabs, prefabs. It's very tempting to put some GameObjects in your scene, and then start duplicating them, and then you realize, "Hey, I want to make some changes to all of these." And if you had used prefabs, you'd be able to. So always use prefabs. It doesn't hurt to get into the habit of using prefabs even with one-offs. Hey, you might duplicate them, or use them in another scene, or what-have-you. For prefabbing a mesh, I've found it's good to parent the mesh to an empty GameObject and prefab that. You can't nest prefabs; you can't have prefabs within prefabs. It's not a super-huge deal, but if you expect a nested prefab to work you'll probably be confused. Something I learned the hard way.
If you've already duplicated a bunch of non prefabbed GameObjects in your scene, it's not too late. There's a useful script here that lets you select a bunch of objects and replace them. Replace all those duplicate GameObjects with a nice prefab.
(The L-shaped buildings are instances of prefabs. I've got a thing going on in the code that randomly shows and hides their roof decorations, that's why they don't look identical.)
- Debug. In my programming career, the habit that took me from being a not-so-effective to a very effective programmer was learning to step through code in the debugger as I wrote it. Don't wait for your code to clearly not work; make sure it's doing what you think it does as you write it. I do this less now, because C# is so much more reliable than C++, but I still do it about half the time. An in depth look at Unity debugging is here.
- Figure out and use the light mapping. The difference in quality between a light mapped scene and a not-light-mapped scene is huge. I'd rather have lightmaps than textures. (Okay, a lightmap is a texture, but you know what I mean.) The settings I've been using for Energy Hook include Shadow Samples: 1000, ambient occlusion 1, but only 5 texels per world unit. Takes hours to bake the city scene, but you can selectively bake if you want to see how the bits you just worked on look.
You don't need Pro to use the light mapping.
- Editor scripts are cool! There's something in me that makes me reluctant to write an editor script - it doesn't feel like real work somehow - but it can be a great time saver, as with any batch file or python script or what-have-you. I have scripts that randomly recolor entities and scripts that randomly adjust the heights of buildings, and I feel like I'm just getting started ... a random city generator wouldn't be out of the question.