Asset store is more strict on free packages?

I’m having a mixture of feelings now, but all circle around the axis of WTF?!

I recently released 3 free packages.

  • DEVBUS: a better undo system (which I ended up just posting and uploading it as an attachment here)

  • EditorGUIFramework: a bunch of useful stuff for editor scripting, most importantly it contains a GUIWrapper that lets you use GUILayout-like methods in GUILayout-restricted areas, like PropertyDrawer.OnGUI (pretty much a response to this feature request)

  • ShowEmAll: An extensive set of property drawers.

For each package, I got the same rejection reasons:

  • Please include documentation with your submission, as it is mandatory for all plugins that require the user to perform more than one step. Create some sort of set up guide (video or pdf), as well as a script reference if they will need to do any coding.
  • In the documentation file, please include your contact info so that users who download your plugin can email you with any problems.
  • We would like you to nest your editor extension within an existing tab rather than creating your own. We now allow extensions to be put under a “Tools” tab, if you don’t find any of the other tabs applicable. This is to avoid the toolbar becoming cluttered.

Allow me to say, this is straight fucking bullshit!

Now to elaborate:

2 and 3 are pretty much the same for all packages:

2- I CLEARLY mentioned in all the packages’ description that for contact info, users could use the package’s thread or contact me at a certain email
3- It’s true, I used my name as a menu item, BUT so did MANY other packages do! and so DID I do in my previous uFAction package. Why didn’t they say anything about those?! How does this rule work?! Does it only work for paid assets? for hot-shots only?? I have no problem as long as you apply the rule to everybody and not just some of us… hence the WTF!

1 is different foreach package:

  • DEVBUS: EVERY single file was documented. I had a very simple test script that you just attach to a gameObject to test the functionality of the undo. You just read it and you’re pretty much good to go, there’s really nothing more to the package than that.

  • EditorGUIFramework: I didn’t have “EVERY” file documented there, that’s true. Cause most the files didn’t actually need documenting. Users didn’t need to worry about them. Not to mention that the API that I use for my GUIWrapper/GLWrapper is almost the SAME that Unity uses for its GUILayout/GUI stuff, who doesn’t know how to fucking use Unity’s GUI stuff?! And I DO have a reference/example file and a test scene, just open it up and see what you could do with GUIWrapper.

  • ShowEmAll: This is the one the pissed me off the most. This package is just a bunch of property attributes that you could apply to different objects to get to draw them in custom ways. WHAT IS THERE TO WRITE A GUIDE FOR?! Am I supposed to write a guide showing how to declare a variable with an attribute?! This is a fucking insult to my users! EVERY attribute was documented. There is a test scene that has an example FOREACH feature/attribute in the package!

Not to mention I had screenshots showing how you could use/setup everything…

This is just too much to bare. I’ve worked so much on those, put so much effort. I wanted to put them out for free for everybody to use, cause I think Unity’s editor is shit out of the box. I thought everybody should have a smooth, nice and pleasant experience without paying.

Did this crap ever happened to you my fellow devs?

I have some free assets in the store and never had issues with rejections like you. I was always successful when I placed a readme file in the main folder explaining where to find everything and my contact information. Additionally I created a reference.pdf which gives an overview and explains the basics.

I quickly had a glance over DEVBUS in GitHub. You may have removed the readme kind of files of course, but that one is obviously missing. What I found misleading was the Test folder. It would be far more useful in my opinion if you would rename it to Example(s). For that kind of package, it is necessary from my point of view to have a document which gives the customer a quick overview. I certainly don’t know whether your package would be accepted like that.

Hi @Dantus , actually “Examples” would have been more accurate than “Test” you are correct cause that’s what it is actually, examples. Taken note. But considering how small the package is, I didn’t see a need for the document you’re describing. I thought that all that’s ever needed for must customer to understand was in the test (example) scripts I had… It seems that I’m mistaken.

And there were many complaints about that (understandably), so they stopped allowing it.

No, you do need to write standard docs…if people can find any way to misunderstand, they will. Don’t assume that looking at scripts is enough.

The submission guidelines are very clearly documented (with screenshots and everything) so honestly I don’t think there’s much excuse for ignoring them and then complaining about rejections. I understand that you’re frustrated, but I can’t see that this is an appropriate way of expressing it.

–Eric