[Opinion] Unity and Package Manger Influence

Unity has had some awesome releases, and they have made a lot of progress in a lot of areas over its lifetime.
It seems like unity’s development is at an all time high since I first started using it (unity 4).
I loved unity 4, unity 2017, and unity 2018.
Unity 5 and 2019 were disappointing in terms of quality control.
As for 2020 I haven’t been using it (has a bad reputation from what I hear).

How do others feel about the state of unity? When did it feel like unity was at its peak in development?

For me:
Things are moving super fast which is really exciting. Scriptable Render Pipeline is an amazing approach for democratizing some of the most complex parts of graphics programming. This in conjunction with Shader Graph are major enablers for game development. The new input makes porting input systems from X sets of control schemes on one system to another system painless. The new Visual Elements system is making UI design way more scalable and design focused by leveraging workflows from front end web development (one of the more entry level programming environments).
There are a ton of awesome features I didn’t really touch on.

What has enabled this fast paced development is the package manager system. Which it has unfortunately lead to some dramatic drops in quality control.
2017 and 2018 have been some of the best releases in comparison.
We got batched physics queries, and they actually worked!
They optimized a ton with a focus on light and fast applications.
Light mapping finally worked.
Sykoo made good content.
Brackey’s was still making content.
I didn’t hate Unity 5, but it really felt like there were a lot of growing pains in the transition from 4.
- improving light mapping
- deferred rendering improvements,
- two particle system
- deprecating component accessors
Unity 4 was extremely approachable, the focus felt like it was entirely how do we make it as easy as possible for someone to complete the roll-a-ball tutorial. It felt very honest with setting expectations. It included starter content that could be imported and was ready to use to play around with and make content.
There wasn’t a 100 ways to do the same thing. Well there kind of was ( they did support 3 scripting languages).

Giant updates aren’t great as demonstrated by unity 4 to unity 5. Too much changes between the two and it invalidates a lot of the community support that was out there.

On the opposite extreme there is package manager. The micro updates suck because you deal with package updates that yo-yo from partially broken/feature changes to somewhat stable. Often times you end up with outdated community support. The same question is asked 5 times over 3 months. Each one with a Unity staff response that contains different information. Developers are often gaslit by the [stable] release tag in package description. Tutorials become outdated rapidly. DOTS is a major offender in this area.

Yearly releases are great because they are largely stable, only incorporate a few features at a time, and have well written timely documentation. Usually community support is pretty solid because only a little bit has changed and it hasn’t invalidated much of what was already out there. Enough Unites have occurred that provide useful demonstrations of the changes. Content creators that make tutorials have had enough time to try out the features and make videos.
There are a good number of people who were testing out the beta, or watching unite talks about new systems. The features are quickly vetted by the community, which is super helpful because then fellow devs know to not bother with a feature until it is more refined. Updates from .1->.2 are useful because all the fixes and changes can be conveyed in a reasonably sized article.
Unity roadmaps with yearly updates are also way more helpful.

 

If you don't want new, unstable features, why can't you just use 2019.4 LTS? I don't understand.

 

There are unity sample projects for 2019 LTS that don’t work because of issues with packages that are included through package manager.
The template projects for unity use packages automatically.
The workflow is embedded in 2019.
LTS is a great system for stable releases, but the package system circumvents it. That is the core issue.
Package Manager is a great concept, and it works really well for organizing complex projects. Having it as a system for users to try alpha/beta features is a good idea too. Using it as a tool for open source community packages is also a really good use case.
The issue comes in when it is core unity features that persistently live in packages.
Key features are being boxed into the packages instead of incorporated into the engine.
Take the new input system for example.
It is a core feature that has hooks in the engine, but for some reason is treated as separate.

 

It was approachable, for sure, but Unity back then didn't support large projects anywhere near as well as it does now. Finishing a roll-a-ball tutorial does not get a large project shipped. And back then, while Unity was indeed nice to get into and great for small things I'm really not sure it's what I'd pick for a large project.

While there are clearly teething issues at the moment I'm personally quite excited to see where this goes. Package management is a pretty standard part of software development in some other environments, as is managing dependencies - which is where a lot of the concerns you've raised stem from. Many people who use Unity have no experience with any of that stuff because their only experience in software dev is in Unity. Everyone starts somewhere, so no worries there, but rest assured that this stuff is generally standard for software development for good reasons.

Yes, managing packages is less user friendly than not having to manage packages. But as projects grow in scope and complexity having a system to manage that stuff is far better than either doing it all manually or taking the kitchen sink approach.

What Unity could definitely do better is their current learning and onboarding materials. Yes, Unity now has a bunch of complex stuff, but there is no reason that new users need to use or understand it. Doing a roll-a-ball tutorial in Unity 2020 does not need to be harder than it was in Unity 4, because sensible defaults and clear instructions can cut out basically all of the extra complexity. That stuff only gets in peoples' way because they don't know what they can happily ignore.

Alas, for whatever reason, the entry-oriented documentation and onboarding by all accounts* is... lacking. And based on my experience last year with the new input system Unity doesn't consider having effective onboarding documentation to be a necessary part of "finished".

* I haven't had to use it myself for 10+ years

 

All fair points in regards to packages in other software development. That is one of the reasons I am for package manager. I like the simplicity of incorporating 3rd party content. I am just not a big fan of unity internal using at as a release tool for features.

I agree with that on boarding material is a big issue. In previous versions it felt like when a feature was added, there was a wealth of content around it. Even the scripting docs examples were awesome. They were well commented and provided observable results.

 

I have a project on 2020.2, with heavy ECS usage, and I'm still using the old Input method, hadn't even tried the new one until 10 minutes ago (in 2019.4 - worked fine). From your perspective it's "core," from mine it's extraneous.

(and for what it's worth, yes DOTS has been extremely frustrating to work with, but it's very definitely still new and unstable so that's not unexpected.)

That can be extended to many things. I bet most don't want to see the "Jobs" or "DOTS" menu items at the top of the screen if they're not using them. Similarly URP/HDRP are in and of themselves a whole can of worms, so it's probably better than Unity keeps them separate unless someone's intentionally delving into them. Most of the packages I see in the Unity registry are things I'd only want to bother with if I need them. I don't need the Animation Rigging package for my text-and-audio-based Android app. I don't need Cinemachine for my top-down shooter. I don't need XR packages for, well, anything.

 

I'm of the belief that more people would be fine with it if they could define the default set of packages rather than having to add them to each new project by hand. You can create your own template but it's a hassle to do and you have to recreate it for each release. If I had an understanding of how it worked I'd try my hand at creating a custom template tool but like many things in this engine there is little to no documentation available.

 

Pretty much this, why am I adding the same 7-10 packages every time I start a project still? Just have some sensible options to pick this at the start with a default one selected already, and be done with it

 

There was a survey recently about Project Creation that collects data on these subjects. I think it'll arrive with UnityHub 3.x

 

I think I may have not been clear on what I meant. The Input system (not necessarily new or old) is integral to the engine. However only the old input system is part of the standard documentation.
I liked how they handled integrating the shuriken particle system. They created a porting tool for old particle system.
They created awesome documentation and tutorials for it. Then something like 2 years later they deprecated the old particle system.

They have some of the best communication with their community. This is one of the strengths of the Unity team.
They always seem to receptive to feedback and strive to make improvements. In my initial post I said something to the effect that the same question is asked 5 times in 3 months, and a unity staff member will provide an answer to each.
If there is an issue, the team is quick to respond to the community.

The lack of documentation has been a recurring theme it seems. I do hope there is a push to bring up the standard of documentation for packages. This would make them way more tolerable. It would be nice if there was blog posts for each update that outlined the changes as well.

 

Yes, user-defined project templates would be nice. Until then, you can do this: create a new project, install the packages, but don't work in it. Leave it be. When you need your template project, just duplicate it, add it to hub, add it to your version control if needed and open up in a newer version of Unity. In theory the project should upgrade without a glitch, since you have no moving parts in it (since you haven't worked in it) of your own and also the packages should be updated to the latest stable versions. At least I was able to pull this off twice already (yeah, I'm making some new test projects for various reasons nowadays... ).

---

If you want the simpler way, just store the relevant package manifest file content somewhere and after making a new project, open up the file and add them on one go (I'm not sure if the packages update automatically at this time though...)

 

I will say this: Getting "500 Internal Server Error. Something went wrong. Please try again later." while trying to download something is extremely frustrating.

 

I am not convinced that 6our 7 packages are same as my 7. So your defaults could be hurdle for my defaults.

By default there is lots of thing missing in settings as well, for need of the project. So doing that every time, with new project, would be really pain.

But @Lurking-Ninja had provided simple solution, which I also used past couple of years now.

 

Yeah but thats why I am saying give the users options to pick them at the beginning, a list of packages with ability to add checkbox to each to include, so that it does all this during initial import instead of initial import and then you have to open packagemanger and import more stuff

 

Sure that could work for packages.
But unless I miss something, this still does not solve the issue with the custom editor settings, or whatever else may come with project as "default" for a user.
Unless we can have that as an option to select too, when creating "default" template.