Sell Assets

Whether you're a programmer, game designer, texture artist or 3D modeler, you’re welcome to share your creations with everybody in the Unity developer community!

You can sell 3D models, editor extensions, audio and many other types of content. It’s easy – just submit your awesome creations to the Asset Store and we’ll take care of the rest. You can actually make enough money to fund your life and your game!

Once your submission is reviewed, you are free to set your own price for the asset. You’ll receive a 70% cut of each sale, which we pay out monthly or quarterly, depending on your selected payment method. Don’t forget to read the default Customer EULA that covers end-user use of the assets you sell.

Submitting your content to the Asset Store:

If you do not yet have an Unity Account, you can create one here.
Carefully read the Asset Store Provider Agreement for legal information, and the Submission Guidelines to learn about the submission process.
If you are not already registered as an Asset Store Publisher login with your Unity Account here and create an Asset Store Publisher Account.
Use the Publisher Administration Package Manager to create or update your package metadata and upload key images, screenshots, etc. ensuring that all the content you provide matches the specifications in the Asset Store Submission Guidelines.
Open the Asset Store inside Unity and download and import the Asset Store Toolsinto the project containing the content you want to submit to the Asset Store. Use the Asset Store Tools Package Upload tool to upload your content and associate it with the package you created.
Use the Publisher Administration Package Manager to submit your package. The Asset Store team will then review your submission!

Complete your publisher profile

Click on the “Info” tab at the top right corner of your Portal, next to the “Payout” tab.
Fill out all fields, including images, descriptions, and phone numbers.
Ensure your email in the email tabs for all contacts is your primary use email.
Input a valid website under the URL field with no spelling errors and access for users to contact you.
Website/online portfolio is required for being an Asset Store Publisher.
You must have 3 examples of current work related to your submissions.

After completing your profile, please read our Submission Guidelines and the Asset Store EULA for all requirements and legal restrictions regarding your submission content.

Uploading your asset in the editor

Go to the “Packages” tab on the top left corner of your Portal.
Create a new package and go to the Metadata section of your submission.
Type in the title for this new submission, save, and click “Go Back”.
Import the Asset Store Tools package into your Unity Editor, but don’t touch this folder after import. Do not place any of your content files in this folder.
Place all folders for submission in named top folder for clean folder structure so upload is easy.
Do not include any Unity Standard Assets in your submission.
Go through the Submission Guidelines of your chosen asset type (Audio/Models/Scripts/etc.) and check off requirements for approval.
After selecting the corresponding project to upload into, choose main/top folder for project.
Uploading will begin and when finished, a dialogue box will direct you back to the Publisher Portal in your web browser.

Submitting via the Publisher Portal

Open Publisher Portal via your web browser and click “Refresh” in top right corner to see your submission in the Unity Package section.
Fill out all fields in Summary section.
Be sure that you’ve assigned a numerical version number, edited the version changes (if it isn’t first release) and select a category.
Double check for the correct pricing of asset (requires Asset Store market research before submission).
Go to Metadata & Artwork section, click the link “Edit” under the Metadata.
Fill out all fields for Metadata; all fields are required.
Use HTML tagging for description text (see Submission Guidelines for tags).
Go to Key Images, Audio/Video, and Screenshots after completing Metadata tab and fill out all fields; all fields are required.
Ensure that your images are properly displayed by clicking on “Preview in Asset Store” in top right corner.
Click on the Unity Package Section.
Ensure that you select all the correct boxes/fields for what version of Unity your asset works for, what pipeline is required, and if there are any additional assets needed for your asset to work.
Submit links to any Unity Store Assets that are required for your package to work and hit save and return to the main portal page.
Make sure you read the information in the (?) next to the Auto-publish box before checking or unchecking it.
Click on the “I have read the Submission Guidelines…” box to verify your asset has been uploaded with the knowledge required for acceptance.

By clicking the last box, you understand that not following the Submission Guidelines and Asset Store EULA increases the likelihood that your submission will be declined.

Get help

Join the community on the Publisher Forums after your first asset has been accepted.
Contact Unity Support if your package has issues uploading.
Have a question? Maybe we answered it already in our FAQ.
For a refresher on this process, check out our Unity Manual on Publishing.
Save these two links to your Bookmarks tab for easy access: Submission Guidelines, Asset Store EULA.

Submission Guidelines

Last updated: Aug 10, 2016.

Introduction & Overview

We're glad you've decided to submit your work to the Unity Asset Store! The goal of this guide is to give new and existing publishers a comprehensive understanding of what is expected of packages that are submitted to the Unity Asset Store. Published products are intended to be professional and useable projects for Unity’s development community. In order to provide content with consistent standards, our curation team will hold your incoming submissions to these guidelines during your product’s review. You will find it worthwhile to read these guidelines thoroughly since it will save you time and in the end, possibly lead to a more successful product.

You will always be notified of your rejection if your project does not uphold these standards. If there are corrections that need to be made to your product, you will be provided with as specific as possible reasoning as to why your submission was rejected. Any issues mentioned in your rejection will need to be fixed before resubmitting your product. While our review process has the best intentions of catching and informing you of all reasons why your product has been rejected, more issues may be found in your product even if your resubmission has addressed all the initial issues. If needed, you will be required to address issues throughout multiple resubmissions before your product is in a state that is ready to be published on the Unity Asset Store. In rare instances, even if your submission has gone through multiple resubmissions, some products may be deemed unfit for the Unity Asset Store.

This is a living document that will be periodically updated and is meant to oversee the broad cases of content that are brought to the Asset Store. If specifics of your submission are not explicitly covered by these rules, the decision of how your submission will be handled ultimately comes down to Unity’s Content Curation Team during your product’s review. The beauty of our development community is that we continuously see projects that we never expected would be developed. If there are specific qualities of your project related to unique or emerging technologies that you do not see in these guidelines, please contact us at [email protected] to discuss any questions or concerns.

1. Restricted Content

1.1 Legal Restrictions

1.1.a Submissions that include content you do not hold the license to resell or redistribute will be rejected.
1.1.b Submissions that include content that is not allowed to be resold, not allowed to be utilized in commercial products, or is required to remain open-sourced due to its EULA will be rejected.
1.1.c Certain asset file types are protected by proprietary licenses and may not be applicable for resale such as models generated from Speedtree or Mixamo’s Fuse. Submissions including these types of assets that are not allowed to be resold due to their EULA will be be rejected.
1.1.d Submissions that include any content from another Asset Store package is a violation of the Asset Store Provider Agreement and will be rejected.
1.1.e Unless expressly forbidden, any products that are developed and published under the Unity Technologies account on the Asset Store are allowed to be incorporated into submitted products for demonstration purposes. To avoid needless file size and clutter, we require that you only include Unity Technology content that is directly being utilized in your demos.
1.1.f To avoid legal conflicts, you may be asked to remove any third party libraries or SDKs that are included in your project but not directly incorporated into your product. Rather than being included directly with your project, your users will need to be informed where to download the libraries/SDKs through your documentation.
1.1.g Submissions must not have unauthorized trademarked names or branded content being referenced anywhere in your package. This includes in images, names, description text, nor in content/file names. Any brands or names that hold active trademarks related to your product in public databases such as US Patent and Trademark Office website, will be rejected.
1.1.h References of the Unity brand must adhere to our naming guidelines. I.e. Unity Technologies, Unity, Unity Personal, Unity Plus, Unity Pro, and Unity Enterprise. Any reference to Unity3D, Unity Free, Unity Indie, etc. will be edited or rejected.

1.1.1 Licenses in your Products

1.1.1.a All content published on the Asset Store is provided under the Asset Store EULA. To maintain a consistent experience for our users, products are not allowed to be sold under any unique licenses.
1.1.1.b Submissions of free products that you, the submitter, have developed and are providing open sourced through other sites, will be allowed to include a EULA. As long as that content meets all other applicable requirements of this doc, is perpetually free and that EULA is compatible with our own. The compatible licenses that we mainly allow are MIT, BSD 3-Clause, and Apache. Any licenses that require a product to maintain open-sourced or limit usability in commercial products such as GNU/GPL Mozilla Public License, or any Creative Commons that requires attribution will not be allowed. Please reach out to [email protected] if you would like clarification about any specific license before submitting.
1.1.1.c Any third party libraries/sdks that are incorporated into your product that are provided under a license will be required to have a license text file that clearly states which third party files are being included and from what source.
1.1.1.d Any fonts with dependent licenses being included in your submission must be compatible with our EULA and include a license file detailing the font that it is covering.

1.2 General

1.2.a While it is understandable that some projects are designed around open source libraries or frameworks, submissions to the Asset Store should have a majority of their content developed directly by the publisher. If we believe a package is a compilation of found content/products or the direct result of public tutorials, it will likely be rejected.
1.2.b Any project or content submissions we feel are already excessively available to our development community may be held to higher quality standards during review. In extreme circumstances, if your content does not realistically offer anything unique, your submission may be rejected solely on these grounds.
1.2.c No aspect of a package will be allowed to promote or redirect users to other marketplaces or digital stores.
1.2.d Packages can not throw any generic errors after setup is complete. Any errors present in your projects should only be those that are from caught and handled exceptions.
1.2.e Submissions that do not perform and function as advertised will be rejected.
1.2.f Submissions that include executables will be rejected. For more information about submitting Applications, please see 4.6 for more information.

1.3 Versions of Unity

1.3.a Submissions are tested on the most recent publicly available version of Unity. Your project will be required to meet all of our standards in that version of Unity or whichever version(s) your content is explicitly stated to be intended for.
1.3.b The version of Unity used to upload your package determines the version of Unity needed by customers to download or buy your package. We recommend that you upload your package from the earliest version of Unity that you know works with your package. You can download and install an earlier version of Unity from the Unity Download Archive.
1.3.c If you are unable to make your package compatible across Unity versions, you can choose to upload your package using multiple versions of Unity.

1.3.1 Beta

1.3.1.a Packages may not be submitted exclusively with beta versions of Unity unless they are specifically designed around features in that specific Unity beta version.
1.3.1.b Packages that are submitted with any beta version of Unity will be required to resubmit their product when a beta or release candidate is officially published to accommodate any changes or fixes.
1.3.1.c Packages submitted in a beta version of Unity must explicitly state in their description text which versions are supported.

1.4 Services

1.4.a If you are an Online Service, such as a monetization service, ad-network, back-end hosting service, analytics system or other service where a variable amount of money changes hands after the user downloads your SDK or plugin, you may not upload your SDK or plugin. Services must register as an Asset Store Service in order to distribute on the Unity Asset Store. Services can register by contacting Macy Mills. Service submissions that include non-proprietary content will be rejected unless non-proprietary content is a registered Asset Store Service or is under an open-source license that we support.

1.5 Inappropriate Content

1.5.a Any content that we deem to be defamatory or libelous will be rejected.
1.5.b Packages that we believe to be marketed or presented with the intention of being overtly violent, gruesome or sexualized will be rejected.
1.5.c Submissions that display targeted hatred of any kind (Race/Religion/Gender/Identity/etc.) will be rejected.
1.5.d Base characters or Avatars are allowed to be completely nude under the condition that they are marketed and presented tastefully.
1.5.e Any models with detailed genitalia or internal anatomy will be rejected.

1.6 Malicious Content

1.6.a Submissions with functionality implemented to track or collect a user’s data will be rejected.
1.6.b Submissions that attempt to install any programs/viruses onto a user's computer or run any background services will be rejected.

1.7 Restrictive Content

1.7.a Submissions that include any DRM or functionality in place that restrict users from directly using content or features to their full extent will be rejected.
1.7.b Submissions that require a user to register, sign up or pay extra costs for a package to fully function will be rejected.
1.7.c Packages that include watermarks or otherwise obstruct the use of the product will be rejected.
1.7.d Packages that are only functional for a set amount of time or uses will be rejected.
1.7.e Submissions that have any artificial limits implemented on functionality or usability will be rejected.

1.8 Lite Products

1.8.a Any submissions that are trial or restrictive versions of products will be rejected. To familiarize users with your product, you may provide a ‘lite’ (smaller/cheaper/indie/free) version of your package. Lite and Free versions must not have limitations implemented on the functionality of your product’s features. Lite packages should only have a reduced set of features compared to your full product.

2. Preparing Your Product

2.1 Publisher Information

2.1.a Publisher information must be included and is expected to meet our standards. Any missing information will lead to your submissions being rejected. Required information includes Name, URL, Description Text, Publisher Key Image, Customer Support Contact, Business Contact, and Technical Contact.
2.1.b Publisher names must not violate any trademarks or brands.
2.1.c You may not insinuate from your publisher profile that you are an individual or public figure that you have no affiliation with.
2.1.d You may not insinuate from you publisher profile that you are affiliated with a company or organization that you have no connection with.
2.1.e Publisher descriptions must provide details about who you are as a professional and include information about your skills or specialties.
2.1.f Publishers must have and maintain an active website that contains examples of relevant work and skill sets. Publisher websites should be built specifically as a portfolio page, or utilize professional 3rd-party service such as Unity Connect, LinkedIn, ArtStation, etc. If we believe the website does not adequately represent you as a professional, we will reject your submissions.
2.1.g Publisher website pages are not allowed to be included as a wrapped link.
2.1.h Publishers must provide and maintain an active customer support email.

2.2 Product Titles

2.2.a Titles must be unique from any other live package on the Asset Store. Duplicate names will not be allowed.
2.2.b Titles should be a reasonably length and not exceed the area provided.
2.2.c Titles should not include your publisher name.
2.2.d Titles should not include extended descriptions of your packages.
2.2.e Titles should not convey that your package is affiliated with any company/product that you are not directly associated with.
2.2.f Each word in your title should lead with a capital letter followed by lowercase letters unless referencing a brand that does not conform to that structure.
2.2.g Titles should only use spaces to separate words without punctuation, unless conforming to an established brand.
2.2.h For legal and branding purposes, any packages starting with a brand name or inferring an affiliation with a brand will be rejected. I.e. ‘Tools for Unity’ is acceptable. ‘Unity Tools’ will be rejected.

2.3 Description Text

2.3.a Our review team may edit any metadata of your package that does not conform to our rules or to correct spelling/grammar. This includes your package’s title, category, description text and keywords. We will never edit your package’s price without your knowledge.
2.3.b Description text should be thorough and cover all important aspects of your product.
2.3.c Description text for art assets should list out the number of unique assets included in your project. We also ask you provide detailed information on the average polygon count, texture size, and types of texture maps included for each asset.
2.3.d Description text for code assets should list out all key features of your product.
2.3.e All description text needs to be formatted properly with html tags. Only use  , <a></a>hyperlinks, , .Packages using ,  or other unsupported tags will be edited or may be rejected.
2.3.f All descriptions must be in English and have proper spelling/grammar. Small edits may be made by our review team but excessive situations will result in your submission being rejected.
2.3.g An English version of your description text is required but localized versions for other languages are allowed.
2.3.h All hyperlinks must be formatted correctly <a href="/%E2%80%9Dwebsite%E2%80%9D">text</a> and lead to active, non-malicious websites.
2.3.i Hyperlinks text should be adequately relevant to the link it leads to.
2.3.j Hyperlinks should only link to external sites, not direct downloads.
2.3.k Descriptions should not reference IP’s, brands, or trademarks that are similar to your product that you are not affiliated with.
2.3.l No aspect of your description text should promote or redirect users to other marketplaces or digital stores.
2.3.m Your description should only pertain to the content of the package. Your description text should not promote any other products unless they are an extension of your product, directly compatible with your product, or required for your product to function.
2.3.n Submissions promoting any “special offers” (free tutorial, free guidebooks, try before you buy, etc) will be rejected, as there is no system to oversee that offers are being responsibly fulfilled.

2.4 Key Images

2.4.a Having high-quality key images improves your packages marketing presence and is a substantial portion of being successful on the Asset Store. Information about on creating clean and professional key images can be found from our Asset Store Promotional Asset Guidelines
2.4.b Key images that are not a clear representation of your content may be rejected.
2.4.c Key images should not be an unedited screen capture of your content inside the Unity editor or a digital photograph of your computer monitor.
2.4.d Key images that only have plain text will be rejected.
2.4.e Key images should not include excessive description text.
2.4.f Key image may not include any sale related graphics or banners.
2.4.g Including Icons of third party content that your product is compatible with will not be allowed if that logo’s brand guidelines are being violated or if any direct affiliation between your product and the third party content is being insinuated.
2.4.h Key images that attempt to recreate any official Asset Store sale or promotional graphics will be rejected.

2.5 Category

2.5.a Your package should be in the category that is most closely related to your product.

2.6 Keywords

2.6.a Keywords should be relevant to your package.

2.7 Pricing

2.7.a You are able to price your package at whatever price point you like. If we feel your content may be better priced in a different range, we will let you know. We suggest examining the pricing of similar assets on the store and following their example. Do not be afraid to ask for a high price for your package. It represents your hard work! Interestingly, the top-selling packages, in terms of quantity sold, are all over $50!
2.7.b Products that are hosted on other stores/marketplaces must match the price of your project on the Asset Store. Attempting to grossly undercut pricing of similar products is actively discouraged.

2.7.1 Personal Sales

Providing packages at a sale price is allowed but under the following circumstances. Failure to follow these guidelines may result in your product being disqualified from future official sale or promotional opportunities.
2.7.1.a Personal sales can not last longer than a two week period. Failure to restore your original price within two weeks may result in any mention of a sale being removed from your products details without notice.
2.7.1.b Sale periods should be separated by at least 2 months.
2.7.1.c Details of your sale must be provided in your description text. Sale period and regular price must be mentioned.
2.7.1.d You are not allowed to include any sale related graphics throughout your package’s imagery.
2.7.1.e You may not promote your product as being included in any sales or features hosted by Unity Technologies that you are not actually included in.
2.7.1.f To be considered for an official Unity organized sale, your package must maintain a consistent price for 2 months. A price increase due to a large update will not disqualify you from being included in a sale.
2.7.1.g After being included in an official sale, your package’s price must not be reduced for 6 weeks.

3. Preparing your Content

3.1 Content Organization

3.1.a In order to keep the process of importing packages as clean as possible, packages should be nested under a folder with either your publisher name, or package name as the title.
3.1.b Assets should be properly sorted into folders with English titles depending on their type (Mesh/Script/Material/etc). Packages should not have a range of file types included under a singular folder.
3.1.c If your submission requires specific folders to be in the project’s root, such as a “Plugin” or “Editor” folder, you will need to include instructions in your documentation telling users to place these folders in the proper location manually. See the Unity documentation for Special Folders and Script Compilation Order for more information.
3.1.d To help users navigate your package and avoid unnecessary clutter, all duplicate, unused or redundant files must be removed from your project before submitting.
3.1.e To avoid inconsistencies during importing, Do not include “Standard Assets” folder in your submission. If you have a demo scene that utilizes any “Standard Assets”, include documentation as to how you setup your scene and allow for the user to import the “Standard Assets” themselves.
3.1.f Content should not be included under any folder named ‘AssetStoreTools’ or any variation of that name as that folder is automatically stripped while uploading your content.
3.1.g Your files must follow a consistent naming convention throughout your submission.
3.1.h Asset file names need to represent the content they are providing.
3.1.i Any incremental files should be appropriately named with proper number padding. I.e ‘asset_01’ if you have over 10 assets, instead of ‘asset_1’.
3.1.j File names should not be excessively lengthened with descriptors such as ‘High Quality’, ‘Low Poly’, ‘PBR’ etc. All details of your product should be left to your description text or keywords.

An example of what we would expect for organized and properly named folders, using “Unity Technologies” as the publisher name.

3.2 Documentation

3.2.a All projects submitted to the Unity Asset Store that require information on how to set up and properly utilize your project, are required to have local documentation.
3.2.b Documentation must be in .txt, .pdf, .html or .rtf file types.
3.2.c Documentation should be thorough and encompass all aspects of your project. If after reading through your documentation, there is not a clear understanding of how to use your product, you may be rejected.
3.2.d You are allowed to maintain more extensive documentation of your product online, but your documentation included in your project must include enough instruction for the user to understand the basic functionalities of your submission. Links to any online documentation must be mentioned at the beginning of your local documentation.
3.2.e Documentation must include a support email for users to contact you.
3.2.f Documentation must be in English and free from spelling/grammatical errors. You may include additional documentation that is localized in other languages alongside the required English documentation.
3.2.g Any video documentation or tutorials should be uploaded online (Youtube, Vimeo, etc.) and not included in your projects. A link to your video should be mentioned in your written documentation.
3.2.h Shader documentation must explain each shader property. Do not assume that the property names alone are enough for the user to figure out what it does.
3.2.i Documentation for server-based plugins (PHP, SQL, etc.) should assume users have a basic understanding of server hosting and setup. Your documentation only needs to be specific to setting up your plugin and how to use it.

3.3 Demo Scenes

3.3.a Most submissions should include a demo scene. If your product has content to show off, they should be displayed in a demo scene.
3.3.b Projects that include a collection of assets must include a scene that showcases all of their assets laid out in a grid or continuous line.

3.4 Compressed Files

3.4.a Submissions with .Unitypackage files solely to obscure or compress content will be rejected.
3.4.b Submissions that include set up preferences, settings or supplemental files for another Asset Store product must be nested in a .unitypackage file.
3.4.c .zip or .rar files will only be accepted if they are compressing files that do not natively function in the Unity editor. (I.e. Blender, HTML Documentation, Visual Studio Projects, etc.)

3.5 File Size

3.5.a Please Note: Users may experience problems importing large packages. Make sure all of your assets are as optimized as they can be or if applicable, your submission should be split into multiple packages to help prevent issue with users downloading your content.
3.5.b Due to technical restraints, submissions over 4GB will be rejected. Packages over 2GB that show instability issues or unoptimized qualities may be rejected.

4. Content Specific Guidelines

4.1 Art Content

4.1.a Packages that do not hold a consistent artistic style may be rejected.
4.1.b Content submitted should display a certain degree of professional design and construction. Any assets that we do not believe could realistically be utilized in a development pipeline may be rejected.
4.1.c Mesh assets should be submitted as either .FBX or .OBJ.
4.1.d All visible meshes are required to have a paired set of textures and materials assigned to them.
4.1.e Each mesh should have a corresponding prefab set up with all variations of the texture/mesh/material that you are providing.
4.1.f Submissions of untextured meshes solely for prototyping purposes will be rejected.
4.1.g Large environments or scenes must be broken up into individual meshes. Submissions with an entire environments being included as one object will be rejected.
4.1.h Prefabs must have their position/rotation set to zero upon import, and should have their scale set to 1.
4.1.i All Meshes must have a local pivot point positioned at the bottom center of the object, consistently in a corner of any modular objects, or where the object would logically pivot/rotate/animate.
4.1.j All meshes should be rotated to have their positive Z facing forward.
4.1.k Meshes need to be at a 1 Unit : 1 Meter scale.
4.1.l Photoscanned data must be retopologized and optimized to a state that users could reasonably edit if needed before submission. Any meshes that are the direct result of scans will be rejected.
4.1.m Assets that have an unreasonably excessive mesh density will be rejected.
4.1.n Assets that appear to have their UV’s automatically unwrapped will be rejected.
4.1.o Mesh prefabs need to be set up with a collider component that fits your mesh.

4.1.1 Rigs

4.1.1.a Character models must be weighted to an accompanying rig. The rig can either be set up with Unity’s Mecanim system or can include your own animations.
4.1.1.b When set to animations, rigs should not show any obvious creases unusual deformations.

4.1.2 Animations

4.1.2.a Bipedal animations should be ready to use with Unity’s default “Humanoid” avatar.
4.1.2.b Projects of non-Bipedal animations need to include a demonstration mesh with a well documented rig breakdown so that users can create meshes designed for the animations.
4.1.2.c Animations need to be sliced and named prior to submission. Submissions with a single long animation clip will be rejected.
4.1.2.d Submissions including raw mocap data will be rejected. Any animations that are developed from mocap data need to be cleaned up into sliced and useable animations.
4.1.2.e Animations should should have fluid movement without any jarring transitions.

4.1.3 Textures & Materials

4.1.3.a Submissions that include .jpgs files will be rejected. Texture files need to be in a lossless compression format such as PNG, TGA, or PSD.
4.1.3.b Any package that is submitted and claims to be PBR, or that is using our Standard Shaders must include at least an albedo,normal,metallic (or specular) and smoothness texture map. For more information see our blog post on PBR in Unity.
4.1.3.c Tileable textures must tile without any seams or obvious edges.
4.1.3.d Maps with an alpha channel need to be paired with a material that can read said alpha.
4.1.3.e All imported materials that aren’t being used in your final product must be removed before submission.
4.1.3.f Normal maps need to be marked as a “Normal Map” in the import settings.
4.1.3.g Content intended to be run on mobile or lower-end hardware should have atlased textures in order to reduce performance impact.
4.1.3.h Assets should not have an excessive number of materials assigned to them.
4.1.3.i .SBSAR and other procedural materials need documentation or a demo scene showcasing the parameters included.

4.1.4 Sprites

4.1.4.a All sprite sheets must be imported with the “Sprite” import settings.
4.1.4.b Sprites need to be properly sliced and named using the import settings.
4.1.4.c Sprite animations need to be spliced, named and set up as proper clips before submission.

4.1.5 Gui Packs

4.1.5.a Submissions of GUI packs must include a functional demonstration scene that showcases all of the components being useable.
4.1.5.b GUI components need to have their elements separated and named either before import or through our sprite editor settings.

4.2 Particle Systems

4.2.a Particle systems should be saved as a prefab for customers to easily drag and drop into their scene.
4.2.b With the release of Unity 5.4, the Legacy Particle System, introduced in Unity 1.0, is planned to be removed from Unity. This includes the "Ellipsoid Particle Emitter", "Mesh Particle Emitter", "Particle Animator", "Particle Renderer" components, and associated code. At this time, any new submissions using the legacy particle system with be rejected and expected to utilize the newer Particle System (codename 'Shuriken'). Until the official removal of the legacy particle system, updates to packages will not be required, but strongly encouraged to utilize the Shuriken particle system.

4.3 Scripts

4.3.a Scripts should not throw any compiler or generic errors. Any potential errors must be properly caught and presented to the user through the debug log.
4.3.b All submitted code must be commented and readable with no spelling/grammatical errors.
4.3.c Code comments must be in English. You may include code comments in other languages alongside the required English comments.
4.3.d Commented code is not an alternative to proper documentation.
4.3.e Functions and variables should be named appropriately.

4.3.1 Editor Extensions

4.3.1.a Editor extension file menus must be placed under an existing entry. If no existing menus are a good fit, you can place it under a custom menu titled "Tools". This keeps the editor clean and organized.

Example of an ideally nested Editor Extension

4.3.1.b Undo operations must be supported. Refer to the Unity documentation for information about Undo Support
4.3.1.c We allow unique windows to be created for practical support or informative purposes. Submissions with any unique windows that we feel are created for spamming purposes or distract the user’s workflow may be rejected.

4.3.2 Server-Based Plugins

4.3.2.a Submissions that are utilizing a Server-Based Plugin must automatically populate any new databases with necessary tables.

4.4 Complete & Template Projects

4.4.a Complete and Template Projects should be designed as instructional, tutorial or framework products.
4.4.b Complete project’s documentation must include in-depth information about how the project is designed and how users can edit and expand on your project. Your documentation must explain more than just how to run the project.
4.4.c If we believe a package is a compilation of found content/products or the direct result of public tutorials, it will likely be rejected.
4.4.d If we believe a package has been designed with the sole purpose to directly recreate a popular game’s design, art style and aesthetic, it will likely be rejected. Products should offer some unique aspect to our development community and should not violate any copyright protections.
4.4.e If you have published a game and are interested in releasing/selling your source project, please keep in mind that purchasers of your product are technically allowed to directly build and sell that project commercially. To avoid users impacting your game’s success by directly submitting your game to marketplaces such as Google Play, App Store, Steam, etc, you should maybe consider replacing your art with professional but generic placeholders.
4.4.f The Project Settings of your project will be automatically included with any submission being uploaded in the “Complete Projects” category or subcategories. Users will receive a notification that their Project Settings will be replace when importing your project.

4.5 Audio

4.5.a All audio asset submissions must link to a preview web server or service such as SoundCloud™.
4.5.b Audio files must be normalized before submitting.
4.5.c Audio files must play properly inside the Unity inspector.
4.5.d Submissions of audio collections must maintain a consistent format, naming convention, and quality.
4.5.e Submissions must only include supported Unity audio formats. For more information on supported formats, please see Unity's Audio File Documentation

4.6 Applications

4.6.a Until further notice, the Asset Store is not accepting any Applications. (For now all content on the Asset Store is required to operate within the Unity Editor and we are not taking third party tools/applications. If you are interested in providing your product that is an application on the Asset Store, please contact [email protected])

5. Outro/Support message

We appreciate you reading through these guidelines in their entirety! If you have an issue with a specific package of yours that has been either accepted or declined, reply directly to that email and you will be able to get in contact with the team member who vetted your package. If you are having any other issues regarding your submission, package, or publisher account, please email [email protected] to open a support ticket. Please include as much information as possible in your email, so that our support team can better help resolve your issues.

https://developer.cloud.unity3d.com/projects/

Welcome!

Create New Project

You've arrived at the Unity Developer portal project listing page... but you don't seem to have any projects yet! Click the 'Create New Project' button to get started.

Where can I learn more about Unity services?

The main Unity Services page on Unity3d.com
Setting up Cloud Build
Setting up Collaborate
How to use Unity Analytics
Monetize your game with Unity Ads
Check out the Unity Multiplayer service
Tracking crashes in your game with Crashes & Exceptions

https://publisher.assetstore.unity3d.com/sales.html

Publisher Administration

ACTION REQUIRED: To receive a payment in mid-March (if you’re eligible for one), please do the following Getting Started Guide before February 28. For more information, see our FAQ. More details here

Set max discount for your assets here

No Access

You are not registered as an Asset Store Publisher.

How to become a publisher and submit content.

Create a new Unity Asset Store Publisher.

https://support.unity3d.com/hc/en-us/articles/206533495-Am-I-able-to-offer-a-discount-on-my-own-Assets-

https://publisher.assetstore.unity3d.com/create.html