Unity Essential Self-Help Tips

This post is a quick summary on how to approach investigating issues in and around Unity that isn’t an installation or system failure (see: Troubleshooting Install / Odd Issues).

Log Files

Be it an issue installing or launching the Hub, the Editor or your Build, there’s a log file for each which you can and should inspect for any errors that do not appear visibly.

Try in a new, empty project!

If you have some issue in your project that you attribute to Unity or a specific version of Unity, it’s best to try and verify the issue in a new, empty project.

Most commonly you’ll find the new project works fine. This gives you confidence that the issue has most likely something to do with whatever is in your project, or the project settings.

Editor major/minor version upgrades

Understandably, large teams try to lock-in to specific editor and package versions. However, this best practice for LARGE TEAMS has somehow trickled down to the solo indie developers and small teams becoming super-hesitant to upgrade versions.

Do not be afraid to upgrade! Especially if you DO have an issue. You can always do so in a copy of the project! There’s always a chance that the issue you are having is known and has since been fixed.

The issues that you do face after an upgrade are commonly quickly resolved by making a few script changes and searching for that particular issue.

Of course, if you make huge jumps more issues are likely to occur! Eg don’t try to upgrade from 2019 straight to 2022. Instead, upgrade to every yearly version one at a time respectively with Unity 6.0 upgrade to 6.1 and 6.2 and so on.

This step-by-step upgrade process helps to find the version you can most conveniently upgrade to, and you can fix smaller batches of issues one at a time rather than getting drowned in dozens of errors and issues.

Keep upgrading to latest patch releases!

Even if you do not have any issues, it is BEST PRACTICE for small teams to keep updating the editor frequently to the latest patch release. That’s the third number, ie an upgrade from 2022.3.42f1 to 2022.3.45f1.

IMPORTANT: Do NOT stay on early patch releases! You can expect to experience more bugs in earlier patch release versions. I would recommend to keep upgrading until you’re at least past 20f1 and then you may want to upgrade every +10 patch releases at the latest - unless you have absolutely zero issues whatsoever.

CAUTION: do not downgrade editor versions!!

Downgrading editor versions is NOT supported, and when it has to be done, be sure to delete the Project caches (eg Library)!

There are no guarantees that an editor version downgrade will work flawlessly. It may introduce persistent issues, an in rare cases may even corrupt assets. These are more likely to occur when downgrading between major versions (ie 2022, 2023).

Package version upgrades

Package version updates are unlikely to have been fully tested against all possible dependent package versions. Thus when upgrading just one package, it is best to also upgrade the packages that depend on the one you intend to update.

Issues may even suddenly occur to you without changing anything in the project because development of the editor and packages continues. Mainly such packages that have an online or cloud service component are prone to issues of this kind (eg sudden 404 results). Be sure to update cloud service packages when such an issue occurs

Debug and Profile

Any odd issues like random framerate drops are best analyzed by debugging and profiling.

Ideally try to isolate the issue and reproduce it in a new, empty project. This would tell you whether the issue is with a particular editor version and its packages, or a project-specific issue. All too often it is the latter, while devs are all too quickly to blame it on the former.

In my experience, an editor or runtime performance regression is far, far more commonly caused by the project’s assets themselves than it is by the Unity Editor or Unity Runtime or Unity’s packages.

Be cautious when using editor scripts and assets that are heavy on editor tools. These can have a SEVERE impact on Editor behaviour, sometimes only observed in certain circumstances. Most editor tooling assets are not developed within a real production project, thus they are often ill-prepared to handle the number and size of assets or the workflows of a production project.

About deleting library. In a large game this one takes a few gigabytes and consists of many thousand files. Takes super long to delete with the wrong method even on a gen4 nvme.

Use rmdir /s/q library from a cmd console and it will take seconds instead of minutes.

1 Like