Official Feedback request: Understanding import & export package workflows

This is a weird survey.

It seems to want to gage how much of an outrage there would be if unitypackage functionality was removed from Unity, seemingly without a replacement?

And then if most people don't really use it, would it really be okay to remove it? This is not the way to make useful software. If only the features that almost everyone uses all of the time remain in the engine, it will become the most limiting and boring piece of software ever.

And for the record, I bet most people don't use HDRP, or DOTS, or addressables.

Also, what percentage of the Unity user base use Muse? chop chop

 

That is understandable, I just don't think the confused and weirdly worded surveys you've been producing in the last 5 years or so are a good method of "asking".

 

1) This would be a fair point *if* much of what was asked was something internally unknowable to a degree that would resolve key decisions. In this case however, it can be (or at least could have been at some point) found out from dogfooding and looking at how your own asset store works and how the assets can even have sub-packages inside them. You (can) already know what would happen if the features got removed. This seems like enough information to abandon any ideas about trimming the codebase or cost-cutting - at least before an actual working replacement has been created and validated first.

2) There still has been no explanation regarding what you intend to do with the data collected. The survey itself only indicates the possibility of removal or breakage. Not a single question on how it could be made better, or if any replacements have been considered, for example.
Added to which, there was this tweet: https://twitter.com/catusmatus/status/1785338946186088449

"not necessarily" meaning, it is actually one of the options being seriously considered? What are the other options, if any?

3) The wording of some of the questions is just truly bizarre. People have already mentioned the issue with asking "how often" for critical features but what actionable information is asking "Do you export with or without dependencies more in the Export window?" supposed to give you in the likely case that both answers will have at least one person choosing it? Do you only have the money to maintain one of the options and want to remove the other if too few people use it? This is such an incredibly tiny and static part of the whole editor (including asset dependencies in particular is something also needed for making builds) that I can't imagine removing a feature like this saving any money.

 

I think there is no need to improve them. They work fine. Unity has much more serious problems. For example, a bug that causes the lighting to flicker if the cooling is turned on (it hasn’t been fixed since 2018). There is a problem with the animator shaking at large distances due to large numbers (not fixed since 2015). There are practically no solutions out of the box. Pay attention to UE (they have a metahuman). Why can't Unity make a character editor out of the box? Given that you have Ziva. There is also no vegetation. The tree system is just terrible. Compare it with TreeIt. There are no systems for creating hair (this is a real problem). There is no solution for creating animals. Why were the Heretic and Enemy packages released, which cannot be used in commercial projects? Pay attention to what developers really need, don’t remake what already works.

 

Removing package import/export would be a huge mistake that could kill the entire Asset Store.

It's crazy that it's even being considered. The whole ecosystem revolves around being able to easily package up and distribute Unity stuff as .unitypackage files.

Getting rid of it is an overreaction that would upset pretty much every Unity developer and creator out there.

 

HDRP usage is between 15-20% across all experience levels according to a recent survey by Unity (publishers have access to it, recalled from memory).

There are also reddit surveys that show HDRP use is >10% and half of BIRP with URP being the go-to RP by far - I would suspect answers are mostly from amateuer/indie devs, so the results are likely skewed to the lower end (HDRP is mostly used by experts):
https://www.reddit.com/r/Unity3D/comments/1bo95l4/which_rendering_pipeline_are_you_using/
https://www.reddit.com/r/Unity3D/comments/1765ia9/which_renderer_pipeline_are_you_currently_using/

DOTS (which isn't just ECS) and addressables are heavily used simply based on the activity on the related subforums and given how both solve pressing issues for certain projects with no other alternatives, and how they can be used piecemeal for a single optimization task.

Sorry, I just had to correct this statement.

 

they said "most". you just proved their statement

 

right, but all of your following statements indicate that everyone understood exactly what you're getting at. "no no! you understood us perfectly, but we didn't WANT you to understand us perfectly, so let us obfuscate our intentions a little more in a way that's less likely to annoy you today but will be just as unpopular"

it sounds like the options you're ready for are

• "does anyone even really use this feature that's been in unity for at least the past 14 years? we have our bloated package manager that doesn't let you modify assets in project, surely this is better and makes our working solution obsolete? hopefully the users agree!"

and

• "yeah let's still do that anyway but be prepared for people to be mad about it"

it's interesting that unity likes to deflect "but it's not the dev team that makes these terrible decisions, our hands are tied by our executives!" and then go ahead and make asinine suggestions like this, which have clearly come bottom up from the dev team. why would an exec care about .unitypackages? seems like devs don't want to maintain a core feature

please don't condescend a forum of professional programmers with marketing fluff, we aren't shareholders

 

I use unity packages a lot, mostly to ship multiple (optional) integrations in 1 unity asset.

The biggest thing for me is that there is no way to add package manager dependancies when making a unity package from right clicking. This is possible for the asset store uploader and when using git packages, but is not included with manual package generation.

Next to that the dependancies tend to break. With bigger projects it can include assets which are not used (anymore) in the selected asset you want to export.

 

Wait this is explicitly not about UPM which is where you import from the asset store.
And therefore it's also nonsense to think they gauge removing this functionality, since the mechanic is indeed the same.

That's true however. A dream would be if there were a visualisation or at least a log that explains why something was seen as a dependency because it sometimes does not seem like making sense. It does feel like there's some bug there, but it's hard to pinpoint.
When I know I'll need to export something later, I usually structure the segment of the software so that I do not need to let Unity select the dependencies.

 

why .unitypackage import/export is critical:
- its simple, fast, few clicks to export or import *1
- its offline, local, free and unlimited (like it should be, its your own files and your projects!) *2
- its easiest way to copy assets/prefabs/scenes with dependencies from one project to another project(s)
- There are no better alternatives offered (in case it would get removed)

*1: although the UI would definitely need more work to make it better (like having search, showing what files were already imported and where - instead of that useless "all files are already imported..", but you dont know where they went and what files)

*2: unlike new unity digital asset manager or any kind of hub asset importer plans

and about the survey:
Good:
- At least they asked, instead of removing & then reverting back after chaos..

Bad:
- Survey doesn't say reason/motivation, so most likely it is to force users into DigitalAssetManager on the cloud/hub
instead of allowing unitypackages..
Then again,
if the reason to consider this feature removal is "editor will be 50x faster", then i would be ready to accept this trade ; )
But nothing is mentioned.. so can only guess.

Here is also list of reactions from twitter (in short: nobody likes this, another PR disaster etc.)
https://twitter.com/unitycoder_com/status/1785303959655137631

 

Not necessarily UPM specific. What I mean is that all the asset packages are using the .unitypackage format, which could force all the developers to repackage their things into a different format to supports both the old and the new import/export flow.

 

1. I use import/export in my daily workflow to quicky export from one project to another.
2. As an asset store dev, I use it to support SRPs and probably 99% of the publishers do the same
3. I use it for support. My users can easly export prefabs, scene, etc.. and share them without worrying about loosing the references.

What's missing is a way to export from Packages, since the files are not under the Assets folder, the export will just throw an error. Being able to export from Packages would allow more publishers to move to Packages and support SRPs with the usual workflow of keepeing different pipeline assets in .unitypackages.

 

Right. But I since the files are not under the Assets folder, they will need to be unpacked in local packages.

 

In that case, if I may offer one practical suggestion - multiline text inputs.

Those 3 input fields on the second page do not expand vertically, making it difficult to provide a significant amount of information directly.
People who are determined to provide the full answer through the survey can just use any other text editor and copy over the text once they're done (after adjusting for lost line breaks) - however choosing to use a single line text input also indicates to survey participants that you're not expecting a long answer, which seems counterproductive if you actually want to find out the full extent of how Unity's features are being used, and may even be construed as a lack of actual interest in the feedback.

Thankfully there's also the forum which doesn't have this issue.

Thanks, it is a helpful (and relatable) explanation, I've also seen it happen in fairly small companies.

I'm worried however that this is a yet another side effect of the significant divide between developers and users, and the organizational layers constructed for soliciting feedback.

Ideally the mentioned "obvious response" would be instead resolved by a recommendation to go and ask directly on the forum. Now, I don't actually expect the question "who here still uses unitypackages?" to appear on the forum. If a developer actually did that, they'd learn some things rather quickly. However, this should normally prompt specifically the person interested in cost cutting to first make sure they are actually standing behind their own proposal, and then do their own prior research and either abandon the proposal or at least subsequently reword the question if after said research they still didn't find all they needed.

The issue in this case with other people like both of you requesting feedback on behalf of the developers is that suddenly it frees the developer who floated the idea from doing the prior research, as it's no longer their own reputation on the line. They won't look stupid if you're the ones asking. And while I believe the users would still fill the research gap (at the cost of user goodwill towards the company - which probably shouldn't be wasted right now in particular), the bigger issue is that there is no indication that anyone's actually whole-heartedly interested in the feedback and this whole thing ends up being one massive waste of everyone's time.

So in many ways I wish that we could just go back to simpler times when developers just talked to the users directly.

 

Oh I wasn't actually aware there's a new format that is used by UPM. I see, that makes sense.

Honestly as an user of assets, I personally dislike it when asset devs take that approach. It means an extra step at import as well as when updating the asset.
Why not simply put the different SRP versions in separate top-level directories and let the user uncheck the ones they don't want?

You cannot talk to all devs though and with an extremely versatile software like Unity you run risk of talking to only a slice of the users. E.g. talking to devs who hardly ever use a workflow that uses .unitypackage files.

 

Not really on option because in most cases we need to override the existing assets.

Imagine an art package with 100 prefabs with 100 different materials. By unpacking a unity package you can simply override them. Going the other route would mean 100 prefabs for each pipeline, 100 materials for each pipeline, different scenes recreated with the correct prefabs and so on.

 

That can't happen as long as Unity is a big company, because as long as they are a big company, instead of doing their best to try and fix and improve most of the things, they apparently think they have time to go "hmm, yes, but what if we removed basic functionality that has been there for a decade".

 

just don’t touch it, everything that has been touched broke something

The only thing that could be improved is to show the files of a package if those are already imported, because right now it shows nothing

 

+1 for this. It's so annoying to not know where those already imported assets are.

 

I find packages a very useful and fully functional part of unity. I have a "two project" approach to development where I have one project which is kept clean and another fills up with crap. I use packages to move only essential useful elements from "crap" to "clean".

Removing support for them would break many, many assets in the asset store and generally create havoc IMHO.

 

destroying Unitypackages would be the next level of insanity that would finally make me switch engines.

 

I like to warn against usage data as a metric of usefulness in general.

How often during driving do you use the key of the car ? Only once to start the engine, after that you don’t touch it until you stop the engine.

Does this make the car key less valuable because it used only once?

 

Think they have really accounted for that with this survey by asking explicitly for what workflows would suffer.

 

Where I work, we usually use Unity package files to share assets and project templates. There is no reason other than them being a "Unity-native" feature (I know they're just tar/zip files in disguise). Also, there is a certain "trust" associated (at least, from what I have experienced before) with Unity package files compared to "raw" archives. I even created a tool to create Unity packages from the CLI without having Unity installed (I use it to automate some asset-sharing workflows). The point is, that Unity packages are OK.

 

Of all things to kill off meanwhile I've been wanting to know when will unitypackages and asset imports actually provide a popup screen that is just barely above useless in showing me what files are getting changed and where... especially in project settings as a screen of what project settings will be changed on import would be nice.. instead of going ahead and finding myself in compile error hell with no undo revert from the package image..... waiting years for maybe some sort of additional difference tool.. to actually see if the change is worth accepting in the package import or at least being able to fully see all the changes before importing... but no just remove whole thing unity go ahead, import/export of files into a unitypackage is the thing to be killed off.<sarcasm>.. at least it would kill dozen feature requests related to actually improving the whole import/export.

At this point SRP pipelines and pink shaders from assets that support URP/HDRP but often only have examples/demos done for birp, still plague your engine not because of unitypackages but because SRP's still suck and people still support built in over the mess that has been caused by URP/HDRP.

maybe just keep working on UPM and improve that with I dunno the same feature improvements I'd want with unitypackages, improve asset store etc.. before wanting to kill off unitypackages.

 

Frankly, you need a team that actually makes, and supports, a long lived game across multiple platforms, with third party middleware and all the bells and whistles. That you have to ask these questions at all shows a level of institutional blindness on how certain features are used that can only be improved by dogfooding the engine.

 

Mulling about this a bit more, is there no part in this where someone asks "does the software make sense if we remove this feature?". Because people might not really use a feature all that often, but it can be the final step in a list of other features that not a lot of people get to, but removing it invalidates everything that comes before.

Like presumably you could save X by removing any feature, and if the only metric is how many and how often users use it, the resulting software doesn't make sense.

Seeing as Unity has been going survey crazy for many years now and in the same time Unity's been completely blowing it with the replacement features, software fragmentation and acting on what your users want, how do you think that strategy is working out, really? (and should this be the next survey you do?)

 

https://forum.unity.com/threads/display-resolution-dialog-deprecation.793611/

This is why I’m scared of the surveys and never fill them in, they somehow justify ( not in my book ) the removal of perfectly useful features, and they never seem to return after removal.

https://forum.unity.com/threads/status-of-unity-remote.882658/#post-5898926

And other one that almost was removed.

 

I work with 3rd party artists who do all the race tracks and VFX/UI for my racing games.
They do not have source code access to my projects.

They provide everything to me in Unity Packages, such as a new racing track scene, so I can import it into my game.
Taking this away would be a huge workflow killer and I have no idea why this is even a consideration.

 

People are freaking out because trust is in short-supply, everywhere, but esp here & now. Sunsetting features is a totally normal part of software development (doing it at my day-job right now!) but naturally without trust or context, ppl will be suspicious. The times we live in, unfortunately.

Answered the survey, but tldr: unitypackage is a great exchange format between asset-creators & consumers, for samples, variants, and pre-release patches. I also like to use it for custom support of things like URP and Input System before I've upgraded wholesale into those systems.

Unlike zip/tar, upkg integrates well into the existing project hierarchy, showing what will be updated and/or replaced in-situ on import. Fills a good gap for things that are not contextually-related enough for a dedicated branch in source-control.

 

As the developer of Asset Inventory (an indexing tool for all packages you own, be it from Unity or Humble or Synty or custom) I have quite a big community and can definitely say: custom packages are in use big time. People use them for all kinds of purposes, be it by purchasing assets from other stores to managing their own production and sharing assets across dev teams.

Also sub-packages are super important. I just created a feature to also index sub packages and they are not only used to have URP/HDRP variants but also contain many other aspects of a package. These are all custom packages in that sense.

Just from my statistics there you can see out of my 1783 assets, 509 contain sub-packages, totalling 2067 sub-packages, typically in the form of .unitypackage but also .zip.

 

[Edit] : actually the above post shows something really interesting

My honest opinion : I think unity should make a live service game, not only tech demos. This what is reflected in your post and this survey, you don't know enough, you should know a bit more and only edge cases to handle. This helped your direct competitor, a lot. I think it's a safer bet. Yes it costs money but so does creating stuff that will never be used and deprecated because of low adoption. Theory vs Practice. Devil lies in the details. Timeline is great but, Cinemachine is great but, Input system is great but, with a little more polish they would be killer tools. A live service game would help standardize and direct your efforts towards usability and overall enjoyable workflows.

On the topic :
- I use packages because they are shipped within the asset store.
- Also because I'm not allowed to copy/paste between two unity instances.
- I find them not really practial.
- They lack version handling.
- Slow archaic UI
- Asset store packages should not bloat my project but behave like the new packages as external references regardless of if it's code or assets.
- Still I should be able to have any overrides I need on these package (delete stuff, duplicate and move around while keeping reference and minimal footprint, modify, and still be able to upgrade them).
I do this a lot with the new packages, fork on a public mirror the package code source, it's very very convenient to have it git based. I can upgrade when needed while keeping my additions, create branches etc, all atomically.

At a point I'm almost considering creating my own tool that auto converts .unitypackage to the new package format to allow this. Possibly there is already an asset/repo doing so as it's an obvious win.

Best of luck

 

Looking forward to the takeaways and interesting points from this!

 

I'm happy to avoid the photoshop situation of 20+ years of bloat and duplicate features.

but the problem with photoshop is often the new things is never fully complete or a replacement. So you have a new partial feature and the old functional but archaic feature at the same time. photoshop is an extremely frustrating bloated program of duplicate stuff all over the place and stuff just not working together.

Packages are super important, but dependencies can be extremely flawed. Updating an asset it's often easier to delete the folder before importing the asset to fix any removed or moved assets/scripts. So I know there's improvement to be made. And I also know people can be stubborn like people who still try to use asset bundles instead of addressable.

Whatever you do especially for stuff like this, the superior version needs to be clear, complete, and preferred before the old depreciated.