All content in this course uses:

Unity Tips

A collection of tips and tricks to make your Unity development faster and more convenient.

Snap objects when moving, rotating or scaling by holding CTRL (PC) or CMD (Mac). Also use V to snap Vertices together. Change settings for snapping by choosing Edit - Snap Settings.

Snapping

Working with the Preview window on the Inspector a lot? Unleash it's power by right-clicking the bar at the top to un-dock it and place it wherever you wish.

Undock the Preview window

Need a quick and easy way to position cameras? Use GameObject - Align with View.

Positioning Cameras easily

When in playmode, Unity doesn't save changes to instances of game objects in your scene. So you always need to switch off play to keep editing - remind yourself to do this by tinting your editor on play.

Play Mode Editor Tint

Need to find help on a particular component in Unity? simply click the book icon to the right of each component header.

Documentation Shortcut

Exposing a float variable in the Inspector for tweaking? Add a Range declaration above your variable in your script and you can instantly turn your public variable into a slider.

Show public variables as Sliders with [Range(min, max)]

Type the complete, case sensitive name of a script or component in the hierarchy search to reveal game objects that have it attached.

Find objects in the Scene by Component name

Enter math calculations directly into any int or float field in the editor!

Math Calculations in Number Fields

To make empty game objects visible when not selected, assign them standard or custom icons.

Use custom icons for empty game objects in Scene views

In this quick tip we'll show you how to copy a single component's settings or how to copy an entire game object in order to restore changes made during play mode.

How to copy and restore changes made in play mode

One of the great advantages of working with Unity is the ease and speed of using the editor interface and the Inspector panel. Variables must be public to be used in the Inspector... or must they? No! You can expose and manipulate private variables in the Inspector by using the "Serialize Field" attribute!

Show private variables in the Inspector

Create and attach new scripts fast by using the Search field in the Add Component Button menu.

Create new scripts fast with Add Component shortcut

Unity offers numerous ways to organize your files or how to approach making your game. This freedom allows for fast prototyping but comes at the price of potentially making the project slower to open, to navigate or develop when it becomes bigger. This guide will give pointers and hints on how to mitigate that and tips to take into account when starting your project.

Before even starting working on your Unity project, there are a couple of steps to think about.

Using source control is very important for any project. It provides safeguards to minimise mistakes and simplifies working with multiple people. Unity has a source control service called 

 that is seamlessly integrated in the Editor.

If you are using an external source control such as Git, Svn, Mercurial or Perforce you will need to configure a couple of settings:

In your source control of choice, exclude the folders 

 as they are not needed to open the project on another computer and would just clutter the repository and use storage needlessly

Edit > Project Settings > Version Control

: This will place meta files next to your assets, in which parameters and import settings are stored. This allows you to share import settings and references by including these files in version control. Otherwise, these settings are stored in the Library folder and cannot be shared between members of the team.

: make all unity files (ScriptableObjects, Scenes, Prefabs and many others) use a text representation instead of a binary one. This allows source control to just store modifications to these files when they change, rather than a whole new copy of the file, and allows you to manually merge any conflicts 

(Note : on very big projects, the additional time needed to import text asset versus binary asset could create a quite noticeable difference. Most projects will not reach that size threshold where the benefits of text over binary are overcome by time of import, so setting to text in the beginning is still recommended)

 In the Perforce Workspace settings, use "revert unchanged files". This will prevent unnecessary commits of files that have not changed.

Decide on standards for the project so everyone working on the project uses the same ones.

 : decide what one unit in Unity is, otherwise models or sprites will not be created using a unified scale. Introducing different scaling for different objects can lead to all sort of problems.

For most 3D games that use Rigidbody components, use one unit = one meter, as the physics system requires that for proper simulation

For 2D games that use Rigidbody components, define a "base sprite size" that will be equal to one meter and one unit. For example 32px = 1 meter and 1 unit. Set all Sprites 

 to that value, so your character sprite that is 64px tall, with a PPU of 32 will be two units therefore two meters tall for the physics system.

 your assets should all follow a naming convention. It can be appending suffixes (An example for textures would be 

N for normal map or _AO for Ambient Occlusion map) or prefixes (Such as LowRes

 or HighRes_ on variations) . It will allow to filter through search and also can help writing custom importer setting value automatically.

Use the Project View in the Unity Editor to organize your assets. Unity keeps a meta file (if enabled, see Source control) next to each asset file that stores the asset’s import settings. That means you should 

avoid moving files through your OS file explorer

, always move them from inside the Unity editor as it will take care of moving everything properly. If you need to move them outside the editor, 

do not forget to move the meta file with them

, otherwise you will lose references and import settings.

To keep the project easy to navigate, avoid placing files in the root Assets folder. Use subfolders. How you organize those subfolders is generally decided by your projects but the two main ways to do it are:

A folder for each type of asset and subfolders in them per objects, zones (For example 

Assets/Level1/Enemies/Archer, Assets/Shared/UI, Assets/Forest/Trees

) with all assets related to those in the folders (

Note that the second way will help if you plan on using 

 as you can then create bundles per content themes just by adding the parent folder to a specific bundle and easily splitting your related assets through different bundles.

Keep everything that is related to a prototype or placeholder in a separate folder hierarchy, and avoid cross referencing between those folders and folders which contain shippable assets/code. For example, your Character prefab in the "normal" file hierarchy should not reference a test material in your Prototype folders. Create a prototype character prefab that would reside in the Prototype folders and never use that prefab in a non prototype scenes (you could even write editor scripts that check references used by objects in the prototype folder to be sure that this rules is enforced. )

Avoid using the Resources folder as much as possible.

 Resources is a special folder name in Unity where assets placed can be loaded dynamically using 

 in code. Some games will require dynamically loaded assets, but try to minimize the assets you place in there as much as possible, as Unity cannot strip any unused assets in there (it cannot tell if you load it via code or not) so everything in that folder will be included in the final build.

As you load assets in code with the path & filename, it also makes refactoring (moving or renaming files) harder and more error prone, as it requires you to manually change the path or name in code.

To use a direct reference (public variable in Monobehaviour) to assign through the editor. This will also support moving or renaming of files.

 version of the function, which will not block execution (on some devices, Loading can take a long time). This function returns an 

 that you can either poll every update to check if it's finished, or use the completed event like this:

Unity offers a way to import source files from a range of different software (Some examples are Photoshop, 3DS Studio Max or Blender) directly. If used for a quick test or prototyping, 

never commit those to your source control or keep them in the Assets folder past the prototyping or test phase

Those files are usually bigger than exported files. Bigger files lead to cluttering the source control history, and every time you modify one, the source control will store the new version, leading to an explosion of the size of your repository.

Those files rely on the software they belong to being installed on the machine opening the Unity project. Any collaborator without the right software installed or a build machine will not be able to open the project.

It is preferable to store those files either in a separate source control software (maybe more suited for binary files) or, if you cannot do that, store them outside of the the Assets folder, so Unity does not import them, and exports your assets to a Unity compatible format to place in the Assets folder and use in game.

Try to keep your asset size to the smallest possible (a bad example would be to export a 2048x2048 texture for a coffee mug on a table). You can reduce the size of a texture in Unity import settings but that will not reduce the import time of the texture, which makes the initial setup on fresh versions of the project way longer.

Test locally with whatever format, but once decided, use compressed format for audio and image files. .png/.tga/.tiff for images (or even .dds if your image software supports exporting those), .ogg for audio. Unity will import (or simply use as is) way faster, cutting down the original import size of the project.

Assembly Definition Files (ADF) compile all scripts in a folder and its subfolders into a separate DLL. This reduces compilation time, by splitting it to only the dll to which the changed script file belongs. For example, if you have an ADF for all your Enemies scripts, changing the enemy scripts will not recompile all your helpers, player, game systems or UI scripts but rather just the scripts related to Enemies.

In teams of more than one, define ownership of zone/assets/features. Some assets like scenes or prefabs do not handle simultaneous changes by multiple people very well, creating conflict. Having a single person who can change (or give the right to change) a given assets helps to avoid that problem.

Use them. A lot. Prefabs keep a single point where you can modify settings for objects in your game. Just 

 as changes on the original prefab will not be pushed to the one nesting it.

Use them. A lot. Just like prefabs, they offer a single place where you can change their settings that may be shared across scenes or objects. Note that if your scriptable object references other scriptable objects or prefabs, and a GameObject in your scene references that scriptable object, when the scene GameObject is loaded, it will trigger a loading of the scriptable object and all references to the objects in a recursive fashion. This can lead to long loading times for scriptable object referencing a lot of other objects or content. But you can also use that to your advantage if your project prefers to load objects at scene load in one big load.

Keep the depth of the hierarchy to a minimum. As a general rule, you should prefer multiple small hierarchies at the root to one big hierarchy.

The reason for minimal hierarchy depth is that Unity transform system has to walk that hierarchy to notify all children when a transform changes.

The reason for multiples hierarchies is that changes are tracked per hierarchy. So if you have 100 hierarchies at the the root, and change one object in those, only one hierarchy will have the transform traversal. But if you have one big hierarchy at the root, any change to any object will trigger a hierarchy change on all your objects. Additionally, Unity will multi-thread transform change checks on root GameObject hierarchies. The more hierarchies you have, the more Unity can multi-thread and speed up multiple transforms change per frame.

 (static environment meshes, lights or sounds) in a single hierarchy if that simplifies your scene navigation/organization for you. Since those will never have their transform changed, the drawback mentioned above does not apply.

To keep the hierarchy depth in check and spread your hierarchies in root:

Do not nest pure gameplay objects with the graphics, physics & audio representation. If something does not need to move with your character, it should not be a child of it. For example, having a GameObject that handle the patrol points of a navmesh agent character is a child of that character. All pure gameplay GameObjects should be as close to the root as possible.

Similarly, when you create a GameObject dynamically, do not make them a child of the object that created them unless they need to be moved with that object

Reducing hierarchy depth is not only beneficial for the engine performance, but for the ease and comfort of the person working on the project. More shallow hierarchies are easier to understand and traverse :

 in the Rig tab of your Animation import settings. This will prevent the "skeleton" GameObject of your rig being created, reducing the hierarchy. If you need to still expose some (you may use one as the target to attach equipment on the character) you can manually pick it to only expose this one.

Use an empty GameObject to organize your hierarchy. For example use a GameObject named 

Note that you should not make it the parent of your lights, but just place it above it in the hierarchy

 for reasons explained in Hierarchy depth and count above.

If you want for ease of working to parent all light under your Light "header" so you can collapse everything, you should write an editor script that unparents everything before build and/or entering playmode, otherwise performance could suffer on large scenes.

If you have dynamic objects that are created and executed in the editor 

 in playmode (For example, a reflection camera that moves to match the scene view camera so Reflections work in the Scene View or a render target updated in the scene view assigned to a material) be sure to set the 

 if you want to keep it visible in the hierarchy to edit it). Otherwise all changes in position or content will dirty the scene, asking to save it every time. This leads to a greater chance of creating conflict if someone saves and commits the scene to source control inadvertently as this will happen to everyone, all the time.

To improve the speed of the development/test/improve cycle, add in "cheat" functions for various features as early as possible. An example could be if your project has currency, make a cheat to get huge amounts of it. If you need to gain items to open doors, make a cheat to grant said item instantly. Create a way for the player to be teleported at points of your level if levels are long. QA and debugging will become way easier. There are multiple ways to do this:

Static functions that implement the cheat with <b> [MenuItem("Cheat/MyCheat")] </b> will allow you to cheat when playing in the editor through a top menu entry.

Good old "Cheat code" based on key press in a particular order, or even simply using the F1/F2 function keys of your keyboard.

Code an in-game console that can be opened with a keypress and in which commands can be typed & interpreted to cheat.

 checkbox of the build window not ticked will remove those and you will not ship your game with all those cheats in. You can do that in two ways:

A conditional attribute for cheat functions

This allows the compiler to just ignore that function on non-development build, so calls to that function will just be ignored.

Or wrap code related to cheating inside functions between

This ensures they will be stripped from the final build. Note, that if you wrap a function between those, the build will fail because all calls to that function will be calling a non-existent function for the compiler. It is preferable to use the Conditional attribute above for functions.

Create and keep small scenes that are only made to test a single feature separate. Some examples could be a scene full of enemies to test the combat, an obstacle course whitebox to test the locomotion, one with interactable objects. This allows you to develop, improve and verify features are not broken by new ones. It will also allow you to more simply isolate a problem testers may have found in the "full" game. For example, you have a character that sometimes fails to grab to a ledge? This can be much easier to reproduce in a small scene than having to replay the first 5 minutes of a level 20 times to reach the point where the problem occurs.

Unity Version 2022.2