Developing and publishing an asset in the Unity Asset Store

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

Here the Unity Asset Store comes to our aid, which allows us to buy / sell almost everything that will help with development, whether it be separate scripts, packs with models, or entire game projects and starter kits, which can save a huge amount of labor, eliminating the need to write basic things that are in almost all games.

In this article I will try to talk about how to publish my asset to the unity store, based on the experience of publishing four packages of various kinds. From experience, I can say that during the publication process there were much more pitfalls than we expected, one of the assets was rejected 10 times like this, citing various kinds of problems.

The following will describe the moments that are not in the official documentation on asset publishing, which are worth paying attention to:
1) When using Package Upload Tools, a package is collected and placed that is uploaded to the server. Since you can’t download your own asset from the preview of the asset page, it is best to use this package, which is created by the tools for downloading to the portal, for the final tests.
If your project uses other packages (let's say you integrated NGUI to work with the user interface), you should check that they are not included in the package that you send for verification. We had it so that even when selecting a folder with our product, the Plugins folder got into the final package. The simplest solution is to simply delete this folder before loading it into the asset.


2) You must check your asset for plagiarism. Especially if you use any of the assets already in the asset store. For example, when we did Complete 3D Game TemplateSome features were taken from another simpler starter kit. To avoid any plagiarism, we checked the entire code through MOSS (the most adequate and accurate tool for checking the similarity of two projects in the code. Developed by Stanford University and can logically analyze the code, it shows the same pieces of code, even if the similarities are veiled by renaming variables, fragmenting the code into functions and the like). An open GUI client walks through the network to compare the sources. You can drop 2 folders — with your code and 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. Both in compiled form and in the unity editor, and, preferably, on different versions of the unity. Many things may not work. For example, in the 4th unit there were all sorts of problems with the build for the browser — it was impossible to use non-redefined virtual functions in Coroutine — the build simply crashed.
In unit, when testing an asset, the latest version of Unity3d pro is used, you can focus on it. In the event that your project will not be assembled on any of the platforms, it may be refused to publish until you fix it.

four)If the project contains more than a couple of lines of code, it must have documentation. Even if you have all the code documented and have a readme that describes how to start working with the asset, you will often need to make a .pdf with a description of your systems and how they interact.
It will 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 saves a lot of time for asset users.


five)In case you use others in your package (For example, to create a starter kit, we integrated several at once into the asset: NGUI, HOTween, Highlighting System, EasySave2, in addition, many of them can be disabled by changing one define) then you should by making sure that you use the latest versions of all packages, as well as that you indicated their names and links to them in the Asset Store in the readme and documentation. You cannot use older versions of assets. Everything should work on the latest version of unity.
When developing a starter kit, we were guided by the experience of developing ordinary projects: it works, do not touch, remaining until the last moment on outdated versions of all assets and units. Later it took a considerable amount of time and effort to update all assets and fix bugs related to the update.

6) A small hack, in the case when the asset was rejected with a note that you need to redo something: as soon as you corrected everything, you can write in response to the message on the rejection of the asset that you corrected the error and ask to double-check. In this case, you do not have to wait long as during the first shipment - your package will be tested within a day or two.
In general, admins in the unit are extremely friendly and will gladly describe when prompted how to reproduce the error they found (the first time we could not find the platform-dependent error, we were told in detail how to get it. The second time, no matter how strange it may be) was, we asked how to reproduce the error and they could not reproduce it ourselves. As a result, we did not change anything and after the second test the assets were accepted).