Directives de soumission

Le but de ce guide est de donner aux nouveaux éditeurs une compréhension complète de ce que l'on attend des packages qui sont soumis sur l'Unity Asset Store. Les produits publiés sont destinés à être des projets professionnels et utilisables pour la communauté de développement d'Unity. Afin d'offrir un contenu conforme aux normes, notre équipe de conservation tiendra vos soumissions reçues à ces lignes directrices pendant l'examen de votre produit. Vous verrez qu'il vaut la peine de lire ces lignes directrices minutieusement, car cela vous fera gagner du temps et à la fin, peut-être conduire à un produit plus réussi.

Vous serez toujours informé de votre rejet si votre projet ne respecte pas ces normes. Si des corrections doivent être apportées à votre produit, vous recevrez un raisonnement aussi précis que possible expliquant pourquoi votre soumission a été rejetée. Tout problème mentionné dans votre refus devra être corrigé avant de soumettre à nouveau votre produit. Bien que notre processus d'examen ait la meilleure intention de vous informer de toutes les raisons pour lesquelles votre produit a été rejeté, d'autres problèmes peuvent se retrouver dans votre produit, même si votre nouvelle présentation a abordé toutes les questions initiales. Si nécessaire, vous devrez résoudre les problèmes lors de plusieurs soumissions à nouveau avant que votre produit ne soit dans un état prêt à être publié sur l'Unity Asset Store. Dans de rares cas, même si votre soumission a fait l'objet de plusieurs soumissions, certains produits peuvent être considérés comme impropres pour l'Unity Asset Store.

Il s'agit d'un document évolutif qui sera périodiquement mis à jour et destiné à superviser les cas généraux de contenu qui sont apportés à l'Asset Store. Si les spécificités de votre soumission ne sont pas explicitement couvertes par ces règles, la décision quant à la manière dont votre soumission sera traitée revient finalement à l'équipe de gestion du contenu d'Unity lors de l'examen de votre produit. La beauté de notre communauté de développement est que nous voyons continuellement des projets que nous n'aurions jamais imaginés être développés. S'il existe des qualités spécifiques de votre projet liées à des technologies uniques ou émergentes que vous ne voyez pas dans ces directives, veuillez nous contacter à AssetStore@unity3d.com pour discuter de vos questions ou préoccupations.

1. Contenu restreint

1.1 Restrictions légales

  1. 1.1.a - Les soumissions qui incluent du contenu pour lequel vous ne détenez pas la licence de revente ou de redistribution seront rejetées.
  2. 1.1.b - Les soumissions qui incluent du contenu qui ne peut pas être revendu, qui ne peuvent pas être utilisées dans des produits commerciaux, ou qui doivent rester ouvertes en raison de son CLUF seront rejetées.
  3. 1.1.c - Certains types de fichiers d'assets sont protégés par des licences propriétaires et peuvent ne pas être applicables à la revente, tels que les modèles générés à partir de Speedtree ou Mixamo’s Fuse. Les soumissions incluant ces types d'assets qui ne peuvent pas être revendus en raison de leur CLUF seront rejetées.
  4. 1.1.d - Les soumissions qui incluent du contenu provenant d'un autre Asset Store package enfreignent l'Asset Store Provider Agreement et seront rejetées.
  5. 1.1.e - Sauf interdiction expresse, tous les produits développés et publiés sous le compte Unity Technologies sur l'Asset Store peuvent être incorporés dans des produits soumis à des fins de démonstration. Afin d'éviter la taille de fichier inutile et l'encombrement, nous vous demandons d'inclure uniquement le contenu de Unity Technology qui est directement utilisé dans vos démos.
  6. 1.1.f - Pour éviter les conflits juridiques, vous pouvez être invité à supprimer les bibliothèques ou les kits de développement tiers qui sont inclus dans votre projet mais qui ne sont pas directement intégrés à votre produit. Plutôt que d'être inclus directement dans votre projet, vos utilisateurs devront savoir où télécharger les bibliothèques / SDK via votre documentation.
  7. 1.1.g - Les soumissions ne doivent pas contenir de noms de marque non autorisés ou de contenu de marque référencé dans votre package. Cela inclut les images, les noms, le texte descriptif, ni les noms de contenu / fichier. Toutes les marques ou noms qui détiennent des marques commerciales associées à votre produit dans des bases de données publiques, telles que le site web US Patent and Trademark Office, seront rejetés.
  8. 1.1.h - Les références de la marque Unity doivent respecter nos consignes de dénomination. C'est à dire. Unity Technologies, Unity, Unity Personal, Unity Plus, Unity Pro et Unity Enterprise. Toute référence à Unity3D, Unity Free, Unity Indie, etc. sera éditée ou rejetée.

1.1.1 Licences dans vos produits

  1. 1.1.1.a - Tout le contenu publié sur l'Asset Store est fourni dans le CLUF de l'Asset Store. Pour maintenir une expérience cohérente pour nos utilisateurs, les produits ne sont pas autorisés à être vendus sous des licences uniques.
  2. 1.1.1.b - Les soumissions de produits gratuits que vous, l'expéditeur, avez développées et qui fournissent des sources ouvertes via d'autres sites, seront autorisées à inclure un CLUF. Tant que ce contenu répond à toutes les autres exigences applicables de ce document, il est perpétuellement gratuit et ce CLUF est compatible avec le nôtre. Les licences compatibles que nous autorisons principalement sont MIT, BSD 3-Clause et Apache. Toutes les licences qui exigent un produit pour maintenir une source ouverte ou limiter l'utilisabilité dans des produits commerciaux tels que la licence publique GNU/GPL Mozilla, ou tout Creative Commons nécessitant une attribution ne seront pas autorisées. Veuillez contacter Support@unity3d.com si vous souhaitez obtenir des éclaircissements sur une licence spécifique avant de la soumettre.
  3. 1.1.1.c - Toutes les bibliothèques / sdks tierces intégrées à votre produit qui sont fournies sous licence doivent disposer d'un fichier texte de licence indiquant clairement quels fichiers tiers sont inclus et de quelle source.
  4. 1.1.1.d - Toutes les polices avec des licences dépendantes incluses dans votre soumission doivent être compatibles avec notre CLUF et inclure un fichier de licence détaillant la police qu'il couvre.
  5. 1.1.1.e - L'inclusion d'une licence qui répond à tous les autres critères doit être incluse dans votre soumission et nommée "licence. txt". Ceci ouvrira une fenêtre d'accord avant l'achat de votre produit pour informer tous les utilisateurs de la licence.

1.2 Général

  1. 1.2.a - Bien qu'il soit compréhensible que certains projets soient conçus autour de bibliothèques ou de frameworks open source, les contenus soumis à l'Asset Store doivent avoir une majorité de leur contenu développé directement par l'éditeur. Si nous pensons qu'un package est une compilation de contenu / produits trouvés ou le résultat direct de tutoriels publics, il sera probablement rejeté.
  2. 1.2.b - Tout projet ou contenu que nous considérons déjà excessivement disponible pour notre communauté de développement peut être tenu à des normes de qualité plus élevées pendant l'examen. Dans des circonstances extrêmes, si votre contenu ne propose pas quelque chose d'unique, votre soumission peut être rejetée uniquement pour ces raisons.
  3. 1.2.c - Aucun aspect d'un package ne sera autorisé à promouvoir ou rediriger les utilisateurs vers d'autres marchés ou magasins numériques.
  4. 1.2.d - Les packages ne peuvent pas générer d'erreurs génériques une fois l'installation terminée. Toutes les erreurs présentes dans vos projets doivent uniquement être celles qui proviennent d'exceptions interceptées et gérées.
  5. 1.2.e - Les soumissions qui ne fonctionnent pas comme annoncé seront rejetées.
  6. 1.2.f - Les soumissions qui incluent des exécutables seront rejetées. Pour de plus amples renseignements sur la présentation des demandes, veuillez consulter la section 4.6.

1.3 Versions de Unity

  1. 1.3.a - Les soumissions sont testées sur la version la plus récente d'Unity accessible au public. Votre projet devra répondre à toutes nos normes dans cette version d'Unity ou à la ou aux versions pour lesquelles votre contenu est explicitement indiqué.
  2. 1.3.b - La version d'Unity utilisée pour télécharger votre package détermine la version de Unity dont les clients ont besoin pour télécharger ou acheter votre package. Nous vous recommandons de télécharger votre package à partir de la version la plus ancienne d'Unity qui fonctionne avec votre package. Vous pouvez télécharger et installer une version antérieure d'Unity à partir de l'archive de téléchargement d'Unity.
  3. 1.3.c - Si vous ne parvenez pas à rendre votre package compatible avec les versions Unity, vous pouvez choisir de télécharger votre package à l'aide de plusieurs versions de Unity.

1.3.1 Beta

  1. 1.3.1.a - Les packages ne peuvent pas être soumis exclusivement avec les versions bêta d'Unity à moins qu'ils ne soient spécifiquement conçus pour les fonctionnalités de cette version bêta spécifique d'Unity.
  2. 1.3.1.b - Les packages soumis avec une version bêta d'Unity devront soumettre à nouveau leur produit lorsqu'une version bêta ou une version finale est officiellement publiée pour prendre en charge les modifications ou les correctifs.
  3. 1.3.1.c - Les packages soumis dans une version bêta d'Unity doivent indiquer explicitement dans leur texte de description quelles versions sont supportées.

1.4 Services

  1. 1.4.a - Si vous êtes un service en ligne, tel qu'un service de monétisation, un réseau publicitaire, un service d'hébergement back-end, un système d'analyse ou tout autre service dans lequel un montant d'argent variable change de main après que l'utilisateur a téléchargé votre SDK ou plugin, vous ne pouvez pas télécharger votre SDK ou plugin. Les services doivent s'inscrire en tant que Asset Store Service pour pouvoir être distribués sur l'Unity Asset Store. Les services peuvent s'inscrire en contactant Ross Avner. Les soumissions de service qui incluent du contenu non exclusif seront rejetées à moins que le contenu non exclusif soit un service de magasin de données enregistré ou soit sous une licence open-source que nous soutenons.

1.5 Contenu inapproprié

  1. 1.5.a - Tout contenu que nous jugeons diffamatoire ou calomnieux sera rejeté.
  2. 1.5.b - Les packages que nous croyons commercialisés ou présentés dans l'intention d'être ouvertement violents, horribles ou sexualisés seront rejetés.
  3. 1.5.c - Les soumissions qui affichent une haine ciblée de tout type (Race / Religion / Genre / Identité / etc.) seront rejetées.
  4. 1.5.d - Les personnages de base ou les avatars peuvent être complètement nus à condition qu'ils soient commercialisés et présentés avec goût.
  5. 1.5.e - Tous les modèles avec des organes génitaux détaillés ou de l'anatomie interne seront rejetés.

1.6 Contenu malveillant

  1. 1.6.a - Les soumissions avec des fonctionnalités implémentées pour suivre ou collecter les données d'un utilisateur seront rejetées.
  2. 1.6.b - Les soumissions qui tentent d'installer des programmes / virus sur l'ordinateur d'un utilisateur ou d'exécuter des services d'arrière-plan seront rejetées.

1.7 Contenu restrictif

  1. 1.7.a - Les soumissions qui incluent des DRM ou des fonctionnalités en place qui empêchent les utilisateurs d'utiliser directement le contenu ou les fonctionnalités dans leur intégralité seront rejetées.
  2. 1.7.b - Les soumissions exigeant qu'un utilisateur s'inscrive, se connecte ou paie des frais supplémentaires pour qu'un package fonctionne pleinement seront rejetées.
  3. 1.7.c - Les packages contenant des filigranes ou qui gênent l'utilisation du produit seront refusés.
  4. 1.7.d - Les packages qui ne sont fonctionnels que pour une durée ou des utilisations définies seront rejetés.
  5. 1.7.e - Les soumissions qui ont des limites artificielles implémentées sur la fonctionnalité ou la convivialité seront rejetées.

1.8 Produits Lite

  1. 1.8.a - Toutes les soumissions qui sont des versions d'essai ou restrictives de produits seront rejetées. Pour familiariser les utilisateurs avec votre produit, vous pouvez fournir une version «allégée» (plus petite / moins chère / indépendante / gratuite) de votre paquet. Les versions Lite et Free ne doivent pas avoir de limitations implémentées sur la fonctionnalité de votre produit. Les packages Lite ne doivent avoir qu'un ensemble réduit de fonctionnalités par rapport à votre produit complet.

2. Préparer votre produit

2.1 Information sur l'éditeur

  1. 2.1.a - L'information sur l'éditeur doit être incluse et doit répondre à nos normes. Tout renseignement manquant entraînera le rejet de vos soumissions. Les informations requises incluent le nom, l'URL, le texte de description, l'image clé de l'éditeur, le contact du support client, le contact d'affaires et le contact technique.
  2. 2.1.b - Les noms d'éditeurs ne doivent pas porter atteinte aux marques de commerce ou marques.
  3. 2.1.c - Vous ne pouvez pas insinuer sur votre profil d'éditeur que vous êtes un individu ou une personnalité publique avec laquelle vous n'êtes pas affilié.
  4. 2.1.d - Vous ne pouvez pas insinuer sur votre profil d'éditeur que vous êtes affilié à une société ou organisation avec laquelle vous n'avez aucun lien.
  5. 2.1.e - Les descriptions des éditeurs doivent fournir des détails sur votre identité professionnelle et inclure des informations sur vos compétences ou spécialités.
  6. 2.1.f - Les éditeurs doivent avoir et maintenir un site web actif qui contient des exemples de travaux et d'ensembles de compétences pertinents. Les sites web des éditeurs doivent être conçus spécifiquement comme une page de portfolio, ou utiliser un service tiers professionnel tel que Unity Connect, LinkedIn, ArtStation, etc. Si nous pensons que le site web ne vous représente pas adéquatement en tant que professionnel, nous rejetterons vos soumissions.
  7. 2.1.g - Les pages du site web des éditeurs ne peuvent pas être incluses en tant que lien encapsulé.
  8. 2.1.h - Les éditeurs doivent fournir et maintenir un courriel de soutien actif à la clientèle.

2.2 Titres des produits

  1. 2.2.a - Les titres doivent être uniques de tout autre package sur l'Asset Store. Les doublons ne seront pas autorisés.
  2. 2.2.b - Les titres doivent être d'une longueur raisonnable et ne pas dépasser la surface prévue.
  3. 2.2.c - Les titres ne doivent pas inclure le nom de votre éditeur.
  4. 2.2.d - Les titres ne doivent pas inclure des descriptions étendues de vos packages.
  5. 2.2.e - Les titres ne doivent pas indiquer que votre package est associé à une société / un produit auquel vous n'êtes pas directement associé.
  6. 2.2.f - Chaque mot de votre titre doit être précédé d'une lettre majuscule, suivi de lettres minuscules, sauf si vous faites référence à une marque qui n'est pas conforme à cette structure.
  7. 2.2.g - Les titres doivent uniquement utiliser des espaces pour séparer les mots sans ponctuation, à moins de se conformer à une marque établie.
  8. 2.2.h - À des fins légales et d'image de marque, tout package commençant par une marque ou indiquant une affiliation avec une marque sera refusé. C'est à dire. 'Tools for Unity' est acceptable. 'Unity Tools' sera rejeté.

2.3 Texte de description

  1. 2.3.a - Notre équipe de révision peut modifier les métadonnées de votre package qui ne sont pas conformes à nos règles ou corriger l'orthographe / grammaire. Ceci inclut le titre, la catégorie, le texte de description et les mots-clés de votre package. Nous ne modifierons jamais le prix de votre package à votre insu.
  2. 2.3.b - Le texte de description devrait être complet et couvrir tous les aspects importants de votre produit.
  3. 2.3.c - Le texte de description des assets artistiques doit indiquer le nombre d'assets uniques inclus dans votre projet. Nous vous demandons également de fournir des informations détaillées sur le nombre moyen de polygones, la taille de la texture et les types de cartes de texture inclus pour chaque asset.
  4. 2.3.d - Le texte de description des assets de code doivent énumérer toutes les caractéristiques clés de votre produit.
  5. 2.3.e - Tout le texte de description doit être correctement formaté avec des balises html. Utilisez uniquement les hyperliens ‹a›‹/a›, ‹strong›‹/strong›, ‹em›‹/em›. Les packages utilisant ‹p>‹/p›, ‹/br› ou d'autres tags non pris en charge seront modifiés ou peuvent être rejetés.
  6. 2.3.f - Toutes les descriptions doivent être en anglais et avoir un orthographe / une grammaire correcte. Des petites modifications peuvent être effectuées par notre équipe de révision, mais des situations excessives entraîneront le rejet de votre soumission.
  7. 2.3.g - Une version anglaise de votre texte de description est obligatoire, mais les versions localisées pour d'autres langues sont autorisées.
  8. 2.3.h - Tous les hyperliens doivent être correctement mis en forme ‹a href="website"› texte ‹/a› et mener à des sites web actifs et non malveillants.
  9. 2.3.i - Le texte des liens hypertexte doit être adapté au lien auquel il conduit.
  10. 2.3.j - Les liens hypertexte ne doivent être liés qu'à des sites externes et non à des téléchargements directs.
  11. 2.3.k - Les descriptions ne doivent pas référencer des adresses IP, des marques ou des marques similaires à votre produit auquel vous n'êtes pas affilié.
  12. 2.3.l - Aucun aspect de votre texte de description ne doit promouvoir ou rediriger les utilisateurs vers d'autres marchés ou magasins numériques.
  13. 2.3.m - Votre description ne doit concerner que le contenu de votre package. Votre texte de description ne doit pas promouvoir d'autres produits à moins qu'ils ne soient une extension de votre produit, directement compatible avec votre produit, ou requis pour que votre produit fonctionne.
  14. 2.3.n - Les soumissions faisant la promotion de toute «offre spéciale» (tutoriel gratuit, guide gratuit, essai avant d'acheter, etc.) seront rejetées, car il n'existe aucun système permettant de vérifier que les offres sont respectées de manière responsable.

2.4 Images clés

  1. 2.4.a - La présence d'images clés de haute qualité améliore la présence marketing de vos packages et constitue une part importante du succès de l'Asset Store. Vous trouverez des informations sur la création d'images clés propres et professionnelles dans notre Asset Store Promotional Asset Guidelines.
  2. 2.4.b - Les images clés qui ne sont pas une représentation claire de votre contenu peuvent être rejetées.
  3. 2.4.c - Les images clés ne doivent pas être une capture d'écran inédite de votre contenu dans l'éditeur Unity ou une photographie numérique de votre écran d'ordinateur.
  4. 2.4.d - Les images clés qui ne contiennent que du texte brut seront rejetées.
  5. 2.4.e - Les images clés ne doivent pas inclure de texte de description excessif.
  6. 2.4.f - L'image clé peut ne pas inclure de graphiques ou de bannières liés à la vente.
  7. 2.4.g - L'inclusion d'icônes de contenu tiers avec lesquelles votre produit est compatible ne sera pas autorisée si les directives de marque de ce logo sont enfreintes ou si une affiliation directe entre votre produit et le contenu d'un tiers est insinuée.
  8. 2.4.h - Les images clés qui tentent de recréer une vente officielle de l'Asset Store ou des éléments graphiques promotionnels seront rejetées.

2.5 Catégorie

  1. 2.5.a - Votre package doit être dans la catégorie la plus proche de votre produit.

2.6 Mots-clés

  1. 2.6.a - Les mots clés doivent être pertinents pour votre package.

2.7 Prix

  1. 2.7.a - Vous êtes en mesure de fixer votre prix à n'importe quel prix. Si nous pensons que votre contenu peut être mieux évalué dans une gamme différente, nous vous le ferons savoir. Nous suggérons d'examiner le prix des assets similaires sur le magasin et en suivant leur exemple. N'ayez pas peur de demander un prix élevé pour votre package. Cela représente votre dur travail ! Fait intéressant, les packages les plus vendus, en termes de quantité vendue, sont tous à plus de 50 $ !
  2. 2.7.b - Les produits hébergés dans d'autres magasins / places de marché doivent correspondre au prix de votre projet dans l'Asset Store. Il est fortement déconseillé d'essayer de sous-coter grossièrement les prix de produits similaires.

2.7.1 Ventes personnelles

Fournir des packages à un prix de vente est autorisé mais dans les circonstances suivantes. Le non-respect de ces directives peut entraîner la disqualification de votre produit lors de futures ventes officielles ou occasions promotionnelles.

  1. 2.7.1.a - Les ventes personnelles ne peuvent pas durer plus de deux semaines. Si vous ne parvenez pas à rétablir votre prix d'origine dans un délai de deux semaines, toute mention d'une vente pourra être retirée des détails de vos produits sans préavis.
  2. 2.7.1.b - Les périodes de vente doivent être séparées d'au moins 2 mois.
  3. 2.7.1.c - Les détails de votre vente doivent être fournis dans votre texte descriptif. La période de vente et le prix régulier doivent être mentionnés.
  4. 2.7.1.d - Vous n'êtes pas autorisé à inclure des graphiques liés à la vente dans l'ensemble des images de votre package.
  5. 2.7.1.e - Vous ne pouvez pas promouvoir votre produit comme étant inclus dans des ventes ou des fonctionnalités hébergées par Unity Technologies et dont vous n'êtes pas réellement membre.
  6. 2.7.1.f - Pour être considéré pour une vente organisée par Unity, votre forfait doit maintenir un prix constant pendant 2 mois. Une augmentation de prix due à une mise à jour importante ne vous empêchera pas d'être inclus dans une vente.
  7. 2.7.1.g - Après avoir été inclus dans une vente officielle, le prix de votre package ne doit pas être réduit avant 3 mois.

3. Préparer votre contenu

3.1 Organisation du contenu

  1. 3.1.a - Afin de garder le processus d'importation des packages aussi propre que possible, les packages doivent être imbriqués dans un dossier avec soit le nom de votre éditeur, soit le nom du package comme titre.
  2. 3.1.b - Les assets doivent être correctement triés dans des dossiers avec des titres en anglais selon leur type (Mesh / Script / Material / etc). Les packages ne doivent pas inclure plusieurs types de fichiers dans un dossier unique.
  3. 3.1.c - Si votre soumission nécessite la présence de dossiers spécifiques dans la racine du projet, tels qu'un dossier "Plugin" ou "Editor", vous devrez inclure dans votre documentation des instructions indiquant aux utilisateurs de placer ces dossiers manuellement à l'emplacement approprié. Consultez la documentation de Unity pour les dossiers spéciaux et l'ordre de compilation des scripts pour plus d'informations.
  4. 3.1.d - Pour aider les utilisateurs à naviguer dans votre package et éviter les encombrements inutiles, tous les fichiers en double, inutilisés ou redondants doivent être supprimés de votre projet avant d'être envoyés.
  5. 3.1.e - Pour éviter les incohérences lors de l'importation, n'incluez pas le dossier "Standard Assets" dans votre soumission. Si vous avez une scène de démonstration qui utilise des «Standard Assets», incluez une documentation sur la façon dont vous configurez votre scène et permettez à l'utilisateur d'importer lui-même les «Standard Assets».
  6. 3.1.f - Le contenu ne doit pas être inclus dans un dossier nommé "AssetStoreTools" ou toute variante de ce nom car ce dossier est automatiquement supprimé lors du téléchargement de votre contenu.
  7. 3.1.g - Vos fichiers doivent suivre une convention de dénomination cohérente tout au long de votre soumission.
  8. 3.1.h - Les noms de fichiers d'asset doivent représenter le contenu qu'ils fournissent.
  9. 3.1.i - Tous les fichiers incrémentiels doivent être correctement nommés avec un remplissage de nombre correct. Ex. 'asset_01' si vous avez plus de 10 assets, au lieu de 'asset_1'.
  10. 3.1.j - Les noms de fichier ne doivent pas être excessivement allongés avec des descripteurs tels que 'High Quality', 'Low Poly', 'PBR', etc. Tous les détails de votre produit doivent être laissés à votre description ou mots-clés.

Un exemple de ce que nous attendons d'un dossier organisé et correctement nommé, utilisant
Un exemple de ce que nous attendons d'un dossier organisé et correctement nommé, utilisant "Unity Technologies" comme nom d'éditeur.

3.2 Documentation

  1. 3.2.a - Tous les projets soumis dans l'Unity Asset Store qui nécessitent des informations sur la configuration et l'utilisation appropriée de votre projet doivent posséder une documentation locale.
  2. 3.2.b - La documentation doit être au format .txt, .pdf, .html ou .rtf.
  3. 3.2.c - La documentation doit être approfondie et englober tous les aspects de votre projet. Si, après avoir lu votre documentation, vous ne comprenez pas clairement comment utiliser votre produit, vous risquez d'être rejeté.
  4. 3.2.d - Vous êtes autorisé à maintenir une documentation plus complète de votre produit en ligne, mais votre documentation incluse dans votre projet doit inclure suffisamment d'instructions pour que l'utilisateur comprenne les fonctionnalités de base de votre soumission. Les liens vers toute documentation en ligne doivent être mentionnés au début de votre documentation locale.
  5. 3.2.e - La documentation doit inclure un e-mail de support pour que les utilisateurs puissent vous contacter.
  6. 3.2.f - La documentation doit être rédigée en anglais et ne pas contenir d'erreurs d'orthographe ou de grammaire. Vous pouvez inclure des documents supplémentaires localisés dans d'autres langues en plus de la documentation en anglais.
  7. 3.2.g - Toute documentation vidéo ou didacticiel doit être téléchargé en ligne (Youtube, Vimeo, etc.) et non inclus dans vos projets. Un lien vers votre vidéo doit être mentionné dans votre documentation écrite.
  8. 3.2.h - La documentation Shader doit expliquer les propriétés de chaque shader. Ne présumez pas que les noms de propriété seuls suffisent à l'utilisateur pour comprendre ce qu'il fait.
  9. 3.2.i - La documentation pour les plugins basés sur serveur (PHP, SQL, etc.) doit supposer que les utilisateurs ont une connaissance de base de l'hébergement et de la configuration du serveur. Votre documentation doit seulement être spécifique à la configuration de votre plugin et à son utilisation.

3.3 Scènes de démonstration

  1. 3.3.a - La plupart des soumissions doivent inclure une scène de démonstration. Si votre produit a du contenu à montrer, il devrait être affiché dans une scène de démonstration.
  2. 3.3.b - Les projets qui incluent une collection d'assets doivent inclure une scène qui présente tous leurs assets dans une grille ou une ligne continue.

3.4 Fichiers compressés

  1. 3.4.a - Les soumissions avec des fichiers .Unitypackage uniquement pour obscurcir ou compresser le contenu seront rejetées.
  2. 3.4.b - Les soumissions qui comprennent des préférences de configuration, des paramètres ou des fichiers supplémentaires pour un autre produit Asset Store doivent être imbriquées dans un fichier. unitypackage.
  3. 3.4.c - Les fichiers. zip ou. rar ne seront acceptés que s'ils compressent des fichiers qui ne fonctionnent pas nativement dans l'éditeur Unity. (Ex. Blender, documentation HTML, projets Visual Studio, etc.)

3.5 Taille du fichier

  1. 3.5.a - Remarque: les utilisateurs peuvent rencontrer des problèmes lors de l'importation de gros packages. Assurez-vous que tous vos assets sont aussi optimisés qu'ils peuvent l'être ou, s'il y a lieu, que votre soumission doit être divisée en plusieurs packages afin d'éviter les problèmes liés au téléchargement de votre contenu par les utilisateurs.
  2. 3.5.b - En raison de contraintes techniques, les soumissions supérieures à 4 Go seront rejetées. Les packages de plus de 2 Go présentant des problèmes d'instabilité ou des qualités non optimisées peuvent être rejetés.

4. Lignes directrices sur le contenu

4.1 Contenu artistique

  1. 4.1.a - Les packages qui n'ont pas un style artistique cohérent peuvent être refusés.
  2. 4.1.b - Le contenu soumis doit présenter un certain degré de conception et de construction professionnelle. Tout asset qui, à notre avis, ne pourrait pas être utilisé de façon réaliste dans le cadre d'un projet de développement pourrait être rejeté.
  3. 4.1.c - Les ressources meshes doivent être soumises en tant que .FBX ou .OBJ.
  4. 4.1.d - Toutes les meshes visibles doivent avoir un ensemble de textures et de matériaux associés.
  5. 4.1.e - Chaque mesh doit avoir un prefab correspondant mis en place avec toutes les variations de la texture / mesh/ matériel que vous fournissez.
  6. 4.1.f - Les soumissions de meshes non texturées uniquement à des fins de prototypage seront rejetées.
  7. 4.1.g - Les grands environnements ou scènes doivent être divisés en meshes individuelles. Les soumissions avec des environnements entiers inclus comme un seul objet seront rejetées.
  8. 4.1.h - Les prefabs doivent avoir leur position/rotation à zéro lors de l'importation et leur échelle doit être réglée à 1.
  9. 4.1.i - Tous les meshes doivent avoir un point de pivotement local positionné en bas au centre de l'objet, de manière cohérente dans un coin de tout objet modulaire, ou à un endroit où l'objet serait logiquement pivoter / tourner / animer.
  10. 4.1.j - Tous les meshes doivent être tournées pour que leur Z positif soit orienté vers l'avant.
  11. 4.1.k - Les meshes doivent être à une échelle de 1 unité: 1 mètre.
  12. 4.1.l - Les données photoscannées doivent être retopologisées et optimisées de façon à ce que les utilisateurs puissent les modifier au besoin avant de les soumettre. Tout meshes résultant directement des scans sera rejeté.
  13. 4.1.m - Les assets dont la densité de mesh est excessivement élevée seront rejetés.
  14. 4.1.n - Les actifs qui semblent avoir leurs UV automatiquement unwrapped seront rejetés.
  15. 4.1.o - Les prefabs de mesh doivent être configurés avec un composant collider qui s'adapte à votre mesh.

4.1.1 Rigs

  1. 4.1.1.a - Les modèles de personnages doivent être pondérés à un rig d'accompagnement. Le rig peut être configuré avec le système Unity's Mecanim ou peut inclure vos propres animations.
  2. 4.1.1.b - Lorsqu'ils sont réglés sur animations, les rigs ne doivent pas présenter de plis évidents ni de déformations inhabituelles.

4.1.2 Animations

  1. 4.1.2.a - Les animations Bipedal doivent être prêtes à être utilisées avec l'avatar "Humanoid" par défaut d'Unity.
  2. 4.1.2.b - Les projets d'animations non-Bipedal doivent inclure un mesh de démonstration avec une panne de rig bien documentée afin que les utilisateurs puissent créer des meshes conçus pour les animations.
  3. 4.1.2.c - Les animations doivent être découpées en tranches et nommées avant d'être soumises. Les soumissions avec un seul long clip d'animation seront rejetées.
  4. 4.1.2.d - Les soumissions comprenant des données brutes de mocap seront rejetées. Toutes les animations qui sont développées à partir de données mocap doivent être nettoyées en des animations découpées et utilisables.
  5. 4.1.2.e - Les animations doivent avoir un mouvement fluide sans transitions brusques.

4.1.3 Textures et matériaux

  1. 4.1.3.a - Les soumissions qui incluent des fichiers. jpgs seront rejetées. Les fichiers Texture doivent être dans un format de compression sans perte tel que PNG, TGA ou PSD.
  2. 4.1.3.b - Tout package qui est soumis et qui prétend être PBR, ou qui utilise nos Shaders Standard doit inclure au moins une carte de texture albédo, normale, métallique (ou spéculaire) et lisse. Pour plus d'informations, consultez notre blog sur PBR in Unity.
  3. 4.1.3.c - Les textures tileable doivent être sans joints ni bords apparents.
  4. 4.1.3.d - Les cartes avec un canal alpha doivent être associées à un matériau qui peut lire ledit alpha.
  5. 4.1.3.e - Toutes les matériaux importées qui ne sont pas utilisées dans votre produit final doivent être retirées avant la soumission.
  6. 4.1.3.f - Les normal maps doivent être marquées comme "Normal Map" dans les paramètres d'importation.
  7. 4.1.3.g - Le contenu destiné à être exécuté sur du matériel mobile ou bas de gamme devrait avoir des textures atlas afin de réduire l'impact sur les performances.
  8. 4.1.3.h - Les assets ne doivent pas contenir trop de matériaux.
  9. 4.1.3.i - SBSAR et d'autres matériels de procédure ont besoin de documentation ou d'une scène de démonstration montrant les paramètres inclus.

4.1.4 Sprites

  1. 4.1.4.a - Toutes les feuilles de sprite doivent être importées avec les paramètres d'importation "Sprite".
  2. 4.1.4.b - Les sprites doivent être correctement découpés et nommés à l'aide des paramètres d'importation.
  3. 4.1.4.c - Les animations Sprite doivent être splicé, nommées et configurées comme des clips appropriés avant d'être soumis.

4.1.5 Gui Packs

  1. 4.1.5.a - Les soumissions des packs GUI doivent inclure une scène de démonstration fonctionnelle qui présente tous les composants utilisables.
  2. 4.1.5.b - Les composants de l'interface graphique doivent avoir leurs éléments séparés et nommés soit avant l'importation, soit par le biais des paramètres de l'éditeur sprite.

4.2 Systèmes de particules

  1. 4.2.a - Les systèmes de particules doivent être sauvegardés en tant que prefab pour que les clients puissent facilement glisser et déposer dans leur scène.
  2. 4.2.b - Avec la sortie d'Unity 5.4, il est prévu que le système de particules patrimoniales, introduit dans Unity 1.0, sera supprimé de Unity. Ceci inclut les composants "Ellipsoid Particle Emitter","Mesh Particle Emitter","Particle Animator","Particle Renderer" et le code associé. Actuellement, toute nouvelle soumission utilisant le système de particules existant sera rejetée et on s'attend à ce qu'elle utilise le nouveau système de particules (nom de code 'Shuriken'). Jusqu' à l'élimination officielle du système de particules existant, il ne sera pas nécessaire de mettre à jour les packages, mais il est fortement recommandé d'utiliser le système de particules Shuriken.

4.3 Scripts

  1. 4.3.a - Les scripts ne doivent pas lancer de compilateur ou d'erreurs génériques. Toute erreur potentielle doit être correctement détectée et présentée à l'utilisateur par le biais du protocole de débogage.
  2. 4.3.b - Tous les codes soumis doivent être commentés et lisibles sans fautes d'orthographe ou de grammaire.
  3. 4.3.c - Les commentaires du code doivent être en anglais. Vous pouvez inclure des commentaires de code dans d'autres langues en plus des commentaires en anglais requis.
  4. 4.3.d - Le code commenté n'est pas une alternative à la documentation appropriée.
  5. 4.3.e - Les fonctions et les variables doivent être nommées de façon appropriée.

4.3.1 Extensions de l'éditeur

  1. 4.3.1.a - Les menus des fichiers d'extension de l'éditeur doivent être placés sous une entrée existante. Si aucun menu existant ne convient, vous pouvez le placer sous un menu personnalisé intitulé "Tools". Ceci permet de garder l'éditeur propre et organisé.
    Exemple d'une extension d'éditeur idéalement imbriquée
    Exemple d'une extension d'éditeur idéalement imbriquée.
  2. 4.3.1.b - Les opérations d'annulation doivent être prises en charge. Reportez-vous à la documentation de Unity pour plus d'informations sur le Undo Support.
  3. 4.3.1.c - Nous permettons la création de fenêtres uniques pour un support pratique ou informatif. Les soumissions avec toutes les fenêtres uniques qui, selon nous, sont créées à des fins de spamming ou de distraction du flux de travail de l'utilisateur peuvent être rejetées.

4.3.2 Plugins basés sur serveur

  1. 4.3.2.a - Les soumissions qui utilisent un plugin basé sur serveur doivent automatiquement remplir toutes les nouvelles bases de données avec les tables nécessaires.

4.4 Projets complets et template de projets

  1. 4.4.a - Les projets complets et templates doivent être conçu comme un programme d'enseignement, des didacticiels ou des frameworks.
  2. 4.4.b - La documentation complète du projet doit comprendre des informations détaillées sur la façon dont le projet est conçu et comment les utilisateurs peuvent modifier et développer votre projet. Votre documentation doit expliquer plus que simplement comment faire fonctionner le projet.
  3. 4.4.c - Si nous croyons qu'un package est une compilation de contenu/produits trouvés ou le résultat direct des tutoriels publics, il sera probablement rejeté.
  4. 4.4.d - Si nous croyons qu'un package a été conçu dans le seul but de recréer directement la conception, le style artistique et l'esthétique d'un jeu populaire, il sera probablement rejeté. Les produits devraient offrir un aspect unique à notre communauté de développement et ne devraient pas violer les droits d'auteur.
  5. 4.4.e - Si vous avez publié un jeu et que vous êtes intéressé à lancer/vendre votre projet source, veuillez garder à l'esprit que les acheteurs de votre produit sont techniquement autorisés à construire et vendre directement ce projet commercialement. Pour éviter que les utilisateurs n'aient un impact sur le succès de votre jeu en soumettant directement votre jeu sur des marchés tels que Google Play, App Store, Steam, etc., vous devriez peut-être envisager de remplacer votre art par des espaces réservés professionnels mais génériques.
  6. 4.4.f - Les paramètres de projet de votre projet seront automatiquement inclus avec toute soumission en cours de téléchargement dans la catégorie ou les sous-catégories "Complete Projects". Les utilisateurs recevront une notification indiquant que leurs paramètres de projet seront remplacés lors de l'importation de votre projet.

4.5 Audio

  1. 4.5.a - Toutes les soumissions de ressources audio doivent être liées à un serveur ou un service web de prévisualisation tel que SoundCloud™.
  2. 4.5.b - Les fichiers audio doivent être normalisés avant d'être envoyés.
  3. 4.5.c - Les fichiers audio doivent être lus correctement par l'inspecteur d'Unity.
  4. 4.5.d - Les soumissions de collections audio doivent maintenir un format, une convention d'appellation et une qualité uniformes.
  5. 4.5.e - Les soumissions doivent uniquement inclure les formats audio Unity pris en charge. Pour plus d'informations sur les formats pris en charge, reportez-vous à la documentation les fichiers audio et le microphone.

4.6 Applications

  1. 4.6.a - Jusqu'à nouvel ordre, l'Asset Store n'accepte aucune application. (Pour l'instant, tout le contenu de l'Asset Store doit fonctionner dans l'éditeur Unity Editor et nous ne prenons pas d'outils/applications tiers.Si vous êtes intéressé à fournir votre produit qui est une application sur l'Asset Store, veuillez contacter AssetStore@unity3d.com).

5. Message Outro / Support

Nous vous remercions de lire attentivement ces lignes directrices dans leur intégralité ! Si vous avez un problème avec un de vos package qui a été accepté ou refusé, répondez directement à ce courriel et vous pourrez entrer en contact avec le membre de l'équipe qui a examiné votre package. Si vous avez d'autres problèmes concernant votre soumission, votre package ou votre compte éditeur, veuillez envoyer un courriel à AssetStore@unity3d.com pour ouvrir un ticket d'assistance. Veuillez inclure le plus d'information possible dans votre courriel afin que notre équipe de soutien puisse vous aider à résoudre vos problèmes.

les réactions

Pour laisser un avis, vous devez être inscrit et connecté

Se connecter