Development and publication of asset in the Unity Asset Store

Many games have similar components in themselves (basic game mechanics, integration with social networks, path finding algorithms, GUI, etc.), which are much easier and cheaper to adapt to your project than to develop from scratch.

This is where the Unity Asset Store comes to the rescue, which allows you to buy / sell practically anything that helps with development, whether it be individual scripts, packs with models, or entire game projects and starters whales, which can save a huge amount of work, allowing you not to write basic things that are in almost all games.
')
In this article I will try to talk about how to publish your asset to the unit store, based on the experience of publishing four packages of various kinds. According to experience, I can say that the publication process turned out to have far more pitfalls than we expected, one of the assets was rejected 10 times, referring to various kinds of problems.

Next will be described the moments that are not present in the official documentation for publishing assets, which you should pay attention to:
1) When using Package Upload Tools, a package is assembled and placed, which is uploaded to the server. Since from the preview page of the asset store you can’t download your own asset, it’s best for the final tests to use this particular package, which is created by the tools to load into the store.
If your project uses other packages (for example, you have integrated NGUI to work with the user interface), then you should check that they are not included in the package that you send for review. We had it so that even when the folder with our product was selected, the Plugins folder got into the final package. The simplest solution is to simply delete this folder before loading into the asset store.


2) You must check your asset for plagiarism. In particular, if you use any approaches from assets that are already in the asset store. For example, when we did the Complete 3D Game Template, some functions were taken from another starter kit easier. To avoid any plagiarism, we checked the entire code through MOSS (the most adequate and accurate tool for checking the similarity of the two projects in the code. Developed by Stanford University and able to logically analyze the code, shows the same pieces of code, even if similarities were veiled by renaming variables, splitting the code into functions and the like). An open GUI client is walking around the network to compare sources. You can throw 2 folders with your code and with an asset code, from which you need to check for plagiarism, and in a minute a detailed side-by-side list of intersections will be generated.


3) Your asset should be tested on all platforms. As in the compiled form, and in the editor of the unit, and, preferably, on different versions of the unit. Many things may not work. For example, in the 4th unit there were all sorts of problems with the build under the browser. It was impossible to use not redefined virtual functions in Coroutine, the build just fell.
In unit, when testing an asset, the latest version of Unity3d pro is used, you can rely on it. If on any of the platforms your project will not be collected, it may refuse to publish it until it is fixed.

4) In case a project contains more than a couple of lines of code, it must have documentation. Even if you have all the code documented and there is a readme describing how to start working with an asset, you will often need to make a .pdf describing your systems and how they interact.
It would not be superfluous to make a class diagram: with the help of visual studio, it is done and converted to .pdf in a couple of clicks, but at the same time it saves account users a lot of time.


5) In case you use others in your package (For example, to create a whale starter, we integrated several into the asset at once: NGUI, HOTween, Highlighting System, EasySave2, in other, many of them can be turned off by changing one define), then you Before publishing, you should make sure that you use the latest versions of all the packages, as well as that you indicated in the readme and documentation their names and links to them in the Asset Store. You cannot use old versions of assets. Also, everything should work on the latest version of the unit.
When developing the starter of the whale, we were guided by the experience of developing ordinary projects: it doesn’t work, not staying until the last moment on outdated versions of all assets and units. Subsequently, it took a considerable amount of time and effort to upgrade all assets and fix the bugs associated with the upgrade.

6) A small hack, in case the asset was rejected with a note that something needs to be redone: as soon as you have corrected everything, you can write in response to the message on the rejection of the asset that you have corrected the error and ask to recheck. In this case, you do not have to wait for a long time as when you first send, your package will be tested in a day or two.
In general, administrators in the unit are extremely friendly and will be happy to describe when they asked for exactly how to reproduce the error they found (the first time we couldn’t find a platform-related error we described in detail how to get it. The second time, no matter how strange it was, we asked how to reproduce the error and they could not reproduce it themselves again. As a result, we didn’t change anything and after the repeated test the asset was accepted).