I published the original 50 Tips for working with Unity about 4 years ago.
Although a lot of it is still relevant, a lot has changed since then:
Unity got better. For example, I now trust the FPS counter. The ability to use property drawers makes it less necessary to write custom editors. The way prefabs work makes the need for explicit nested prefabs or an alternative less. Scriptable objects are friendlier.
Visual Studio integration got better, making it a lot easier to debug, and reducing the need for so much guerilla debugging.
Third-party tools and libraries got better. There are now many assets in the Asset Store available that takes care of things such as visual debugging and better logging. Our own (free) Extensions plug-in has much of the code described in the original article (and a lot of it described here too).
Version control got better. (Or perhaps, now I know better how to use it effectively). No need to have multiple copies or backup copies of prefabs, for example.
I got more experience. In the last 4 years I worked on many Unity projects; including tons of game prototypes, production games such as Father.IO, and our flagship Unity asset Grids.
This article is a revised version of the original taking all of the above into account.
Before getting on with the tips, here is a disclaimer (essentially the same as the original).
These tips don't apply to every Unity project:
They are based on my experience with projects with small teams from 3 to 20 people.
There's is a price for structure, re-usability, clarity, and so on — team size, project size, and project goal determine whether that price should be paid. You would not use all these during a game jam, for example.
Many tips are a matter of taste (there may be rivalling but equally good techniques for any tip listed here).
Unity also has some best practices on their site (although these are mostly from a performance point of view):
Best practices for physically based content creation https://youtu.be/OeEYEUCa4tI
2D Best practices in Unity https://youtu.be/HM17mAmLd7k
Internal Unity tips and tricks https://youtu.be/Ozc_hXzp_KU
Unity Tips and Tricks https://youtu.be/2S6Ygq58QF8
Workflow
1. Decide on the scale from the beginning and build everything to the same scale. If you don't, you may have need to rework assets later (for example, animation does not always scale correctly). For 3D games, using 1 Unity unit = 1m is usually the best. For 2D games that does not use lighting or physics, 1 Unity unit = 1 pixel (at "design" resolution) is usually good. For UI (and 2D games), pick a design resolution (we use HD or 2xHD) and design all assets to scale in that resolution.
2. Make every scene runnable. Do this to avoid having to switch scenes to run the game so that you can test faster. This can be tricky if you have objects that persist between scene loads that is required in all your scenes. One way of doing this is to use make persistent objects singletons that will load themselves when they are not present in the scene. Singletons are described in more detail in another tip.
3. Use source control and learn how to use it effectively.
Serialize your assets as text. It does not in practice really make scenes and prefabs more mergeable, but it does make it easier to see what changed.
Adopt a scene and prefab sharing strategy. In general, more than one person should not work on the same scene or prefab. For a small team it may be enough to ask around that no-one else is working on a scene or prefab before starting to work on it. It may be useful to swap physical tokens that denote scene ownership around (you are only allowed to work on a scene if you have the scene token on your desk).
Use tags as bookmarks.
Decide and stick to a branching strategy. Because scenes and prefabs cannot be smoothly merged, branching is slightly more complicated. However you decide to use branches, it should work with your scene and prefab sharing strategy.
Use submodules with care. Submodules can be a great way to maintain re-usable code. But there are a few caveats:
Meta-files are not generally consistent over multiple projects. This is not generally a problem for non-Monobehaviour or non-Scriptable object code, but for MonoBehaviours and Scriptable objects using submodules can cause code to get lost.
If you work on many projects (including one or more in submodules), you can sometimes get an update avalanche where you have to have to pull-merge-commit-push over various projects for a few iterations to stabilize the code over all projects (and if someone else is making changes while this is going on, it could turn into a sustained avalanche). One way to minimize this effect is to always make changes to submodules from projects dedicated to them. This way, projects that use submodules only always have to pull; they never need to push back.
