Advice for a first time asset store publisher?

All,

I'm almost ready to publish my first asset store item, and wanted to get some feedback from the community. Comments are appreciated.

Licensing. The item I am planning to publish contains C# source code. Obviously, I don't want the code copy/pasted publicly online. Is the Unity EULA sufficient to prevent this, or should I include an additional source code license?

Changelogs and feature requests. I've noticed many publishers keep their changelogs here in the forums. What are the pros/cons of this approach vs. a dedicated website?

Positioning on the asset store. I'm planning to publish an FPS controller. It has been designed for high performance, tight game feel, and reliability on a variety of collision surfaces. It is not a complete project, but more of a solid project foundation. Which asset story category is appropriate for this type of asset?

Other comments for a publishing noob?

Thanks in advance.

 

Do a search for similar products and see what they do. If you are selling an FPS controller you are going to have to release the C# code because everyone is going to want to modify it for their games.

There is an interface in the store itself that handles the changelog, but if you are going to maintain the product, it is a good idea to have a customer service / change log thread here also.

Again, check out similar products. I think the category would be ´scripting/controllers´ but probably just search for UFPS and see where they are.

 

@Carve_Online Thanks for the reply.

I definitely intend to release the C#, but want to ensure that it is protected by an appropriate license.

Regarding the asset store category, I don't see Scripting/Controllers as a browse-able category. Is this something I can select when publishing, that isn't exposed in the store front?

 

(1) With regards to FPS category check out what the competition offers compared to your offering. The main FPS competition would be UFPS and Realistic FPS for a starting point. Also see what other assets they integrate with.

(2) Make sure it is easy to integrate with other third party assets. For example some people like to use third party input systems like Rewired, InControl, etc. So make it easy for users to switch to third party input systems without having to touch your code.

(3) This is also a very helpful thread.

https://forum.unity3d.com/threads/how-to-make-better-code-assets-for-the-asset-store.366355/

 

Sorry, I didn´t actually look. It seems like most of the FPS´s are going in Complete Projects / Templates or CP/Systems with a few in Scripting/cameras.

 

And for my two cents worth: Unlike some Vendors who simply disappear along with their support ( raedentertainment. Visual Actions), make sure you keep around to support your product and give refunds if necessary.
It's not a pleasant experience to find Unity still allowing sale of a app. when the Vendor has completely vanished but still taking the money!!
And all the very best for your asset. Hope it sells well.

 

Unity's EULA is sufficient. I recommend against adding your own license, since this will cause approval delays and confuse customers. Regardless of what your custom license would say, you'd get a continual stream of customers asking if it prohibits them from using your asset in their own projects.

You definitely need your own website, but also keep a thread updated here in the forum. Ideally your website will host a demo and support form, and maybe an issue tracker, FAQ, and/or forum. Cleverous's Deftly also has a Trello board that's a nice supplement.

If you've customized any of the project settings (Input Manager, Physics Manager, etc.), it's a Complete Project. Personally I find this to be a huge pain. What if I want to import two assets that each have their own custom Input Manager settings? I much prefer the import to leave the project settings untouched and provide a menu item to add settings, like Opsive's Third Person Controller does. PL Young posted a good article on how to modify the Input Manager here.

Some categories (Editor Extensions) license on a per-seat basis. The other categories are site licenses. With a per-seat license, a big studio may purchase several licenses instead of just one , but on the other hand the increased cost may deter them from buying it in the first place .

Keep in mind that, after your initial development is done, 50% of your time as a publisher will be spent on support: answering questions, recording tutorial videos, etc. Plan your time accordingly. Whenever you answer a question, put it in your FAQ so you don't have to rewrite it the next time someone asks. This also gives users the power to google the answer immediately instead of waiting for you to reply.

And definitely read the thread that longroadhwy posted above. A lot of devs contributed some really good advice there.

Good luck!

 

Thanks all. Great info here and in the posted links! A couple follow-up questions:

According to the latest usage stats, I should be targeting v 5.1, 5.2, 5.3, 5.4, and 5.5. The prospect of manually managing all the API flux across these versions is unpleasant to say the least. Is there a recommended best practice for managing warnings, deprecations, and API changes?

Regarding support, can anyone recommend an online system for managing updates, feedback, forums, customer service? UserEcho seems decent, but i've not used it.

 

(1) My suggestion would be to start with Unity 5.4.1 or later and not worry about the older versions of Unity. There always the infamous #ifdef mechanism for managing version/API changes.

https://docs.unity3d.com/Manual/PlatformDependentCompilation.html

(2) You should also consider how much time you want to spend maintaining multiple areas for your on-line presence. For example I would not setup my own forums but just use the Unity forums. Try to limit the amount of duplication you have in support locations. You should also get a dedicated e-mail account just for supporting your Unity asset. In your documentation make sure you are very specific about how your support works and what is the appropriate contact mechanism for support. Another thing you should be specific about what Unity versions should support specifically. Some expect full support of Unity beta and patch releases in addition the official Unity supported releases.

(3) Look at your favorite Unity assets and find out what tools they use for support and on-line presence and see if those make sense to for you.

(4) Also consider getting a private beta group together (it might just be one person) to test your product before you launch so you can get feedback on how the product works and to refine how you launch your product. And also fix any issues you have in your documentation. The goal is reduce future support calls.

(5) Make sure all of your e-mail addresses and website links actually work and are correctly documented in your user manual too.

 

Another option since you are launching a brand new product is just use the latest supported version of Unity at the time of launch. That will reduce your support to a specific Unity version right away.

Another potential support call is what Unity Editors are supported. The windows and MacOS platforms are expected but some developers use the experimental Unity Linux editor and might be expecting support too.

Make sure your documentation is available (without having to purchase) so developers look over what you are providing without have to purchase the product.

Also look closely at your competitors (e.g. UFPS and Realistic FPS) and be ready to answer what makes your product different. You should probably put something in writing so you can point future customers to it also. This is a a very common question. There are a couple Unity forum threads on the differences between UFPS and Realistic FPS. So expect to get that type of pre-sales question regularly since you are entered into the same "FPS" market. Pre-sales questions are support questions. Being able to reduce support calls is the goal.

You should also really look at integrations with other assets before launch too. If you can can get many of the common third party assets working with your product before launch the better. Inventory "type of assets" is one of the most common type of requests.

 

I second making Unity 5.4.1 the minimum. There were a lot of headache-inducing API changes between 5.1 and 5.4.0.

Since longroadhwy brought up on-line presence, make sure you have good presence of YouTube, Twitter, and Facebook so people can discover your asset through multiple channels.

All of longroadhwy's suggestions above are really good. Take them all to heart.

Also read Adam Goodrich's excellent entry on the Unity blog: Launching a successful product on the Asset Store.

 

Huge thanks again for all this great info. I've got some planning to do!