What’s the best way to add integrations for third-party assets into my existing asset?
I am wondering how other Asset Store publishers handle this kind of approach - creating a system which would work properly with or without third party assets.
For example, there’s an asset that heavily relies on UI. It supports with both UGUI and NGUI.
Here are some approaches I’ve seen (and some I’ve used myself) for distributing integrations, with some pro’s and con’s:
Compiler defines:
If your integration is only code, wrap the files in compiler defines. For example:
#if MYASSET_SUPPORT_NGUI
public class IntegrationForNGUI : MonoBehaviour {
...
}
#endif
Then provide an editor menu item to automatically add or remove these defines using PlayerSettings.SetScriptingDefineSuymbolsForGroup(). (Don’t make the customer manually add the symbol in the inspector; it can be confusing for non-programmers.)
Pros: Easy for the customer to enable integration.
Cons: With this setup, your main development project typically contains all of the third-party assets. It’s easy to forget to wrap an integration script in compiler defines, which will cause the compile to fail on customers who haven’t imported that third-party asset. Also, if you’re integrating multiple Complete Project assets, their ProjectSettings may be incompatible, so you won’t be able to use this approach.
Unity packages in folder:
Package each integration into a unitypackage, and put them all in a single subfolder in the main project. The customer can import any needed integration packages and/or delete the folder to reduce project size. Make sure each integration package imports into its own subfolder so it’s easy for the customer to remove if they want. Make sure the integration package doesn’t include any actual files from the original third-party asset.
Pros: You can have separate projects for each integration. This lets you test each one individually, and ensures that the main project doesn’t have any code that depends on third-party assets. It’s also really easy for the customer to enable integration by simply importing a package.
Cons: It’s more to manage. (The Dialogue System has 30+ integration projects). I’d never attempt this by hand. I use uTomate to handle it automatically. As with the compiler defines approach, it makes your main package bigger.
Unity packages on your website:
Put the packages on your website. Either let customers download them, or provide an editor window to automatically download and import them. If you let customers download them, you can use the Asset Store’s invoice verification API to verify the customer first if you want. For my assets, I make them freely downloadable. I figure it’s less hassle for the customer, and they won’t run on their own anyway since they’re just integration packages.
Pros: Same pros as unitypackages in folder, but it also keeps the main package smaller.
Cons: Same cons as unitypackages in folder, but you also have to manage the web part.
If you can design your asset so it provides some kind of abstract interface for integration, it’ll make your life easier, and it’ll usually make the integrations much cleaner and more loosely coupled. Taking the Dialogue System as an example again, it uses an abstract IDialogueUI interface to run dialogue. Each integration (NGUI, Unity UI, etc.) simply implements the interface. I can add new integrations quickly without having to touch the main source code.