If one is serious about game development it’s unbearable to work with the Asset Store the way it is.
If you have hundreds of assets there’s no way to filter or sort items.
It would be welcome:
to “install” and “uninstall” assets inside a folder like “Third Party”, cleaning/organizing my project’s root folder
to know which asset were “installed”
to update installed assets per project. Today you have to track each asset installed, know its version and update it manually. Do that for a hundred assets and you don’t have time for true creation.
some sort of dependency management (that would also fix the annoying commonly duplicated scripts that you need to fix each one by hand so not to lose GameObject’s references)
some way to group items like “basic assets every project should have” (one have to resort to Grab Yer Assets for this kind of functionality)
in general, allow one to be productive and focus on game creation, not spending so many hours managing assets
The thing is, even basic functionality for any serious project is missing. You cannot search your purchased assets for a title or publisher’s name, for example. Go ahead and find what you want in hundreds of assets spread across various pages each time.
Things are extremely slow and cumbersome. Very bad UX. It’s unbelievable they didn’t fix that yet.
Since Unity doesn’t make money when you’re are successful, they don’t have an incentive to help you manage your assets and workflow. Unity’s interest stops after you buy an item.
Caveat emptor: if you’re starting game development now look for alternatives or be aware before you spend thousands of dollars in a very unproductive and subpar asset workflow and management.
What do you think? Tell me if I am missing something because the way I see now is very unproductive.
Keeping track of what assets are installed or not is a difficult task, since you’re free to move the assets anywhere you want in the Assets folder, and you’re also free to only partially install assets. Is the asset installed or not when you left out half of it when you installed it? (I routinely do this when excluding demo scenes or standard assets for asset store installs)
I do think they should enforce requiring all assets to install in their own folder under a “Third Party” folder though.
Updating assets is another tricky one, because the design of the asset could have completely changed, previous script files may no longer even need to be there, and the existing asset may have serialized references all over your project. Another issue is you are free to modify assets you download, which I routinely do, so how should Unity handle these modifications? Just delete them?
In general though you shouldn’t need to update assets you download from the store unless they are fixing a bug you are hitting or are adding new functionality you need. If the update doesn’t do either then you shouldn’t be updating it, simply because why are you even updating it then? I can’t imagine any scenario where updating 100 assets in your project is a good idea.
…unless you have a base project containing all of the assets you want to use already, and you use that project to start new ones.
Point is, it’s easy to disagree with someone’s perspective and dismiss an idea if we ourselves aren’t affected by it. Sometimes it helps to put ourselves in someone else’s shoes.
I’m also in agreement that even if I could mass-update in a project I wouldn’t do that. Just updating one asset generally involves effort and testing, doing a hundred at once just doesn’t make any sense to me. Moreso if it’s a shared set of assets used with many projects, the testing and troubleshooting becomes even more important there.
I definitely agree that some kind of enforced organisation is a good idea. My project folders get 3rd party stuff scattered all over the place and it often makes things a mess. I used to manually put stuff in a “3rd party” folder, but that just caused a bunch of other issues - it breaks updating and, even worse, some assets hard code paths to things…
Dependency management would also be neat. It hasn’t really been an issue for me, but I can see how that would easily be an issue with some combinations of assets, and it’s something that other package distribution systems (like NuGet) cover.
Install tracking would also be great. I think that some of the complications could be handled by a) enforcing some organisation as mentioned above, and b) making sure it has “partial” and “modified” states. (Once something becomes “modified” the package manager really can’t do much for you any more, but at the same time you probably don’t want it to change things and lose your modifications anyway.) The system doesn’t have to be perfect to make life easier.
I keep a document of 3rd party assets I’ve imported and list what I’ve unchecked/removed demos etc.
if I moved it afterwards, changed anything, interferes with other assets, what assets within assets it has.
At least then I have some reference if I might update something later and how dangerous it might become.
Generally code assets I don’t move, pure texture/model assets go into a 3rdParty folder.
One real troublesome one gets its own project because I’ve done major changes to it and gets export/imported.
It’s not all bad though, I find most assets aren’t much of a problem, some very good stuff on the store.
Just need to keep track of them. Project Management.
I had no intention of dismissing anyone’s idea. I was just trying to convey my own opinion, which is no more valid than yours or the opinion of the OP. Apologies if I came off otherwise.
Hundreds at a time may be an exaggeration. (Well, maybe not for a big studio)
I do get to update hundreds during the course of many months. Sometimes because of Unity changes, like many editor extensions.
I have a spreadsheet with 400+ assets and try to keep track which assets (+version) are installed where. It’s common to a project to have 100+ assets. I wonder how a bigger studio deals with it. It is no fun.
Unity has hundreds of people working in so many areas. Why not a little attention to such important issues?
They could start fixing basic things like the slow store, the ability to filter the list of downloaded assets etc.
But, hey, that isn’t a source of new revenue, is it?
Most likely by not updating stuff unless there is a strong and specific reason to do so, that is worth the significant testing overhead.
Another likely approach, which @zombiegorilla may be able to back up, is that they just avoid 3rd party assets in the first place, because once you’ve got a big team working on a big project the overheads may not be worth it.
The bigger you get the more important your internal workflows, procedures and standards are, and anything that messes with those is potentially a spanner in the works. Even in the small teams I’ve mostly worked in we’d avoid mid-project updates.
Yea, generally in large and smaller teams, we avoid 3rd party stuff like the plague. Certainly never for art assets, and very, very rarely for game dependent stuff. Editor/productivity tools we’re a little looser on, as if there is a problem it doesn’t impact shipping. With having to constantly deal with device/os/market place & unity updates, it’s simply not worth adding extra dependence to most things that can be written more efficiently and specific to our needs. With all the challenges associated with shipping/updating a game, the risk isn’t worth it.
It’s a general software development and management issue, nothing specific to Unity.
If I’m working on a significantly sized project and I have a bunch of 3rd party stuff integrated, I’ve tested the integration and then built some stuff with or on top of it and then tested that. I don’t want the extra work of testing and then sometimes having to fix things just because a version number has changed.
On a case-by-case basis we’ll decide if updates are relevant and provide a bigger benefit than their cost, and in that case someone will explicitly manage and test the integration of the update. (Otherwise you’re basically blindly trusting a 3rd party with your project and/or data, by letting them change stuff while you’re not paying attention.) If you have a process like that in place a mass update function just isn’t really appealing, because there are no circumstances under which you’d use it.
I don’t think that making arbitrary, untested changes to my project is worth it by itself. I especially don’t think that making such changes en-mass is worth it.
Slow and steady is definitely my preferred approach.
Managing assets has nothing to do with. That part is easy. Quality and usefulness (and dependence) is the problem. Most non art assets are made for folks who don’t have time or skills to do it themselves are are often of questionable quality or meant for overly general purposes. It’s not worth the effort of optimizing/tailoring someone else’s work, when you can just write it yourself within your own architecture and have full control. There are a few exceptions, but not many.
I agree for the most part, like core game mechanics stuff, games that rely too much on those always get that asset flip feel to me, plus like you said the quality is often piss poor. But stuff like Node canvas or Final IK is a different story, who have time writing their own visual behaviour tree editor or IK framework
Certainly there are exceptions, TMP is a good one as well. There about two or three we have used regularly across studios. There are many more we have tried that just became a time suck and had to be replaced.
Well, it’s legit to have that preference - but reinventing the wheel on every aspect may also delay your game on shipping. Will you start from scratch a weather package, lighting solution, a character controller or AI system, your own shaders, utility packages, etc. ? Maybe you have the resources and knowledge to produce them all but not everyone can, want or have the time to produce every bit, and that’s the purpose of the Asset Store. And even having tight control on everything, it doesn’t mean that you or anyone will produce the better quality.
One way to learn how to produce software of decent quality is to study the code from top packages. At the minimum the Asset Store is a phenomenal learning experience and the fact that most assets come with source code make it very flexible and a time saver for those who want to build upon the development experience of others.
On those… definitely, always. Productivity / editor tools, more open to using if there isn’t a runtime aspect.
Of course for some, those may be useful and/or helpful and of great benefit. And they can be learning tool for some. But Unity isn’t specifically a beginner tool, and not everyone using is just learning how to make games, or doing it as a hobby. For those, simple tools from the asset store may be great, for others, not so much. The op constantly uses the term “serious” games/developers, but I think you will find that most of the time larger/successful/professional teams and projects will be using fewer and fewer third party solutions, at least not gameplay related or content ones. Certainly not “hundreds” of assets.
it has.