This is a question for someone at Unity working on the asset store:
Our asset, Scene Fusion, has to be built for each specific build of Unity. What’s more, is that a version built for a previous Unity build often won’t work for a subsequent Unity build for reasons that might be obvious given what the asset does.
Is there any way we can put it in the asset store in such a way that it will make the correct version available for download, or do I have to submit a version for each compatible Unity build (also, is that even possible)?
In the same asset submission, you can submit a separate package for each version of Unity. The Asset Store will deliver the package that corresponds with the customer’s Unity version.
But, instead of that, is it possible for you to handle versions using compiler directives? Then you can submit a single package that compiles appropriately for the customer’s Unity version. You could future-proof by using an _OR_NEWER directive. For example, if you’ve only designed for Unity versions up to 2017.2, you could add some code like this:
#if UNITY_2017_3_OR_NEWER
Debug.Log("Warning: This asset is not tested on Unity 2017.3 or higher and may not work in your version.");
#endif
although I’m not sure how the Asset Store reviewers will look on that, since they generally want things to be as forward-compatible as possible.
Hmm that might do a good part of the work for us. Our concern is that, because we need to access very specific features of each build of Unity, we don’t want a version of Scene Fusion for, say, Unity 2017.1 to be available to those who use Unity 2017.2 because many of the new features might not work (ie, the new tile system).
Compiler directives work on source distributions. Our product is mostly an assembly distribution so any detection we do is at run-time, though we could package some code in to do the detection and take some action.
If you’re writing in C#, you might want to consider a source distribution anyway since lack of source code will limit your potential customer base.
BTW, Scene Fusion does look very cool. I’m working with a team right now that isn’t using Scene Fusion. The level designers pass a virtual baton in Slack to make sure only one person is working on a scene at a time, which is a hassle.
We do a little bit of C#, though generally tend to avoid doing it because we offer support and need to know the state of the assemblies. We also put a lot of effort and money into Scene Fusion, so giving out the source code might be a bit risky. That said, we do want to have a version that almost everyone can use. It is free for small scenes and 2 users.