This is a great article with great ideas: http://devmag.org.za/2012/07/12/50-tips-for-working-with-unity-best-practices/ It's also worth coming back to, as your project gets bigger and you get more proficient with Unity, to see if things that didn't make sense before now apply.
The first time you look at it, you may wonder: "50 is an awful lot. Which of these are *really* important?" A thing about Unity is its pretty flexible, so you can be agile about adopting these things. For example, 27 - I'm not doing that yet, probably will have to someday, but when it comes to that a global search and replace should let me fix things up in a couple hours.
Here's the ones I use so far:
6, 7 (usually), 9 (usually), 10, 11, 12 (if you're using other people's assets you can do this with prefabs), 15 (look at prototype textures in the asset store), 16 (well, most things), 19, 26, I'm not doing 27 but probably will have to at some point, I'm not doing 30 but only because I'm the only one working in Unity right now (and I still do it sometimes), 32 (but in a different way, with saveable game state in a MacroState class), 35 (who wouldn't do that, anyway? parallel arrays are so old school), 42, (on a Mac you don't have to do 43), 45 (what you've unlocked so far), 47 (I have a "PrefabLibrary" scene - more on that in a bit).
I'm not doing 36, but I was just bit by some enum problems: supposing you declare a big enum. (I was using one for string localisation.) At first, that seems really nice, because in the Unity inspector gameobjects that expose the enum are human readable. But behind the scenes they still store their values as int, so if you insert something in the middle of the enum it will throw off all your work. For small enums 36 seems like a good option ... for long enums I might want to use strings. (A localisation file is really just a super-long enum, for example, and he does something like it with 39.) Or you can still use enums and make sure when you extend them you only ever add to the end...
37 looks really cool but I haven't tried it yet - my main character class could use it. What I've been doing is giving related parameters the same prefix, like "swing" or "wallrun" or "jump" and alphabetizing them to make them easy to find.
On Specialized Prefabs
I have a lot of triggers that activate challenges. I want them all to look and act the same, but they all trigger different challenges. Sometimes I'd make a change to one, hit Apply to propagate it to all of them, and realize that some variable I didn't want propagated got propagated, like what text it displays or what goody it unlocks.
Concretely, suppose I have two of these things. One unlocks goody 34, the other doesn't unlock anything so I left it in its default of 0. Later I decide these triggers aren't green enough, and I happen to have the scene open with the first one, so I make it more green and hit apply. Now the prefab's default state is to unlock goody 34, and any trigger that hasn't been explicitly specialized will have that 34 value in its unlock variable.
But these things are still pretty simple - so Herman's 33 technique seems like overkill. What I've started doing:
- Remember to edit the prefab rather than the instance when I want to make global changes.
- Sometimes it's hard to edit the prefab - if you want to add a child object, for example. For that, I have a PrefabLibrary scene that has every prefab. The prefabs in there are considered the canonical examples - that's the only place I should feel free to hit Apply from.
- For variables that every instance is supposed to specialize, like which level a teleporter beam transports you to or which challenge a trigger activates, there's a default Uninitialized value that can be checked on Awake and an error thrown.
Another Gotcha With Prefabs - Don't Make A Hierarchy Out Of Them
One thing I've liked to do is build, say, a walkway, or a pipe, out of walkway segment or pipe segment prefabs by making each segment a child of the previous segment. This way I can add each segment and just type in the new +x or +z or whatever, it's the same each time. BUT - this is kind of like a nested prefab, which Unity doesn't like, and if the underlying prefab changes, it can cause all of these pieces to lose their parenting information, and I have to rebuild the thing again. So I still sometimes build things this way, but then make sure to unparent them afterwards.