• The Asset Store
• Sharing & Licensing
• Working with various Assets simultaneously
• Time available to learn the ways of the asset
• Under active development?

The Asset Store

One of the great advantages of developing in Unity is the Asset Store. It is filled with thousands of great free and paid assets. Their clear descriptions, excellent user-review system, and often great developer support make them a joy to use. 

Using these assets in your project is a great way to shave hours off of development time. However, some considerations are mentioned below.

Sharing & Licensing

Using assets from the Asset store come with some restrictions in how you can distribute them. Do check with each individual asset, but in general you’re operating under these rules:

1. Any asset you download or purchase is yours to use in your project(s).
2. Assets downloaded or bought can be distributed to others, but only in a Build. This means that you can create a Unity Project using as many third party assets as you see fit, and once you’re completely done you can Build a stand-alone version of this program. That stand-alone program can then be run on the targeted device without Unity (for instance as an .exe or .apk). You can send this Build to other people (e.g. other researchers in other universities), for them to use it exactly as you’ve created it. 
3. You’re not allowed to send other researchers the asset separately, nor as part of your larger Unity project. This means that your colleague cannot easily adapt your program to their needs. You cannot send them your Unity project for them to continue working on, such as in an Open Source framework. This rule has some influence on projects which are funded under a general goal of collaboration, either personally or as part of a larger Open Source philosophy. 

If you do want to create something that can be modified by other developers, there are a few ways to deal with the restrictions:

1. You can simply not use third-party assets, and create everything yourself. 
2. You can distribute only stripped versions of your project to other researchers / developers. So, in your version you do use third-party assets, but in the version you share with other researchers you’ve stripped these out of your project. A few ways to do this:
   1. You can create and distribute something resembling a ‘grey-box’ version of your project. This version does not contain any third-party assets, but is generally still usable, and easy to develop further by your colleague. 
   2. You can wrap the ‘boundary’ between your code and third-party code in a layer of Interfaces. This still requires you to strip third-party assets from your project, but they can then be more easily swapped for other solutions. 
3. If you would like to use third-party assets in your project, but not send this to other developers via Git, you have two options. For both, it’s easiest if you put all third-party assets in a specific folder in your Asset directory.
   1. You can use git submodules, and add that folder as a private submodule.
   2. You can add that folder to your gitignore. 

You probably want to use multiple of the suggestions mentioned above. As long as you consider dissemination and licensing actively during development, you should be fine.

Working with various Assets simultaneously

One thing to consider is how well various assets work together. Suppose for instance you want to have talking characters in your project. In this case you’ll need to have at least two complementary assets:

1. A competent LipSync system which handles the facial movement (for example SALSA).
2. A character model which has a detailed facial rig and/or BlendShapes supporting your needs. 

Naturally, one would not work without the other. 

As another example, suppose you’re building an environment from various purchased assets. You want to double check whether the various assets are complementary in both visual style as visual fidelity, so no object looks out of place. 

Finally: using one third party asset is often easily done. Creating a networked version of your application is a breeze with Photon when following their online tutorial. However, making sure all your other assets or custom XR rig is correctly synchronized over the network is another question altogether. 

Time available to learn the ways of the asset

Even though assets through the Asset Store can be a great help in reducing development time, you’re still going to need to budget time to learn to use these assets. For example, both SALSA LipSync and FinalIK (see below for more information about these assets) are fantastic tools, but come with a fairly steep learning curve. Make sure you’re fully understanding and testing the capabilities of the assets you’re using, to make sure there’s no surprises later on in development.

Under active development?

Double check to make sure that the asset you’re intending to use is still under active development. Also check the review/comment section to see if other users of the asset have left comments whether the developer is responding to questions and how they respond to bugs. This is especially important when coding is involved in using the asset. If the asset is no longer under development, you’ll have to consider whether you have the time, energy, and capability to fix the asset yourself if need be. While you’re at it, check whether your current Unity version is supported by the asset. 

However, even when an asset is under active development you’re not out of the woods yet. Since developers are free to change their asset’s API as they see fit, you can easily break your own code when updating assets. Two solutions: 

1. Consider whether  you really need to update the asset. “If it ain’t broke, don’t fix it”.
2. Wrap the ‘border’ in between your code and the third-party code in an interface or wrapper class. This way, if other developers change their API, at least the problems remain (largely) localized and not spread-out throughout your own code.