Making plug-and-play Modular addons

Hello, I am making an asset with optional (modular) addons for the unity asset store. However, I have run into the problem that the main asset often needs to reference the addons in order to work. This is a problem because none of the optional addons will be there in the base version, which means it will have errors. I also have the issue that some sections of my asset’s options will only exist for the addon.

Does anyone have any tips on how to handle this sort of thing in a user-friendly, modular, way? For example, is it possible for me to drag and drop addons onto my base unit and have them automatically couple?

1 Like

When importing the add-on, you can add custom scripting symbol in player settings via code: Unity - Manual: Custom scripting symbols

In the main asset code, you can check this symbol using the known way: Unity - Manual: Conditional compilation

There are more tips in my Manual for Asset Store Publishers.

In most cases, you shouldn’t change the player settings’ custom scripting define symbols. They’re platform-specific, disruptive to set up and hard to manage well. They should only be used to configure platform-specific compile-time options, not editor-only configurations.

E.g. do you set your symbol on all build target groups or only the active one? What happens if the user switches active build target? What if Unity adds a new build target group?

The best option is to use “Version Defines” on Assembly Definitions. This allows you to set up compilation defines based on installed packages. Those defines can depend on the package version and will only apply to the assembly definition, not polluting the global compilation define namespace. (You can also combine it with “Define Constraints” to completely exclude and assembly based on a “Version Define”.)

Unfortunately, this only works with Package Manager packages. There’s experimental support for shipping asset store assets as such packages, and I hope that we’ll see more and more assets adopting this, but right now you’ll find plenty of assets that still install into the Assets folder.

In this case, a better solution might be to generate a csc.rsp file next to your assembly definition, that contains the compilation defines to activate the integrations based on the installed assets you’ve detected. This will also only apply to the assembly definition the file is placed next to and not pollute the global namespace.

For the asset-specific options, I would not compile them out when the asset is not present, only hide them in the GUI. Otherwise, if the project configuration changes in unexpected ways (during an upgrade, a merge, the asset updating and no longer being detected correctly, etc), there’s a chance for the options to be lost if they’re compiled out intermittently.

1 Like