Community-authored "TRCs" for the Asset Store

News & General Discussion
1

There’s a lot of really great things in the Asset Store. But there’s a lot of… not-so-great things too. And then there are some outright crappy things.

Unity have guidelines, but they’re a bit thin on the ground, and they’re not enforced very rigorously either. For example, I’m pretty sure I’ve bought packages from the store with JPG textures, or editor extensions that add company-named menus to the main menubar.

I think it might be interesting if we came up with a checklist of “things that must be true about an asset for it to qualify as good.” Ideally our checklist is something that the Asset Store team might adopt and integrate into their submission process (though not exclusively - sometimes a crappy, standards-violating package is better than no package), but if nothing else we could keep a community-maintained list of which packages are “certified awesome,” and it can function as a do-or-die list for package developers.

The checklist should also consist only of ‘testable’ criteria to as great an extent as possible - i.e. whether or not a package meets a particular criteria should not really be a matter of personal opinion. So “has good documentation” is no good, but “every public API method has an XMLDoc summary” is fine (if a bit on the strong side).

What would you put on the checklist?

Here’s the condensed form of the most interesting, non-subjective things from Unity’s submission guidelines, to start us off. I’ve strengthened some of their ‘you should do this’ into ‘you MUST do this’ in a couple of places, because either this stuff is worth doing or it isn’t, and if it is then people shouldn’t be allowed to skip it, and if it isn’t then it shouldn’t be on the list.

From my own experience, and input from some folks on Skype, here’s a few things to add/change to all that:

General:

  • All files should be in one folder per compilation phase (which for most packages means: just one folder).
  • Don’t include image effects purely for use in your sample scenes.
  • Any documentation should be available outside of the package (e.g. on a website somewhere).

Art:

  • All textures, unless they are GUI elements or intended to be atlased, should actually be power-of-two sizes. Don’t rely on the texture importer resizing them.
  • All textures must have their texture type set correctly in the importer.
  • Materials should not have ‘default’ names as generated by the modelling tool (e.g. no “Default #27” materials from 3DSMax models).
  • All model vertices should be welded where appropriate.
  • Models should come into Unity in the smallest number of separate objects appropriate - submeshes/multimaterials should be used instead of separate objects where possible.
  • Models should not contain extra ‘bad’ data in the UV2/Color channels - i.e. no junk UVs getting left in by accident. (Using the UV2 channel for something other than lightmap UVs is fine, provided it’s deliberate and documented).
  • Humanoid characters should have preconfigured Mecanim avatars.

Code:

  • All Unityscript files must have #pragma strict turned on (except in Editor scripts).
  • Components/prefabs in scenes should not be used for pure ‘data storage’ - ScriptableObject (or some other asset-based storage mechanism like XML files) should be used instead.
  • All public types, properties, fields, and methods should be documented. If a symbol is not intended for package users, it should not be public.
  • All types should be in namespaces.

Editor extensions:

  • Read-only files must be handled correctly (code must respect the read-only flag and fail gracefully if needed files are readonly)
  • Objects should never be marked as dirty when they have not actually changed.

What do you think? Are any of these unreasonable? What else would you add?

2

I think these suggestions are not only reasonable, but mandatory. To add to it, I would like all assets to be rejected if the author cannot accept an agreement where it is OK for us to distribute said content royalty free in our games. From time to time I’ve seen arrogant asset store authors pop up saying weird stuff like “oh you can’t use it if you’re selling your game” - I mean wtf is that about?

Also, I’d like a clear list of supported platforms. Mobile, Windows DX11, Windows DX9, Mac OS etc… I also would like a check for garbage - if an asset starts spewing garbage everywhere, it’s simply unacceptable (yet common).

I think as the store grows, we will see a lot of cowboy work and that reflects poorly on Unity, so standards are a must.

3

That doesn’t work at all. I include DLL + source, and it’s simply not possible to import both at the same time, so the source is a separate unitypackage. Also it’s far easier to import demo stuff as a separate package, instead of including everything in one huge package, some or most of which you do not want to import on a regular basis.

–Eric

4

My 2 cents:

  • I think .max is a proprietary format and requires 3D Studio Max to convert to other formats. Maybe this has changed recently?
  • Power of 2 textures are always a good idea, but you should explain some of the issues with up and down sizing textures
  • There’s no way to enforce correct texture type, its just a setting
  • Naming conventions are very important, but I don’t think you can enforce them.
  • There is no way to determine what verts should be welded except on a single smoothing group
  • I guess you could write a script that combines multi objects into a single object with multi-materials…
  • Useless data in the color channels is often hidden and requires scripts within the modelling program to delete that useless hidden info. Most artists are not even aware that it can exist and won’t be able to write the scripts to clean it up.

Based on my past experience, these art things are had to enforce and usually requires a technical artist to monitor them and clean them up. That’s not an excuse for ignoring them.

5

Examples and documentation should be in written form. Other forms (eg: tute videos, example scenes) are great additions, but should not be the primary documentation.

I like the idea of explicitly documenting all public API members, even if for no reason other than to ensure that people think about whether something should be public and making its usage clear. If it should be public then it should be clear as to what it does, either through appropriate naming or an explicit comment, and making people write the comments helps them get that straight. Also, comments should be explanatory, not descriptive.

6

Also, web based docs. Having the docs online is great and can include more up-to-date info, but the current version should be included in a local file with the asset. A good example are the Mega-Shapes and their other tools. They include a change log and link to their site for docs/api. But their site is painfully slow and their docs are spread across multiple pages. It is really a pain to browse their api.

Heh, one of my favorite extensions has docs that are basically screen shots of examples they typed up. Useful info, but it would be nice to be able to copy and past from the api list.

There are more than a few that assets from the store that have company names in the menu. The Hedgehog Team is one of the worst of offenders of this. They have some great assets, but they sure spent a lot of time self promoting in the editor. Icons in the project window, icons on assets on the stage. Not only that, but their company name is long and annoying to have in the menubar. I have to strip all the crap out after I install it.

Great suggestions. I would hope that developers would look at this and make some better choices when putting a package together. A few of my requests in no particular order:

  • even though it is mentioned above, I would remove the qualifier. NO top menu additions at all. Period. Everything should be in the proper menu places, there is no need to add another one.

  • All demo assets (models, scenes, mats, textures, etc) should be in a single folder labeled demo. that way it can easily be excluded on import.

  • Don’t include things that are not part of your asset. (like the whole standard assets folder)

Naming…

  • Name everything properly and logically. A demo scene shouldn’t be called “scene”, you shouldn’t have materials called “material” or “test” or other generic names. Also add the name of the asset to the readme file name like ReadMe - Cool Editor tool.txt. If I import a handful of assets at once, I get several readmes all named the same.

  • Name your meshes / objects and prefabs, especially if you asset is primarily a collection of models. These almost always have generic names like box123, default, and polysurface. A real pain to find mesh.
    1298631--60156--$Screen Shot 2013-07-14 at 9.26.59 PM.png

-Use clear and sensible names. remember your assets are probably not the only ones used in someones project. Ideally prepend the names if there are should appear as groups in the selector. Like “sb_whatever” for skybox images, or “matcap_red” for matcap images. if they all have generic names they are spread though the list. Specific ones like skybox images or matcap textures are really only used for those cases. Things like that. Make the images easy to get to with keywords and named in a way that is clear.

  • Editor icons. Please, PLEASE do the same for icons that are used in editor panels. Or better yet, put them all in a single image. There are a few great editor extensions that have lots of icons. While they are amazing tools, it is annoying to have my image selector riddled with images that aren’t part of my game. I usually rename that all “zzz_originalname.png” so then mod the editor. This at least puts them all the end of my selector window.

That is really the biggest ones for me. And I pretty much agree with everything the others have said.

7

Well, that’s kinda the idea. I mean, in theory, the everything in the quoted box already is mandatory, though the Asset Store team don’t seem to enforce it very strictly.

Hmm… I’ve been focusing on “technical” requirements rather than things like having rights to the content and license and stuff. Maybe I should add something though. I’m less concerned about stuff like license because at least that is something you can really check before you buy - most of the intention here is to kill the things that make you go “oh, ffs” when you’ve actually bought the package and you start to try to integrate it.

Ah, yes, OK. Or if no platforms are listed, the asset must work on ALL Unity platforms.

In the interests of making this a pass/fail test, how much garbage is too much garbage?

8

I think Unity’s requested practice in that case is to include the source in a ZIP file, not as a unitypackage. Section 5.1:

I think I’d consider your source to be ‘non-Unity-native assets’ - the intention here looks to me like it’s OK to use zip files for “source files” in general (be they maya/max files, code, or whatever).

I agree, though this is something that Unity themselves actually forbid, as quoted.

I assume that the purpose of this is to make it easier for people who don’t know Unity very well to find the demos. I suspect that’s a silly reason - anyone incapable of finding and double-clicking a package file is probably incapable of finding and double-clicking a scene file too.

9

Nope, that’s still true. Same for .mb. That’s why models are required to be in .OBJ or .FBX format. It’s OK to provide .max files as well, for the benefit of those users who happen to have Max and want to work with exactly what you put together, but users that don’t have Max can still work with the FBX/OBJ.

I’ve not really added any explanations for why most of these requirements are the way they are, but yeah, that needs to be added at some point I think.

True, but I mean, it should be a requirement that that setting has been checked/set for every texture. I guess the only one that can really be checked in an automated way is normal maps - basically, using a package as-is, I should never see the “Texture is not marked as a normal map” warning upon import/in the inspector.

I thought about naming conventions but more than anything I wasn’t sure what convention to adopt. It is possible to check and enforce some things, like texture filenames, based on the material slots they’re used in.

Ehh… well, no, you can weld vertices that are used by polys in different smoothing groups, but if you mean that there’s no mechanical test to know which vertices can be welded… it’s true, but I think there’s still some situations where a human could look at it and go “hey, c’mon…” Like, it’s not OK to submit a model that when you look into how it’s been built, every single triangle is actually disconnected, kinda thing.

Maybe that requirement needs to go, as what it’s really getting at is “art should be optimised” but that’s subjective. Or maybe we need to place an upper limit on how many vertices there can be as a percentage of the triangle count.

Yes, though in Max it’s as simple as picking your “main” piece and then Attach List all the other bits. If you have different materials assigned to each piece then Max will automatically make a Multi/Sub-Object material for the result.

In Max you can do it via the Channel Info window (or UVW Clear modifier), but yes. As you say though, I don’t think this is a valid reason to ignore them; the scripts have already been written and can be found on the web, and if an artist wants to submit a game-ready, smoothly integratable package, then they’re going to have to learn some things.

Yeah, a bunch of this stuff is just “technical art requirements for working well with Unity.” I’m fine with requiring that artists either learn a bit of that stuff, or find a technical artist friend to review their stuff prior to submission. If we’re really looking to identify the most ‘well-behaved’ packages, we shouldn’t be making exceptions just because the artist didn’t know any better - it’s up to them to fix that.

10

It’s not how much that matters, it’s when. If there’s any kind of per-frame generation, or behind the scenes generation that’s not a result of something that you control, then it’s bad.

11

Agreed. I’m not going to compromise on the quality of an asset I purchase just because the seller might be a rookie. At the end of the day, if you want to sell something then it should be of appropriate commercial quality.

12

There are a few that come immediately to mind:

Location Neutral: I think all assets should be able to be installed in pretty much any folder structure you like. I understand sometimes an Editor script will need to access a resource, in which case if it can’t be found automatically, there should be an easy-to modify file that points to wherever you’ve installed it on your system.

Namespaced or Prefixed: I think that all asset components should be either in their own namespace (if for Unity 4.0 and above), or prefixed. (Yes, I know my own asset doesn’t do this - I regret it now).

Extension Methods should be prefixed: I’d like all extension methods to be prefixed, which makes it obvious when you’re using an extension method and where the method comes from.

13

TurboSquid has the Checkmate program which is trying to improve asset quality.
http://www.turbosquid.com/CheckMate

They recognise the extra effort required to make a perfectly clean model so the minimum price for a CheckMate Pro model is $49. It would be tough to sell a single model on the asset store at that price.

14

I think it’s okay to have some common-sense guidelines, but if the list becomes lengthy then it becomes prohibitive and starts to be a big turnoff… Unity is about removing the pain of development, and lots of technical hurdles can easily make the asset store seem hard to get into. It has to be balanced with openness and some forgiveness.

15

Ah, great link, thanks! We can definitely pinch a few of those.

For a skilled artist I’m really not convinced it’s a lot of extra effort. With some things (like ‘no isolated vertices’) it’s little more than just knowing which buttons in Max to click before you export.

16

Well, this is why I think rules like these should be for a separate ‘certified excellent’ kind of thing rather than absolute requirements for getting into the Asset Store at all. If you can’t be bothered to comply with them, you can still sell your stuff.

That said: I’m interested in removing the pain of development for game developers, not for asset store developers. That it’s ‘easy’ for an asset store developer to throw stuff up onto the store is exactly why there are quite a number of poor-quality assets. So instead of one asset store developer putting up something that five game developers then have to fix independently, I’d rather require the one asset store developer to fix it up-front so the five game developers can use it without problems.

You’re right that the list needs to be as short as possible though - or possibly that there need to be multiple lists with multiple ‘levels’ of certification (“certified good” vs “certified excellent” etc).

17

In that case I’d be putting a unitypackage in a zip file, which seems fairly nonsensical… Unless you’re going to ask users to manually move the source files into the project themselves, which is worse.

This isn’t possible in the case of scripts, since it may be required to place them in the Plugins folder because of script compilation order issues.

–Eric

18

Yes, that’s true for plugins - however, I think you should still be able to put the files in a subdirectory of your choosing once within one of the unmovable Unity directories (like Plugins, Plugins/iOS, Plugins/Android etc)

19

Testing against many of these items could be automated, which would make certification easier and make creating a good asset easier for the asset author, especially if each item had some good descriptive text with it, including advice on how to fix each point.

20

All these suggestions are very well and good, but I can’t imagine Unity are staffed enough to enforce this. Therefore it comes down to having much more data available before purchase, such as a complete table the asset author must enter data in for example ticking a box which claims it does not allocate data each frame during gameplay execution (if middleware and not an editor tool) for example. Or ensuring all verts do not have garbage data in them that goes unused. This would be a tick too in the list.

Then we can just scroll through the list and choose to buy it or not - its essentially self enforced certification. If an asset is unable to tick what is important, it probably won’t be that popular. And if an author lies, well the rating for the asset would be a little on the low side I’d think until fixed.

One thing that’s absolutely vital is that the asset author and customer have a clear line of communication. Currently, I don’t think sellers are able to ask customers any questions on improvement or encourage a re-review without the customer first getting in touch. Perhaps every update, stars for the asset can be reset like the appstore, with the option to see old stars.

In short, I’m asking what options we have given that unity are understaffed for the job.