Introducing Feature Sets to Package Manager

Unity Engine
, ,
1

Hi everyone,

Back in 2017, we introduced packages with better modularity in mind. Since then, you have been asking us how to best use them together; hence the creation of Feature Sets, groups of packages guaranteed to work well together. You can see Feature Sets in the Package manager, starting with 2021.2a19.

What you can expect from feature sets in this release:

  • Version and dependency management

  • Tested together! You don’t have to guess which package version to install.

  • Rapidly find the most common tools to use when working on a specific aspect of your game

  • Get inspired to see which other tools can help you do what you’re doing.

  • Quick Start pages access to learning resources

  • Each feature set links to a page in the docs collecting samples and other learning material.

We want to hear from you!

  • Tell us which new Feature sets you would like us to create

  • Do we have enough? Which ones would you add?

  • Would you add or remove any packages? Which ones and why?

  • Should these become defaults?

  • Would you want to be able to customize them?

  • Build your own?

  • What do you think about our Quick Start pages?

  • Are these samples helpful to you?

  • Do you have any suggestions of your own samples or knowledge that would be helpful to share?

  • Tell us how you would like us to improve this tool

  • Share your thoughts in this thread and check out our public roadmap under the tab “Package Management”.

Eager to hear from you on how we build this together,

Cathy

8 Likes
Animation Status Update (Q2 2021)
2

Quick glance and opinion:

Does it mean we finally will see the default new project without a ton of unnecessary packages? It would be about time. It’s a bit tiring to remove all not needed packages one by one every time I make a new project (which is frequent since I started to work with many “subprojects” for separate aspects of games and merge them together only the bits I intend to use into my “final” project where I build the game).

Why would anyone want to install all of Visual Studio, VS Code, Rider together? The first thing for me is to get rid of the VS ones (I use Rider only). It is not different if you use VS or VS Code either. You should add choice to this feature, so before the “Install” button I can select which one editor support I intend to use. Plus add Version Control maybe? Although I don’t use any of Unity’s solution either. For an indie and especially for a solo dev, you have one reasonably priced version control service and one working. Not a nice choice.

I would like to see support for experimental packages. One stop shop DOTS install for example.

The roadmap is empty for me.
7216141--867508--screenshot1.png

1 Like
3

Because it is pretty common to have different IDEs being used between different team members. It may not a thing for a solo developer though, so most likely you would disable that feature set in that case.

3 Likes
4

Interesting. I only worked in teams where it was decided what tool the entire team should use, but never individually, that’s kind of recipe for a hidden disaster.

That’s the thing: as a solo developer, obviously it’s not a question, but in my experience in a team it also isn’t a question because of the team decision. I guess ragged teams, where people are randomly get together under no strong management are using random editors.

3 Likes
5

Yeah, it would be great to have HDRP in a feature package where you could bundle demo scenes and such along with it for people who need it and just barebones packages with project setup with defaults for others who just need the packages/features.

1 Like
6

I would love to be able to make a set of assets that I imported into my project from the store. So that If looking for updates I don’t need to look all over the place for updates but only inside a group

4 Likes
7

I am wondering if you could extend on the concept (and goal of helping developers manage compatibility of packages) by using deep analytics for all packages, including asset store ones?

What I mean by that is that you could expose anonymous data gathered from Editor analytics containing:

  • % Editor versions actively using / crashing with / failing to build X package + package version.

  • Helps determine if they are compatible or not & which version is the most stable

  • % Users reporting issues with other packages.

  • Implement a -very- quick & simple way of reporting if a package is working or not (thumbs up/down, or similar) and if not, automatically report and cross-check package manifest with other users reporting issues to help narrow down which packages are problematic.

  • Gives more granular information on which packages could create issues with a specific package.

Exposing more analytics to everyone (including your own developers) can be a win-win solution that can alleviate a lot of frustrations while helping identify when/if packages created regressions. And it can be done right without exposing sensitive data (just use %, keep it all anonymous).

Just be mindful that the key for this to work is to implement it properly so it’s very easy to access and read the information. If you end up having the user click through 3+ levels of links / charts to get the relevant information, you have failed.

5 Likes
8

This is going off-topic, but Unity is not tied to a single IDE in any way, so there is no reason to not allow different IDEs according to each team member’s taste. Where I work we use Editor Config files to ensure standards, which is compatible with all major IDEs (VS Code, VS Studio and Rider).

3 Likes
9

This is going off topic.

I don’t care if you have a team where you all use different editors; do whatever you like.

The point being made is that any package group should include the minimal possible set of packages to run. If you want other packages, then opt-in, don’t force people to auto-opt-in and manually remove packages.

Why is TextMeshPro a default package now?

Why is Unity Collaborate a default package now?

Why is Unity UI a default package now?

The package manager already includes a mechanism to have ‘internal system packages’ like ‘com.unity.modules.physics2d’; if it is an internal system package, mark it as such; but these are not internal system packages, you can uninstall them and it’s fine.

They’re just bloated crap-ware that is added in for no obvious reason; this is highly undesirable behaviour in a package manager.

With regard to actually desired features:

> Tell us which new Feature sets you would like us to create

I am totally uninterested in your efforts to create feature sets; you’ve completely bollocked it up so far, and there’s no obvious reason to suspect you’ve learnt your lesson and are going to do a better job of it now.

Please allow the community to define these feature sets and put them on the asset store; I also manually deploy my package manifest with ‘known good configuration’; it would be nice to be able to have other folk do similar things.

You think unity should have 1st party feature sets? Awesome. I do too; but, please put them on the asset store. If they are good, they can compete with the other feature sets from 3rd party developers like the existing unity assets.

Are these defaults?

What does this question mean? Are what defaults?

Would you want to be able to customize them?

Yes.

Build your own?

Yes.

2 Likes
10

Hi there!

Thanks for taking the time to share your thoughts and feedback.

The intent of Feature Sets is to get the ball rolling on understanding what users need to start/develop a project; where the users can grab a bunch of tools at the same time to develop something with a specific purpose. The suggested Feature Sets are the ones we have initially identified on our end and will be refined with all of the collected feedback as we go.

There are plans in improving the experience in removing packages in the future release.

The roadmap is still currently “empty” as we’re working on putting the content as we do planning. However, the “Submit Idea” card allows you to express what you’d like to see in the future. Stay tuned for more updates on this roadmap; it’ll come out shortly.

Again, can’t thank enough for the constructive feedback,

Cathy :slight_smile:

3 Likes
11

Hi there,

Thank you and duly noted for this feedback!

Cathy

3 Likes
12

Hello!

First and foremost, thanks for sharing your thoughts and feedback on this, it’s truly appreciated.

Similarly to some of my previous comments I’ve posted here, the intent of Feature Sets is to get the ball rolling on understanding what users need to start/develop a project; where the users can grab a bunch of tools at the same time to develop something with a specific purpose. Obviously this takes time to refine and improve.

I’d like you to express more on the “you’ve completely bollocked it up so far”; educate me here :slight_smile:
What made you feel this way exactly?

Again, all feedback is welcome and will be noted for reference.

Looking forward to more of these,

Cathy

2 Likes
13

One more: I would put the feature sets below the packages list. We use the feature sets (if even) only at the beginning of a project (usually), but we use the package browser more often for updates and/or install individual packages as needed.

4 Likes
14

Duly noted! We’re trying to understand how often people would interact with the feature sets and when it fits into the project workflow and timeline.

1 Like
15

Look, it’s very simple.

If you install a package A, and it depends on package B, then using semantic versioning, if you install A, it should install a version of B that works.

Semantic versioning right? 1.0.0 means it’s ready right?

https://docs.unity3d.com/Packages/com.unity.mathematics@1.2/changelog/CHANGELOG.html

1.2.1 Internal (Not ready for production)

I mean, just read these changelogs:

https://docs.unity3d.com/Packages/com.unity.addressables@1.18/changelog/CHANGELOG.html

https://docs.unity3d.com/Packages/com.unity.formats.alembic@2.1/changelog/CHANGELOG.html

https://docs.unity3d.com/Packages/com.unity.xr.oculus@1.9/changelog/CHANGELOG.html

https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@10.5/changelog/CHANGELOG.html

I particularly liked the URP upgrade from 7.0 → 7.1

The render pipeline now handles custom renderers differently. You must now set up renderers for the Camera on the Render Pipeline Asset.

Don’t worry, that’s a minor point change, we’re just… adding… a breaking change…

O_o I guess it depends what you consider a ‘breaking change’ to be… if all the scripts still compile and it just breaks projects, it’s not a breaking change right?

Look, I get it, doing semantic versioning is hard, and with many different teams, maintaining strict semantic versioning is tricky; but if you depend on a package, and the version of a dependency that is installed is broken, you’ve screwed it up.

I’ve personally been affected by this multiple times.

…and look, frankly, I’m openly skeptical that the internal processes to adhere to semantic versioning are applied uniformly across all internal teams; I think just looking at the change-logs from different packages even now (and you’re doing waaaay better now than we were a year ago) that different standards and practices are being applied on different packages by different teams.

You must read the package manager forum right? …so, I feel like I didn’t have to write this long reply, since, you should already know how people feel about this stuff. …but, you asked.

After reflecting on it, specifically with regard to this feature:

  • I generally like meta-packages; they are helpful for installing ‘many at once’ dependencies (since you still can’t do this). The ‘features’ view is strange; why are these not just normal packages?

  • Wouldn’t it be nice if you could have a meta-package that included all the dependencies and a package ‘sample’ for the starter projects? Then, rather than having the project templates in the unity hub you could have semantic dependencies for project templates.

  • I still think there’s tremendous opportunity in allowing asset store authors to ‘group’ their assets into features like this.

  • I’m annoyed that the package manager still can’t show (or I haven’t figured out how to show?) a full hierarchy of the packages before installing them; the only way to know what you’ll get is to install everything and then look at the lock file.

  • The game play feature depends on VS 1.7.1, but you can go and install 1.7.2 manually if you want to. It warns you after you’ve manually upgraded, but the main package manager suggests that you upgrade; it shouldn’t do that. You should be warned before you upgrade that you’re potentially breaking an a ‘verified’ feature group.

…

PS. It’s alpha, I know, but I feel like as I write this, when I create a new URP project from the template, and the first thing I see when the project opens is:

NotSupportedException: ForwardRendererData has been deprecated. Use UniversalRendererData instead
UnityEngine.Rendering.Universal.ForwardRendererData.Create () (at Library/PackageCache/com.unity.render-pipelines.universal@12.0.0/Runtime/ForwardRendererData.cs:55)

…is some deep irony. I am so convinced you guys have this under control.

6 Likes
16

I also agree with this point, this will also remove the 100 MB demo content limit that you guys have (it was mentioned by pierred_unity in some post) when it’s included with the project itself and would allow for better showcase scenes.

4 Likes
17

Just when I think Unity is beginning to understand how to make an engine, they make it the responsibility of the random public at large again, most who have never shipped anything.

I do not think this is a good idea at all. I think all packages should work together, separated by mono and DOTS. If you make an engine, it all works together. What’s this pick and mix cop out feature sets concept?

There should only ever be 2 things:

  1. DOTS
  2. NOT DOTS

Why does this sort of feature sets thing set all kinds of business alarm bells ringing? Can I trust Unity to chart a course, when they’re asking everyone else to draw the map?

7 Likes
18

What is more, wouldn’t the same person asked about this, change their selection constantly? It would be a different answer per project, or even as the same project evolves. It would be forever-changing even for the same person. I think I would need clarification what this feature is intended to solve.

Are you talking exclusively about learning materials and not core engine features? Or asset store packages? I can see it being useful for starter assets, but these are assets, not engine features as they are made with the pre-existing engine for the purpose of accelerating someone’s game development, and I am still unsure why it would be a part of package manager.

19


Nice to see that instead of a cautionary tale, they took this meme as a guide. Now you need to make even more choices about the project you are making before you even start making it.

Docs UI Page:
7238372--871505--upload_2021-6-15_0-37-29.png

Flowcharts about GI:

7238372--871508--upload_2021-6-15_0-39-35.png
7238372--871508--upload_2021-6-15_0-39-35.png1354×548 149 KB

And now feature sets, where they more or less admit that their features are not designed to play well together.

10 Likes
20

To be fair, asking this… did you actually try the feature?

These packages are simply meta packages, they look like this in the manifest:

"com.unity.feature.gameplay-storytelling": "1.0.0",

and this in the lock file:

    "com.unity.feature.gameplay-storytelling": {
      "version": "1.0.0",
      "depth": 0,
      "source": "builtin",
      "dependencies": {
        "com.unity.cinemachine": "2.8.0-pre.1",
        "com.unity.timeline": "1.6.0-pre.5",
        "com.unity.visualscripting": "1.7.1"
      }
    },

It is literally a zero content, one-click install for several unrelated package heirarchies.

The UI looks like this:

7240286--871838--screenshot1.png

It’s obviously related to all packages not core engine features (which aren’t discoverable in the package manager anyway), and intended, see:

7240286--871841--screenshot2.png

To group ‘known working package versions’.

Well, yes. That is the ideal situation. I’d like that too. Pfft. I’ll believe it when I see it though.

1 Like