How does Unity decide what features become core, and what becomes packages?

This is just a minor curiosity! When the package manager was released, it was clear that Unity was going to move more and more from the editor into packages. This still continues now, for example, splitting Visual Studio support into a package. However, recently there seems to be a move to integrate features back into the editor, such as URP/HDRP and Quick Search.

I’m curious how they decide if a feature should be a package or integrated. I can think of pros of packages being easier to update, more optional, but with the cons of being less… integrated? I’m not too sure.

What do you guys think?

Ideally - everything should be a package, that can be disabled anytime. And initial project setup should only have basic required ones. Potentially a user-friendly tick list for packages should be presented, but that’s just a dream.

Since Unity was written as monolithic C++ engine at first (with C# wrappers added on top) - it will take time to reduce dependencies and move components to C# / HPC# side. Which will most likely happen at some point (since Burst is out of preview already for quite some time).

But don’t expect it to happen too soon and don’t quote me on that, that’s my pure speculation.

5 Likes

A dream that has already been smashed i’m afraid as Unity having already starting moving packages back into the main application. For example the Device Simulator package is now depreciated in favor of the built in solution shipping in 2021.1. I’m pretty sure a few others have done this too or planning on it.

Completely ruins the whole point of packages, not that there was much left to ruin after they deemed developers to stupid ( maybe some were ) to use experimental/preview packages and removed half of them form the package manager.

Then again in three years they’ve been unable to offer the ability to install the packages into a custom location to save space on your C drive, so all of this is unsurprising to me anymore.

3 Likes