I’m creating a new project, and again I’m going through the somewhat laborious process of reimporting all my old assets. This is so much more of a chore than it needs to be. Conflicting class names, old standard scripts and shaders, folders everywhere - Ugh!
If you are an asset developer, please think about the following topics.
Please put all your content under a unique folder. Otherwise, when importing, your stuff is scattered all through our projects, either in the root folder, or in generic “Textures”, “Meshes”, “Scripts” folders, getting everything all mixed up and basically junking up our projects with lots of stuff everywhere. If you would create a unique folder to put your stuff in, it would make things so much tidier, and easier to find. For example: “MyCompanyName/MyProduct/…”
If your app is some sort of utility, please include a read me with instructions on how to “get started”. I know it seems self-evident to you (you did write it, so I hope it does). But for someone with no familiarity, it may not be so obvious. Unity is very flexible, and things can be done so many ways. If it’s too hard to write documentation for your product - think how hard it must be for someone to figure out without documentation.
Please Don’t include standard assets. They get out of date in later versions. I know they’re not supposed to, but they do. Instead, if you need standard assets, put that in your readme file. If you really, really must include them for some reason, then at least put your copies under your own subfolder (see 1).
If appropriate, please include a complete working scene with your asset. Preferably zipped up so we don’t have to delete a ton of files every time we create a new project, after the first time. You make cool scenes to get us to buy your asset - just go ahead and include one of them.
Please include source code instead of DLL’s. A lot of people, myself included, prefer source. Not because we want to steal your secrets, but because the odds are that you will abandon your asset and quit fixing and/or updating it. Without source, we’re screwed when this happens. There are very few assets that are still updated a year or two after release, and making games can be a long term process.
Consider putting your code in a namespace. This way, when you create yet another “tween” class, your special version doesn’t conflict with someone else’s class. Your code would know exactly which one to call, and their code wouldn’t see yours. No conflicts. it would even lower your support requests.
Don’t use hardcoded paths if possible. This way, if we need to move your folder somewhere, it doesn’t break.
Don’t include a generic asset preprocessor! Maybe setting the scale, generating collision meshes, etc is cool for your models, but likely it’s going to mess up others. Better that you just set the scale in your modelling too so they work without it! But if you do need to include one, then document that you did - and be careful that you check paths (etc) to be sure you’re only preprocessing YOUR models.
Maybe you don’t agree with all these. But just know that there are some of us that look at the assets we buy and judge them on how easy they are to use/update/ etc. Following these suggestions, when they make sense, means everything is easier for your end users. Less complaints, less filtering, and more sales.
Good points, more importantly about point no 5 is the most important for me as other reasons i need to deeply integrating customizing it with my projects, no matter how good an assets is, when it’s closed source it’s no fly zone :/, i am not trying to pointing finger to any assets here, but AI assets closed source? cmon. Do we have to forgetting from which starting points we coming from?, helloooo, we are indie developers ladies gentleman, and this is a developer world, i would be tolerating this open vs closed thing if i am on end client store.
I agree with those points and generally follow them with my utilities. In fact I think it would be a good idea if they started enforcing most of these as part of the official guidelines. I tend to include both DLL and source, because the DLL is often easier to work with, but you always get the source if you need it. The only thing with #4 is that it may require convincing asset store staff to let you include zipped files, which is apparently against the guidelines, but I can’t see any good way around it (for the exact reasons you mention) so they’ve let it slide.
I very much agree with this thread. I have actually found myself importing packages, reorganizing them, and then exporting them again so that in the future they’re already in reasonable shape to start working with.
I don’t expect every asset producer to use the exact same folder structure. But the practice of putting all of your items in a sub-folder for your specific package will go along way to helping your customers keep their project assets organized.
I always put AUB_ prefix to all my classes and file names, use the namespace Aubergine whereever necessary and finally even for different products they are all under the same Aubergine folder in your root folder.
If for some reason they are not, you just tell me and i fix it
This prevents conflicts and everything is in order.
100% agree with Jaimi. And like Eric, I think it would be a good thing if Unity adopted such rules as official guidelines. I often avoid re-using some purchased assets, just because their folder organization is a total mess, which would need more checking before approval.
Added #8 - Got tired of finding yet another mesh preprocessor that globally sets the scale for EVERY MODEL IMPORTED thus screwing up all my other assets. Don’t be lazy - set the scale properly in your modelling tool And if you can’t, well, then at least be sure that your preprocessor only affects your models.
