For context, I have over 100 assets I use in all my projects (99% tools). From small ones that add a couple of useful features to really huge ones like Gaia, Gena, Amplify Shader Editor etc…
It takes me days to import, test and set up all assembly definitions for everything.
I usually do it on a new yearly LTS version because its incredibly time consuming, mind-numbing stuff.
So what I do is I download and put all assets in a cloud drive (over 20GBs) and use symlinks to link to all projects.
It takes a while to compile and process everything with each new project, but it beats the days it usually took.
My question is, are there any new features in the works or under consideration for improving cases such as mine?
Say a way to know what version of an asset I already have downloaded, if its outdated or latest. (I currently use google sheets to keep track of that but its less than ideal)
Faster import times for when doing it all over again.
Faster import/compilation times for when linking all these assets to a new project. (Generating the data in the Library folder seems to be the biggest issue, its over 30GB)
Enforcing assembly definitions for all code in an asset. (I had to buy an asset to automate that for me because this by itself took a day at least, and not doing it increased my compilation times by a couple of minutes).
Enforce that an asset should be able to live outside of its default import folder. (I need to manually change hard-coded values in some assets in order to be able to move it around for proper project organization)
Enforce a separation between samples/demos and essential files. (So bloat can be deleted easily)
Import/update multiple assets simultaneously.
Be able to specify where exactly to import the asset. (Instead of being forced to import to its default folder, wait on a potentially long import/compile time, then move it to where you actually want it and wait again)
An easy way to remove an asset directly from the package manager.
I agree that Asset Store Asset management could be improved. But I wouldn’t even know where to start, even my own behaviour regarding assets has changed a lot over the years. Your approach, while it seems like something you would want to manage, isn’t maintainable (as you indicated) and leads to severely bloated projects and of course, bloated source control repositories.
I cannot say “I’ve been there” because before I was stopped short from getting this serious about managing assets. This was due to working in a team and maintaining those asset packs (or template projects which had all of these included) was a major point of confusion in the team, and many devs actually took that template, and stripped 80% of it simply because they often needed a quick & dirty test/prototype project, and the pre-installed assets had a noticable performance impact all around (Amplify Shader in particular). On top there used to be all kinds of errors depending on Unity version from assets they weren’t even going to use.
The whole idea of making custom Assembly Definitions … yeah, I remember doing that too. What a waste of time! It’s really as simple as moving each of these assets under the “Plugins” folder and you’re good to go if you rarely, if ever, modify them. Of course you shouldn’t be putting your own, regularly updated code under Plugins though, because Plugins is essentially a single big assembly.
The idea of symlinking assets into each (!) project is bad … no, terrible practice! Besides this becoming a nightmare when working with source control (your projects are incomplete because they rely on external symlinked files that aren’t versioned!), you can also essentially destroy existing (older) projects without knowing it until you open (or build) that project the next time, when it shows compile errors or compatibility issues because it won’t work with the now-updated assets from your cloud. If you actually release your projects to the public, and you need to make a quick fix to an otherwise stable project, you could not guarantee stability if you’ve also updated all the linked assets. That’s a support nightmare!
You may find that splitting your assets into categories (eg terrain tools, editor tools, debug tools) may be more manageable. At the same time, accept that for some projects you will be manually adding some assets as needed, and this will have some overhead during early development, but it will still be less time spent than trying to keep everything together and up to date. And will save time working with these projects as well, since more assets means longer wait times all around, including source control push / pull and making builds.
Yeah, ideally I’d have as much bandwidth and space as necessary in source control and just put everything in there.
This could be viable if samples/demos was easier to separate from essential files. Even really huge assets like Gaia, which by default is over 4GB, can go down to a few dozen MBs when all the bloat is stripped out. Most of their size is assets that are useful for testing and prototyping but that I’d replace with my own authored assets for the final project. What is actually useful to me is the code.
A simple way to .ignore these nonessential files would be a pretty big help. Say a standardized folder structure and naming convention.
There are a couple of interesting things either coming or under consideration in the roadmap that could help a bit. But I hope they have a lot more they are not sharing.
I’d like to have multiple selection support, so I can remove many packages at once.
I usually start with a cleaner template than the default ones, but I don’t feel comfortable enough to mess with internal hacks to make a custom predefined manifest…