10 things my 10 years of using Unity have taught me
Over the past 10 years or so of using Unity, I’ve worked on 6 professional games and countless personal projects. I’ve seen many fantastic solutions and an equal number of misuses of Unity that lead to slower and more painful development times. I want to share some of the best advice I’ve acquired over the years.
- Pick your stream carefully
- Disable Compression at import time
- Using and Creating Packages
- Scenes & Prefabs
- Testing
- JetBrains Rider
- Organising your Tools
- Customise the toolbar
- Don’t reinvent the wheel
- Setup asset bundles/addressables and localisation straight away
1. Pick your stream carefully
As you may be aware, Unity offers two main streams of versions, the Tech stream and the long-term support (LTS) stream.
The Tech stream is focused on getting the latest features and fixes to you fast, this is great in the early stages of development, however, APIs and features aren’t locked in at this stage so can be quite volatile resulting in more bugs and crashes, and additional work ensuring your code stays compatible with their APIs.
The LTS stream on the other hand is what you should always aim to ship on, it has a much more stable stream of fixes, less frequent API changes, and will still receive support for new platform versions like Android SDK updates.
When picking your stream consider your release date with the usual shipping times of LTS streams, it’s still okay to start on a tech stream and move to its LTS before launch. Though do bear in mind that a large team using a Tech stream release is likely to be slowed down by this and you should strongly consider using an LTS stream throughout your entire development period.
2. Disable asset compression on import
This one is for those who aren’t making builds on their local machine and instead can just rely on automated builds from their build farm or CI Solution. Unity has a nifty setting hidden away in the Project Settings menu that tells it to not compress assets upon importing them, asset compression is one of the longest parts of opening a project after you’ve pulled changes from other people. If you’re only playing the game in the editor and using your CI to make your builds, you’ll never use the compressed version of an asset and don’t need to wait for it to import. Switch this off if you can, the one downside is if you do need to make a build, you’ll incur the compression time at build time instead.
3. Using and Creating your own Unity Packages
Often in development we find ourselves writing the same systems again and again, and where possible we like to reuse these systems. This is amazingly straightforward to do in Unity, using their built-in Unity Package Management system that you’ll use for a whole host of Unity packages, you can build and publish your packages to any npm registry. This makes sharing code between your projects or others far easier, and forces you to think in a more modular mindset helping you produce cleaner code.
These packages should follow a folder structure at the top level of:
- Runtime
- Editor
- Tests
- Tools
This will align you with Unity’s packages and helps when you need to reference them. Don’t forget to set up some asmdef files for your packages.
4. Scenes and Prefabs
If you’ve worked on Unity projects with lots of developers you’ll have seen the pain that is trying to merge scene file changes. A best practice here is to use prefabs in your scenes as much as possible. Not only does this ensure your changes propagate to all other scenes using that prefab but you can edit the prefab without the scene file being updated, thus lowering the risk of causing a merge conflict.
Another best practice is to keep your scenes small, naturally, this reduces the amount of data in a scene and the likelihood of causing a merge conflict goes down. Another bonus to this is that small scenes can be loaded and unloaded as needed quite quickly which is a very useful tool to have at your disposal when optimizing on mobile.
My other top tip here is to lock the scene files, either manually using a Google sheet to track who has ownership of the file or create an integrated solution for this. If only one person is editing it at a time you won’t conflict.
5. Testing
Just test.
From Unit testing and Unity Play mode tests to dedicated QA testing builds, it’s imperative to test frequently. Seemingly minor changes can have big impacts on each of your platforms. While Unity is super powerful for building cross-platform solutions each platform has its quirks that may take you by surprise. Keeping an eye out for possible issues from day one will save you so much pain later.
6. Jetbrains Rider
At the risk of starting a comment war, JetBrains Rider is better than Visual Studio for Unity.
Allow me to elaborate, I religiously used Visual Studio for everything for years, including Unity development. But a few years back I made the jump to Rider and haven’t looked back, it has deep integration with Unity from its ability to tell you where exactly your Monobehaviour is referenced inside of Unity; to starting and preparing code coverage sessions for you; to it’s enhanced script creation abilities (it even helps you set up asmdef files).
7. Organising your tools
It may not surprise you that as a former lead tools engineer, I’m very passionate about this subject. As your project develops so do your tools, both in quality and quantity. It can be hard to keep track of where all your tools are, find them, and know how they work, from the perspective of both the tools developer and the end user.
This can be countered for the end user very simply, create a tools window to act as a container for your tools, this can be upgraded with tabbed views, favourites, and search features. It makes it a one-stop home for all of your tools.
From a developer perspective, organise your tools in folders next to their features, unit test them (this will act as developer documentation for the tool).
8. Customise the toolbar
Huge shout-out to SMK Games on this one. I discovered their package a few years back, and it has become one of those I add to my projects immediately.
The CustomToolbar package is fantastic, whether you need to jump between scenes quickly, modify the target framerate, or if you just want to add custom shortcuts; this package is a must.
9. Don’t reinvent the wheel
I feel like no Unity top tips article would be complete without a mention of this particular tip. One of Unity’s greatest strengths is its community, so many developers are producing free and paid-for assets that enable you to get your project started rapidly. Never underestimate how much time can be saved by grabbing a few packages early on rather than spending the time to make them yourself.
That’s not to say you should cut and paste your whole game, rather in those early days of development when you don’t know if your idea will be fun; use the asset store to get something playable fast. As you progress you can replace the elements you want.
10. Setup asset bundles/addressables and localisation straight away
If there is one thing I’ve seen ring true on almost every game I’ve worked on, it’s that leaving sorting out your asset bundles / addressables (DLC) til last is a huge mistake. The same goes for localisation.
These systems are huge and in the case of DLC, they’re fundamental to how your game flows. Ensuring you have flows in place to fetch and load your DLC early on will save huge amounts of time retrofitting it, and reorganising your project to ensure your dependencies are correct, and that assets are grouped into the right bundle. One big thing to look out for is the inevitable duplication that can come from asset bundles, Unity will happily load an asset into memory multiple times if it’s in multiple bundles,
With Unity’s new localisation system now up and running there’s little excuse either, it’s incredibly simple to use, and getting started with it from the first text you add to your game will save countless hours of tracking down missed localisations later.
Closing
I hope some of these tips are useful to you and if there’s anything I can elaborate on further leave a comment and I can go more in-depth in a future article.
