I have been using Unity for a while and just my my sake I wanted to compile a list of Do’s and Don’ts that will save you a lot of time (or if you are like me stop from going Doh! and hitting your forehead a few hours later).
1. Importing from Blender to Unity. Make sure you set the import to calculate your normals again. At least in Blender 2.56a the exports product models with extremely dark Textures. So unless you want environments in your game to be a homage to 2001 Space Odyssey.
3.Never use gravity a local variable name. In fact make sure if the editor highlight any variables that you aren’t using as a public or private variable. Bad things happen.
4. Always print out the gameobject you are acting against if you can’t find the components on it. I was trying to figure out why my projectiles wasn’t able to SendMessages or access components on a gameobject. The Tag was right. Made a fool of myself on Unity answers.
5. You CAN attach multiple scripts to a player. You can attach it to colliders on the bones that are hidden ONLY if you drag it to the scene and inspect it there. It won’t show up on the prefab.
6. Use the 80/20 rule of networking (well my 80/20 rule anyways)..If you think or findout that 80 percent of the time the variable needs to be updated, use state updates to do it versus RPC’s. I haven’t done a benchmark on Unity3D RPC’s but in my past experience with newtork coding RPC are slow, not timely and fat on network bandwidth. Easy to use again, but not to often.
7. Put something in your script name to help you find where it is. When inspecting a game object you can find scripts attached but have to hunt for the scripts. Putting all the scripts in 1 place and for me starting with a Prefix is a must. For example call player code ‘PlayerInputController’ and put it under a player folder in scripts. Good for you and good for any programmers that follow
8. Understand the code your write (or copy). There are alot of helpful scripts but the need to complete a project will drive you to cut and paste code. Soon you will have jumble of unoptimized code and if you don’t understand it a nightmare just waiting to happen.
9. The inspector can be useful to debug your game. If you select it during gameplay, you can check out public variables. It’s a quick and dirty way to do debugging rather then setting breakpoints which I haven’t done yet because it’s a pain to switch to the MonoDevelop (which is buggy, the scroll bars don’t respond to my mouse wheel and the folder ‘lock up’ so I can open it to click on scripts).
10. Beer and code don’t mix unless you have to re-write some particularly painful code. ;P