We can prioritize which Scripts will have their Update and Fixed Update methods called before others, by navigating to Edit | Project Settings | Script Execution Order. With the exception of some time-sensitive systems, such as audio processing, if we find ourselves trying to solve complex problems using this feature, it implies that we've got some fragile and tight coupling between our Components. From a software design perspective, this can be a warning sign that we might need to approach the problem from another angle. However, it can be helpful to have particular objects get their Update() and LateUpdate() functions called before other objects, in order to do some bookkeeping.

Integrating Unity projects with a Source Control solution can be a little tricky. The first step is to force the project to generate .meta files for assets; if we don't do this, then anyone pulling data into their local Unity project must regenerate their own metadata files. This can easily cause conflicts, so it is essential that everyone uses the same versions. Visible metadata files can be enabled by navigating to Edit | Project Settings | Editor | Version Control | Mode | Visible Meta Files. All of the .meta files will now be visible within the file structure and available for upload into Source Control.

It can also be helpful to convert certain asset data into a Text-only format, rather than binary data, to allow manual editing of data files. This turns many data files into the much more human-readable YAML format. For instance, if we're using ScriptableObjects to store custom data, we can use a text editor to search and edit these files without having to do it all through the Unity Editor and serialization system. This can save a lot of time, especially when hunting for a particular data value or when multiediting across different derived types. This option can be enabled by navigating to Edit | Project Settings | Editor | Asset Serialization | Mode | Force Text.

The Editor has a log file, which can be accessed by opening the Console window (where log messages are printed out to), clicking on the "hamburger icon" (made from three horizontal lines) at the top-right, and selecting Open Editor Log. If we recently built our project, it will contain a breakdown of compressed file sizes of all assets that were packed into the executable and ordered by size. This is an extremely helpful way of figuring out which assets are consuming the majority of our application footprint (hint: it's almost always Texture files), and which files are taking up more space than we would expect.

Additional windows can be added to the Editor by right-clicking on the title of an existing window and selecting Add Tab. This also allows us to add duplicate windows, such as having more than one Inspector View open at a time:

Having duplicate views can be kind of redundant, unless we use the "lock icon" to lock the given view to its current selection. When we select an object, all Inspector Views will update to show the object's data, except for any locked Inspector Views, which continue to show the data of the object they were locked to.

Common tricks that make use of window locking include the following:

We can enter calculations into numeric inspector fields. For example, typing 4*128 into an int field will resolve the value to 512, sparing us from having to pull out a calculator or do the math in our head.

Array elements can be duplicated and deleted from a list (in the same fashion as the hotkeys mentioned previously) by right-clicking on the root element and selecting Duplicate Array Element or Delete Array Element.

A Component's context menu can be accessed through both the small cog icon in the upper-right or by right-clicking on the name of the Component. Every Component's context menu contains a Reset option, which resets all values back to their default, sparing us from having to reset values manually. This is useful when working with Transform Components, as this option will set the object's position and rotation to (0,0,0) and its scale to (1,1,1).

It's commonly known that, if a GameObject was spawned from a Prefab, then the entire object can be reverted back to its initial Prefab state using the Revert button at the top of the Inspector View. However, it's less well known that individual values can be reverted by right-clicking on the name of the value and selecting Revert Value to Prefab. This restores the selected value, leaving the rest untouched.

The Inspector View has a debug mode that can be accessed by clicking on the hamburger icon next to the lock icon and selecting Debug. This will disable all custom Inspector drawing and reveal all raw data within the given GameObject and its components, even private data fields. Private fields are grayed-out and cannot be modified through the Inspector View, but this gives us a useful way of examining private data and other hidden values during Play Mode. The Debug view also reveals internal ObjectIDs, which can be useful if we're doing "interesting" things with Unity's serialization system and want to resolve conflicts.

If we have an array of data elements serialized in the Inspector View, then they are typically labeled Element <N> where <N> is the array index. This can make it tricky to find a specific element if our array elements are a series of serialized classes or structs, which tend to have multiple children themselves. However, if the very first field in the object is a string, then the elements will be named after the value of the string field.

When a mesh object is selected, the Preview window at the bottom of the Inspector View is often fairly small, making it hard to see details in the mesh and how it will look when it appears in our Scene. But, if we right-click on the top bar of the Preview window, it will be detached and enlarged, making it much easier to see our mesh. We don't have to worry about setting the detached window back to its original home because, if the detached window is closed, then the Preview window will return to the bottom of the Inspector View.

The Project View's search bar allows us to filter for objects of a particular type by clicking on the small icon to the right of the search bar. This provides a list of different types we can filter by, revealing all objects of that type within the entire project. However, selecting these options simply fills the search bar with a string of the t:<type> format, which applies the appropriate filter.

Thus, we can simply type the equivalent strings into the search bar for the sake of speed. For instance, typing t:prefab will filter for all Prefabs, no matter where they can be found in the hierarchy; t:texture will reveal textures, t:scene will reveal Scenes, and so on. Adding multiple search filters in the search bar will include objects of all types (it does not reveal objects which only satisfy both filters). These filters are modifiers in addition to name-based filtering, so adding a plain text string will cause a name-based search through the filtered objects. For example, t:texture normalmap will find all texture files that include the word normalmap in their name.

If we're making use of AssetBundles and the built-in labeling system, the Project View's search bar also allows us to hunt down bundled objects by their label using l:<label type>.

If a MonoBehaviour script contains serialized references (using [SerializeField] or public) to Unity Assets, such as Meshes and Textures, then we can assign default values directly into the script itself. Select the script file in the Project View and the Inspector View should contain a field for the asset for us to drag-and-drop the default assignment into.

By default, the Project View splits files and folders into two columns and treats them separately. If we prefer the Project View to have a typical hierarchy folder and file structure, then we can set it to One Column Layout in its context menu (the hamburger icon at the top right). This can be a great space saver in some Editor layouts.

Right-clicking on any object in the Project View and selecting Select Dependencies will reveal all objects upon which this asset relies in order to exist, such as Textures, Meshes, MonoBehaviour script files, and so on. For Scene files, it will list all entities referenced within that Scene. This is helpful if we're trying to perform some asset cleanup.

A lesser-known feature of the Hierarchy View is the ability to perform component-based filtering within the currently active Scene. Confusingly, it uses the same syntax as performing type-based filtering in the Project View and can therefore be accomplished by typing t:<component name>. For example, typing t:light into the Hierarchy View search bar will reveal all objects in the Scene that contain a Light component.

Upper- or lower-case characters are unimportant, but the string must match the full component name in order for the search to complete. Components that derive from the given type will also be revealed, so typing t:renderer will reveal all objects with derived components such as Mesh Renderers, Skinned Mesh Renderers, and so on.

The Scene View camera is not visible from the Game View, but it is generally a lot easier to move around and place through the use of the hotkeys mentioned previously. The Editor allows us to align the selected object to the same position and rotation of the Scene camera by navigating to GameObject | Align with View (Ctrl + Shift + F / Cmd + Shift + F). This means that we can use the camera controls to place the Scene camera where we would like our object to be, and place the object there by aligning it to the camera.

Similarly, we can align the Scene view to the selected object by navigating to the GameObject | Align View to Selected option. This is useful for checking if the given object is pointing in the right direction.

We can perform similar component-based filtering on the Scene View, as we can with the Hierarchy View, using the t:<component> syntax within its search bar.

At the very top right of the Unity Editor is a drop down labeled Layers. This contains a Layer-based filtering and locking system for the Scene View. Toggling on the "eye" icon will show/hide all objects of that Layer within the Scene View. Toggling the lock icon will allow or prevent objects of the given layer from being selected. This is helpful for things such as preventing someone from accidentally selecting and moving background objects that have already been situated in the perfect location.

A commonly known and useful feature of the Editor is that GameObjects can be given special icons or labels to make them easier to find in the Scene View. This is particularly helpful for objects with no renderer but that we wish to find easily. For instance, objects such as Lights and Cameras have built-in icons that identify them in our Scene View more easily.

However, the same gizmos can be revealed within the Game View by clicking on the Gizmos button at the top right of the Game View. The drop down for this option determines what gizmos will be visible when this option is enabled.

Since Play Mode changes are not automatically saved, it is wise to modify the tint color applied during Play Mode to make it blatantly obvious which mode we're current working with. This value can be set by navigating to Edit | Preferences | Colors | Playmode tint.

Changes can be saved from Play Mode by simply using the clipboard. If we're tweaking an object in Play Mode and we're happy with its settings, then we can copy the object into the clipboard using Ctrl + C (Cmd + C), and paste it back into the Scene once Play Mode ends with Ctrl + V (Cmd + V). All settings on the object at the time of the copy will be kept. The same can be done with individual values or entire components using the Copy Component and Paste Component options in the component's context menu. However, the clipboard can only contain data for one object, component, or value, at a time.

Another approach, which allows us to save the data of multiple objects during Play Mode, is to create Prefabs from them by dragging and dropping them into the Project Window at runtime, once we're happy with the settings. If the original object was derived from a Prefab, and we wish to update it across all instances, then we only need to overwrite the old Prefab with the new one we created by dragging and dropping the copy on top of the original. Note that this also works during Play Mode runtime, but it can be dangerous since there is no dialog pop-up to confirm the overwrite. Be very careful not to overwrite the wrong Prefab.

We can use the Frame Skip button (the button to the right of the Pause button in the Editor) to iterate one frame at a time. This can be useful for watching frame-by-frame physics or gameplay behavior. Keep in mind that this causes both one Fixed Update and one Update to be called each step, in equal counts, which may not exactly reflect actual runtime behavior where we tend to have unequal calls to these methods.

If the Pause button is enabled when Play Mode begins, then the game will be paused just after the very first frame, giving us a chance to observe any anomalies that occurred from initialization of our Scene.