To me this is kind of a critical issue. Unity needs to define and enforce some standards.

Namely on Asset Store assets. Unity needs explicitly define the folder structure things should go into. The API’s people should use for editing XCode projects, or any other common API’s. Unity needs to make those commons API’s easily accessable dependencies in a common place somehow, so not every third party asset has to include it.

Further than that I think unity needs to publish coding standards. I have personally taken on the coding standard of Unity’s open source C# code. But I think this should be published openly, as an official document. We should all be writing C# in the same style as how Unity themselves does.

The asset store should have the use of these defined folder structures, API’s and code formatting strictly enforced.

Also I think all Unity assets should be forced to come either as C# source code, or a compiled DLL. And then there be a drop down menu in the asset store that says ‘Download DLL’ or ‘Download Source (if available)’, into the the project.

There should also be the ability for asset store uploaders to specify ‘Optional Downloads’. So that there can then be a ‘Download Examples’ button, or a ‘Download Unity 4.6.x DLL’.

It should also be forbidden to put documentation in a PDF inside the asset itself. All documentation should have to be hosted on the web somewhere. I don’t want unneeded PDF’s and txt files in my Assets directory.

This current set up that there is only one UnityPackage per asset store package and you must download the whole thing, where asset store creators had to package the different versions in zip files, or put the docs in a PDF. This is just messy.

Of course I am asking for alot here, such a change would be drastic. But really I hope there is some committee at Unity discussing standards for these things to publish and thinking of some plan to have people conform to something. Atleast something.

In the least make an official requirement that the asset needs to be in it’s own namespace and under an Assets/YourAsset subdirectory.

Asset store is great. But seriously needs to some refinement now that these issues have popped up.

I wouldn’t argue that the points I highlight are what it should be exactly. Am just doing that give an example. Just saying there needs to be some kind of standard defined and enforced. I’m sure someone much more knowledgable than me could come up with better standards and ideas.

6 Likes

I suspect they’ll get there eventually. The Asset Store used to just be the Wild West, and that’s getting much better. And with all the competition among game engines these days, I think the natural progression for Unity to stand above the rest, and consequently, shake that lingering stigma that Unity games are somewhat amateurish, would be to enforce higher standards in its development assets.

And like you said, this kind of strictness is such a big change, that it’ll take a long time to get there.

1 Like

You seriously want code formatting to be enforced? And in the manner that Unity formats their code, which is substantially different from the standards created by Microsoft, and isn’t even consistent in Unity coding?

A lot of your rules seem unnecessary, and some I’d call even petty. I’d say that if you have issues with how a certain asset is packaged and coded, you should take it up with the asset creator. Your proposal sounds like micro-managing with the sole point of making it easy for you to do things specifically your way. I don’t like Unity’s way of formatting their code, and I don’t mind importing an asset and reorganizing it to fit my file structure. I often work offline, and have no problem with assets coming with instructions.

I don’t expect you to agree with me on this stuff, and that’s the point. You want everybody to do things exactly the same, but this is a large community with diverse styles and desires. To force everybody to do things exactly the same for your convenience is like saying “people may only eat chocolate ice cream, for that is the best flavor and dealing with desires for multiple flavors is inconvenient.”

Here’s my simple solutions to your problems: don’t like somebody’s coding style? Run their code through Resharper. Don’t like extraneous files? Uncheck them while importing. Don’t like a file’s default location? Move it.

4 Likes

It’s hard enough to get people to read the docs; making them be hosted elsewhere (out of sight, out of mind) would be problematic. As it is, I somehow occasionally get support requests asking “where are the docs” when they’re right there, so I can imagine how bad it would be if you had to go to a random external site. Having docs included in the asset doesn’t do any harm, plus it’s convenient when your internet goes out or you otherwise don’t have access.

Having enforced coding standards might be nice but there’s no way that can be practically implemented. Unity’s own code isn’t consistent anyway.

That’s not actually true; there are different packages for different major versions. Downloading my SpriteTile package, for example, gets you different DLLs depending on whether you’re using Unity 4.x or Unity 5.x. However this should be refined further since there are sometimes differences in the .x versions that require code changes, so having different packages for major versions doesn’t help in those cases.

–Eric

I don’t want people arguing against me on this like I am trying to impose my way on everything. This isn’t the case. And like I even have any say in this at all other than just making a forum post about it and hoping some at UT reads it.

I just want some more standards implemented to make things more consistent. Whether this is how I am currently doing it, or Unity decides on something and then I conform to that I do not care. I just want more consistent standards for asset store packages. So I am not always having to rearrange and alter things in Assets to get rid of issues between them.

Enforced code formatting is extreme. I wouldn’t expect it to happen. But I would personally vote for it if it were an option.

If you don’t want any discussion, posting a topic on a public forum wasn’t really the thing to do. You’re using strong language such as “should be strictly enforced”, “should be forbidden” etc., so reactions to that shouldn’t be surprising. Send an email to the asset store if you just want to give them some private feedback.

–Eric

1 Like

I’d like people to discuss it. Just don’t assume my ideas are the authority. I was hoping I wasn’t the only one who has run into struggles due to inconsistencies in asset store packages.

Also, on another note but slightly related. Unity’s own open source code does vary package to package. But thus far I have been following the format in the UI source code that’s been released. As that is an actual module included in the engine itself. I presume that is representative of Unity’s actual internal C# code. Whereas things in their examples, or the other peripheral open source projects are not.

1 Like

I agree with having tighter standards. I’ve raised my issues before so I don’t really feel the need to repeat them again, but even simple stuff like making people use namespaces to reduce the chances of conflicts between packages would be a great step. (Heck, you could all but eliminate conflicts by having people register their namespaces in their publisher account, and making sure they’re all unique.)

Also, general quality and QA. I purchased a package the other day which didn’t have documentation, didn’t have source code, and (when I’d eventually figured out how to use it by trial and error) just plain didn’t work - it got hung up on an internal index out of bounds exception. That’s obviously a worst case scenario, but there’s also plenty of cases where I’ve grabbed stuff and decided not to use it for the same type of quality issue - I look at the code, decide that there’s no way it’s robust enough for my liking, and find some other solution.

On the whole the Asset Store is still a huge plus, because even considering the time and money I’ve spent on assets I’ve decided not to use (or… been unable to use) on the whole it still comes out way in front. Still, I’m pretty certain that if those issues were weeded out before a customer had purchased and started to use an asset it’d be even better for everyone.

That’s not what he said, though. :wink:

3 Likes

Hardly a critical issue. Getting the front end of the asset store user friendly would be far more useful to everyone.

2 Likes

Coming up with coding standards in a large company is hard enough let alone getting a whole marketplace to agree to. It’s impractical. Some people like Allman style brackets, some GNU style brackets. Some people like Camelcase, some don’t. As the topics get to a higher level like interface recommendations, etc. forget about it, companies don’t even usually get that far or they aren’t enforced and companies even have some authority over their employees.

Commonsense basics like @angrypenguin talked about sure (namespaces, documentation, etc.), but anything overly pedantic is a waste of time. In general our field changes so fast that you always need to learn new techniques and styles anyways and getting used to different coding standards is just a part of that. Sometimes, you encounter some new style and say “Hey, I like that, it makes things clear”.

As an experienced developer (30 solid years) but new to Unity I feel your pain, techmage. While enforcing code formatting goes beyond what I’d recommend, I get your point. While people who are fluent in all things Unity might not see the need, there’s nothing wrong with enforcing a “basic foundation” for something like the Asset Store - and it would make it SOOO much nicer for people who are new to Unity.

Jay

I think people might be getting caught up on the style and formatting aspects of @techmage 's issues. There’s a lot more to it than that.

2 Likes

Some things, like enforcing a consistent UI, and workflow would be nice. There have been multiple assets I’ve downloaded that force me to use a different language or interface from the one I’m used to. Editor extensions in particular should still feel like you are working in unity.

Not convinced how pratical this is.

I’ll disagree. I can find more assets on the store than I’ll (probably) ever be able to afford, but using an asset that I buy is, at this point, hit or miss. This last week was “learn to use the assets you bought over the last year” time, and it’s left a sour taste in my mouth. If, at the least, there was a convention for where files are imported it would be really nice for anybody who’s new to Unity (and wouldn’t bother the pros who want to move things around anyway).

Right now, for example, I have no idea if the PDF file downloaded into my assets folder is bundled into my build or not. I kind of assume it is (because it’s in assets) but how am I supposed to know exactly what asset parts should stay in and which should go? Importing conventions could help that problem tremendously.

Jay

1 Like

One thing that irks me about many assets is that they add new menu items which are just their developer’s name. Instead of “Window → Funky Editor Tool” there’s often stuff like “Generic Joe’s Assets → Funky Editor Tool”. What the heck for? The menu bar is for navigation, not advertising.

Unity are already doing some level of QA, which surely means that they’re at least importing assets into a fresh project and making sure they don’t have immediate errors. It can’t take more than an extra 30 seconds to make sure that their menu items are following guidelines that I’m pretty sure already exist.

4 Likes

With the exception of scripts, that are always in a build, assets only get included if they are reference in a scene or in the resources folder. So including a PDF manual in the asset folder doesn’t increase build size.

2 Likes

Thank you!

So I don’t have to worry about that, but for the more “particular” among us, examples that all go under an Examples folder, documents that all go under a Documents folder, etc., would be nice. Less searching around for things that change from one asset to another.

Jay

2 Likes

Assets should all install into plugins, where they would not be recompiled every time someone changes their own code. It is also highly inconvenient if the asset cannot be relative, some people still hardcode this crap.

Guilty parties like should allow being moved around. Hardcoding paths is retarded. But most of all this needs enforcing on Unity’s side. I have a main project root filled with asset junk because I can’t tidy them up or optimise the compile times because they break. Recoding them each update isn’t my fecking job nor what I paid for.

9 Likes

Hear here!

2 Likes

Yup I agree more on the Asset Store packages being consistent than I do on consistency and strictness across the board, so although I “like” a lot of the original post I don’t necessarily agree with it the whole thing so I didn’t hit “like”.

Registered consistent namespaces for Asset Store packages? Standard locations for store package files? Yes, please. :slight_smile:

4 Likes