The State of Unity & Packages in 2020

[smcclelland]

Hi all,

We have seen your forum posts, blog comments, tweets, and direct feedback to our support channels and want to have a candid discussion with you about the current state of the Unity product experience. We’d like to dig in a bit more and gather requirements that will help inform solutions we think might help address your concerns. To ensure we’re on the right track, we have a few questions we’d like to ask you to kick things off and will use this thread as a means of hearing everyone.

Some core product questions we would like feedback on:

• What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?
• When you see a new Unity release, what is your expectation of quality?
• Do you expect different levels of quality or completeness based on the release distinction?
• What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?

And more package specific questions we would like feedback on:

• When we say something is in Preview, what does that mean to you? Why do you feel that way?
• Does the expectation of quality change when you see something in Preview? What drives you towards using something in Preview? What keeps you away from using something in Preview?

If there are items that exist outside of these questions you would like to raise as well, please do so. Your opinion matters and we want to make sure we can gather requirements from every one of our users.

We have also put together a brief survey to help get some further insights into how the community feels about packages in general and would appreciate your input on this.

Take the survey

The questions may seem a bit odd or repetitive but they are structured in a way to help us understand how would you feel if you had this functionality, how would you feel without it, and how important is this functionality to you as a user.

Best Regards,
Unity Product Management

[system]

So, I took a 2 month break from Unity because it was so unstable; and, almost every package I used broke or had serious bugs. I now return and within 10 minutes of using Unity it crashes. You are failing on one of the most important metrics of a tool that people want to use on a daily basis - stability. Enough new features, etc. - focus on stability and quality. You are making the rookie mistake of every early-stage company of trying to be everything to everyone and failing to provide a tool that is useable by anyone.

[MadeFromPolygons1]

@smcclelland

…snip…

Im over the moon that you are engaging us about this . Been a big issue for a while now and glad to see its being noticed by the product management team. I know @willgoldstone and some others from unity have been active in this regard and it always is greatly appreciated.

I know it sucks to hear lots of criticism but trust me when I say its really good that your engaging us and I hope it continues! Hopefully the feedback we provide will be of some use to you guys to get unity back to where it should be (the best free and commercially available game engine on the planet)

EDIT: forgot to actually answer the questions, they are below:

Some core product questions we would like feedback on:

• What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?

Right now it doesnt really mean a lot. My understanding was it was meant to be 3 tech releases and 1 stable supported release, problem is due to constant changes 2019.4 is mostly useless as a lot of core needed stuff is coming in 2020 cycle, so if you want stable you have to jump to a tech release. Making all of this pointless. This is due to certain packages requiring certain versions of unity, meaning you choose between feature support or stable editor. Sometimes you choose between editor stability or feature stability. Not a fun juggling act. Less so when doing it at work where there are deadlines and real repurcussions.

• When you see a new Unity release, what is your expectation of quality?

Its actually very low. It used to be higher. When we first heard about alpha opening up I was over the moon as I thought the early exposure would mean better QA that takes place over a longer period of time. It actually seems that all that is happening is you are rushing releases out earlier now and shoehorning needed features into later releases with a lot more frequency.

• Do you expect different levels of quality or completeness based on the release distinction?

Yes. I expect alpha to be feature complete, beta to be content complete (user interfaces, usability,documentation on new features), and released version to be stable. That is a world away from where we are, is it not?

• What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?

Again stability, which doesnt really exist anymore. I believe doing only 2 tech releases will help somewhat but not fix the problems altogether.

And more package specific questions we would like feedback on:

• When we say something is in Preview, what does that mean to you? Why do you feel that way?

It means it is an early access version and bugs should be expected. I would not expect design and architecture to change dramatically otherwise it isnt ready to preview. In that case make a seperate distinction between “alpha preview” and “beta preview” or just do alpha and beta and released for packages as preview seems weird - your software developers…

• Does the expectation of quality change when you see something in Preview? What drives you towards using something in Preview? What keeps you away from using something in Preview?

My expectation whether in preview or not is to expect serious stability issues, incompatability issues, usability issues and performance issues. Didnt used to be that way but slowly over last 6 months I have reached this point.
EDIT2: PS, despite the criticism dont take me as a negative user. I love unity and always will, but being honest about where we stand is the best approach IMO. Everything I write as feedback, I do so in hopes to help make the engine better, not because I enjoy whining (which I really dont)

[smcclelland]

So, I took a 2 month break from Unity because it was so unstable; and, almost every package I used broke or had serious bugs. I now return and within 10 minutes of using Unity it crashes. You are failing on one of the most important metrics of a tool that people want to use on a daily basis - stability. Enough new features, etc. - focus on stability and quality. You are making the rookie mistake of every early-stage company of trying to be everything to everyone and failing to provide a tool that is useable by anyone.

Thank you for this! Can you elaborate on some of the packages you were trying out and off the top of your head some of the major issues you found? One of the big challenges with so many packages is us understanding the mix of packages and how users move between packages and whether that’s a fluid experience. I’ve captured a note around stability of the product as a whole and quality of our releases which raises another question I have around LTS vs non-LTS and whether there’s an expectation difference there around quality and stability? i.e. if you download Unity 2019.1 and it’s a bit unstable how do you feel vs if you download 2019.4 LTS and it’s unstable? Thanks again for the honest feedback!

[JoNax97]

I won’t be answering all the questions because I very much agree with @MadeFromPolygons_1 so i will focus on what I personally feel the most.

What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?

I want to emphasize that due to package requirements as well as QoL and workflow improvements requiring the latest version, it feels useless to stick to LTS. Some times things are needed for a certain aspect of the engine to work properly, that are not strictly considered bug and thus they don’t land in LTS. With packages this is worse, as sometimes actual bug fixes land in new package versions that depend in new engine versions.

When you see a new Unity release, what is your expectation of quality?

In it’s current state I think is very difficult to make a sensible estimate as so many features, and therefore potential instabilities come from packages. Normally I don’t expect a major version to be consistently stable until 2 or 3 patches. i.e: 20XX.0f1 is usually closer to beta than to final release.

Do you expect different levels of quality or completeness based on the release distinction?

No. If anything I think in some cases the focus on stability of LTS versions has brought problems: The release schedule of new features, combined with the strict policy of only backporting bugfixes results in cases where a feature is half-baked for 2 years for those sticking to LTS. Most clear example being the new prefabs introduced in 2018.3.

[MadeFromPolygons1]

@smcclelland

Thank you for this! Can you elaborate on some of the packages you were trying out and off the top of your head some of the major issues you found? One of the big challenges with so many packages is us understanding the mix of packages and how users move between packages and whether that’s a fluid experience. I’ve captured a note around stability of the product as a whole and quality of our releases which raises another question I have around LTS vs non-LTS and whether there’s an expectation difference there around quality and stability? i.e. if you download Unity 2019.1 and it’s a bit unstable how do you feel vs if you download 2019.4 LTS and it’s unstable? Thanks again for the honest feedback!

If I download 2019.1 and its unstable I think well okay thats not the LTS version. If an LTS is unstable, it makes me want to flip tables and scream at someone because we often wait an entire year (somtimes longer) for the “stable” version and thats exactly what it should be. To be honest however, if each .x release has an alpha, beta and release phase, it doesnt make sense that anything other than extra tech should be unstable by time of release. Which again, highlights how the current release structure doesnt give anywhere near enough breathing room for the teams to provide the quality expected. I would do 1 tech release, 1 stable release. So you save up all the tech and release that as 2020.1 and then work through the year making it stable to do 2020 LTS.

The package system should make this much more feasible now as you can roll out new features seperate from the editor features etc. But if we are doing packages, what is the point of tech releases anyway? isnt all tech packages at this point?

[smcclelland]

@MadeFromPolygons_1

…snip…

Honestly, criticism and feedback is a good thing! If we’re not getting it, even the harshest of it, we’re not doing our jobs

1. Interesting point regarding the juggling of feature stability vs editor stability. Is this something you’ve noticed has increased with our inclusion of packages?

2. That’s unfortunate to hear. Was your expectation around the alpha that you would have access to things earlier in development and help drive things over a longer period of time? If you see something in Alpha that’s not ready or moving in the right direction, how would you want us to handle that?

3. To be honest, yes. In what sense would you want Alpha to be ‘feature complete’? For example if we gave you a new brush-based terrain system would you expect that to be completely done when it shows up in the first Alpha? Have some missing functionality that’s added over time? And what about Beta? Mostly bug fixes? Any API changes?

P1. Interesting. So if you saw a 0.5.0-preview you would expect some bugs and no major changes to happen until what point? Would you expect additional functionality in a 0.6.0-preview? What about if you were using a 1.0.0-preview? Does the version number have any significance or meaning to you as a user for what’s included in the package or different between versions?

P2. That’s fair. So even if we say a package is Preview, Verified or Released, there’s still a lingering concern of stability, incompatibility, and usability issues?

This is great feedback and I just want to say thank you for being so candid and thorough with this response!

[system]

@smcclelland

Thank you for this! Can you elaborate on some of the packages you were trying out and off the top of your head some of the major issues you found? One of the big challenges with so many packages is us understanding the mix of packages and how users move between packages and whether that’s a fluid experience. I’ve captured a note around stability of the product as a whole and quality of our releases which raises another question I have around LTS vs non-LTS and whether there’s an expectation difference there around quality and stability? i.e. if you download Unity 2019.1 and it’s a bit unstable how do you feel vs if you download 2019.4 LTS and it’s unstable? Thanks again for the honest feedback!

Gaia Pro, Terra World, and almost any program with modified shaders. And, almost anything I use with the HDR pipeline is a disaster.

I am currently using 2019.3.3f1. When I was having troubles earlier, it was with earlier version of 2019. However, today with Gaia Pro and 2019.3.3f1, I generated a terrain and then it crashed.

I assume by 2019.4 LTS you mean 2018.4 LTS. I used the LTS versions when I teach; however, using even the stable versions with the 3D game you had with Ellen was a mess. A lot of your tutorials/template games you put out are not kept up to date, so most of them become quickly useless as others have mentioned above - features/functionality don’t match.

Finally, I am trying to sort through my assets in the editor asset store and it keeps jumping to the top - obviously some sort of bug.

[MadeFromPolygons1]

@smcclelland

1. Interesting point regarding the juggling of feature stability vs editor stability. Is this something you’ve noticed has increased with our inclusion of packages?
   Yes, its solely happened since packages have come out. And again, its not all of them, just some are super unstable and dont gel good with the current editor version.

2. That’s unfortunate to hear. Was your expectation around the alpha that you would have access to things earlier in development and help drive things over a longer period of time? If you see something in Alpha that’s not ready or moving in the right direction, how would you want us to handle that?
   I mean I just expected that by the time it releases there will be docs and serious testing involved. What happens during alpha isnt the main issue, its what doesnt happen during beta and release. Beta should be when all the docs are being made which in turn will highlight usability issues and in turn will lower user pain which in turn will lead to no need for this sort of conversation to take place in the first place.

3. To be honest, yes. In what sense would you want Alpha to be ‘feature complete’? For example if we gave you a new brush-based terrain system would you expect that to be completely done when it shows up in the first Alpha? Have some missing functionality that’s added over time? And what about Beta? Mostly bug fixes? Any API changes?
   I expect alpha to contain all the new features that are meant to come out, but they may be buggy and unusable (like the UI for the feature may not make sense or stop it being used well) and be undocumented. I would expect beta to be bug fixes and building the usability (including a new UI if needed, creating docs and releasing these to public so they can comment and say “that makes no sense, I dont get how to use X” or “That shouldnt be used that way, would be better this way” and then make those ammendments if needed. I would expect public release to have contained all the above so that its usable from day one with proper docs and stability (as much as possible, not expecting miracles I understand how commercial software works - nothing is ever bug free!)

P1. Interesting. So if you saw a 0.5.0-preview you would expect some bugs and no major changes to happen until what point? Would you expect additional functionality in a 0.6.0-preview? What about if you were using a 1.0.0-preview? Does the version number have any significance or meaning to you as a user for what’s included in the package or different between versions?

No I would still expect changes, but I mean for instance if a system has been built to be say LWRP, I dont expect the entire architecture to change after its gone into preview (turning into URP - just one example ofcourse - lots of this all over the place). That shows serious lack of foresight on the design part. Again, early docs would highlight this as users would tell you their pain earlier if they knew how to use the system. The version number means nothing really, but when a flashy blog post comes out saying something is in preview, it shouldnt have massive fundamental changes (features added or removed or completely changed) after that point unless its literally do or die. Once people read that stuff they get excited and make plans based on it, so big breaking changes and u-turns on design decisions will affect them and create user pain - even if justified.

P2. That’s fair. So even if we say a package is Preview, Verified or Released, there’s still a lingering concern of stability, incompatibility, and usability issues? Yes absolutely, but I do believe that the user engagement on your part (you and rest of unity team) and the new release structure proposed will help somewhat.

[smcclelland]

@JoNax97

I want to emphasize that due to package requirements as well as QoL and workflow improvements requiring the latest version, it feels useless to stick to LTS. Some times things are needed for a certain aspect of the engine to work properly, that are not strictly considered bug and thus they don’t land in LTS. With packages this is worse, as sometimes actual bug fixes land in new package versions that depend in new engine versions.

If you don’t mind me asking, is this ideal for you? If not, is there an ideal world where you can get QoL and workflow improvements without having to jump through hoops? What’s the blue sky situation here if everything “just worked” for you?

@JoNax97

In it’s current state I think is very difficult to make a sensible estimate as so many features, and therefore potential instabilities come from packages. Normally I don’t expect a major version to be consistently stable until 2 or 3 patches. i.e: 20XX.0f1 is usually closer to beta than to final release.

And does that expectation also carry over into packages when you see an update? What do you look for to tell you a package is “good” to install or upgrade? Are there other metrics of evaluation you use for deciding on an editor version to upgrade to?

@JoNax97

No. If anything I think in some cases the focus on stability of LTS versions has brought problems: The release schedule of new features, combined with the strict policy of only backporting bugfixes results in cases where a feature is half-baked for 2 years for those sticking to LTS. Most clear example being the new prefabs introduced in 2018.3.

Interesting. So in cases like this, the strict rules of backporting doesn’t improve the situation for you but instead puts you in a more precarious decision of sticking to the LTS with the missing features or jumping to the tech releases to get the new feature enhancements? What’s the ideal situation here or is there one from your perspective?

Thanks!

[smcclelland]

@MadeFromPolygons_1

If I download 2019.1 and its unstable I think well okay thats not the LTS version. If an LTS is unstable, it makes me want to flip tables and scream at someone because we often wait an entire year (somtimes longer) for the “stable” version and thats exactly what it should be. To be honest however, if each .x release has an alpha, beta and release phase, it doesnt make sense that anything other than extra tech should be unstable by time of release. Which again, highlights how the current release structure doesnt give anywhere near enough breathing room for the teams to provide the quality expected. I would do 1 tech release, 1 stable release. So you save up all the tech and release that as 2020.1 and then work through the year making it stable to do 2020 LTS.

Right. This is something I’ve heard echoed from a few customers is giving some more breathing room in the product development process and putting more time into hardening releases. Should tech releases and LTS be held to different standards still?

@MadeFromPolygons_1

The package system should make this much more feasible now as you can roll out new features seperate from the editor features etc. But if we are doing packages, what is the point of tech releases anyway? isnt all tech packages at this point?

It really depends. A lot of the “core” is still in the main codebase and then we have various circles of dependencies that build on top of the core as packages. Some of these have deep links into the core engine while others don’t have that dependency. What we often see is teams closer to core have to move in sync with the editor releases while teams not reliant on core have a bit more latitude and freedom to update outside of the editor cadence. One of the major goals of the tech releases was to drive more innovation and early preview technology for example. Did it come across that way as a user? I’m curious how the messaging of tech releases came across from the users perspective.

[MadeFromPolygons1]

@smcclelland

Right. This is something I’ve heard echoed from a few customers is giving some more breathing room in the product development process and putting more time into hardening releases. Should tech releases and LTS be held to different standards still?

I actually dont think LTS makes sense at all. As in I dont think you should declare which version is long term supported ahead of time, that is causing a problem where major stability problems seem to get pushed back as “theres a stability focused release coming” but because the stability focused release is at the end of the cycle, its never actually stable as there is no time for the team to ensure 3 releases worth of stuff becomes stable in like 3-6 months time.

I would just make unity releases without the LTS moniker, and at the end of the release cycle pick the latest greatest to become LTS and continue to support that for 2 years. I also didnt know LTS and tech have different standards, it feels like they are the same right now?

@smcclelland

It really depends. A lot of the “core” is still in the main codebase and then we have various circles of dependencies that build on top of the core as packages. Some of these have deep links into the core engine while others don’t have that dependency. What we often see is teams closer to core have to move in sync with the editor releases while teams not reliant on core have a bit more latitude and freedom to update outside of the editor cadence. One of the major goals of the tech releases was to drive more innovation and early preview technology for example. Did it come across that way as a user? I’m curious how the messaging of tech releases came across from the users perspective.

I think the idea was understood but it doesnt really feel that way in practise. It feels like instead of worrying about upgrading a single program, we have to worry about upgrading it AND various packages and it creates a compatability depedency spaghetti that is hard to debug at times.

I think this is probably making it harder for unity QA to determine things too. I havent heard of anyone not being stuck having to update at some point or another the last year. Before I could remain on an old but stable version for as long as needed, but due to features in packages - I now often am forced to update due to a package I started using months ago now needing it to remain compatible.

The SRP and shadergraph packages are the biggest culprits in this regard. I am pretty sure that a massive portion of user pain comes from those alone.

[system]

“I would just make unity releases without the LTS moniker, and at the end of the release cycle pick the latest greatest to become LTS and continue to support that for 2 years.”

^^ This nails it. And, make all of the packages be stable on the current LTS or they are marked deprecated. That way I can quickly set up projects and do what we all love, which is - creating games. Otherwise, I am constantly being a beta-tester for all kinds of other people’s projects, including the Unity game engine.

[smcclelland]

@MadeFromPolygons_1

Yes, its solely happened since packages have come out. And again, its not all of them, just some are super unstable and dont gel good with the current editor version.

Thanks for this - if a package is not compatible with the current editor version, should you be able to install it? What would you expect that workflow to be if you saw a list of packages or versions and some were not compatible with the current editor version?

@MadeFromPolygons_1

I mean I just expected that by the time it releases there will be docs and serious testing involved. What happens during alpha isnt the main issue, its what doesnt happen during beta and release. Beta should be when all the docs are being made which in turn will highlight usability issues and in turn will lower user pain which in turn will lead to no need for this sort of conversation to take place in the first place.

This is great insights and something we’ve been discussing a lot with our documentation group. How much documentation would you expect to have in the beta phase for say Beta 1?

@MadeFromPolygons_1

I expect alpha to contain all the new features that are meant to come out, but they may be buggy and unusable (like the UI for the feature may not make sense or stop it being used well) and be undocumented. I would expect beta to be bug fixes and building the usability (including a new UI if needed, creating docs and releasing these to public so they can comment and say “that makes no sense, I dont get how to use X” or “That shouldnt be used that way, would be better this way” and then make those ammendments if needed. I would expect public release to have contained all the above so that its usable from day one with proper docs and stability (as much as possible, not expecting miracles I understand how commercial software works - nothing is ever bug free!)

Great summary of expectations for the lifecycle phases.

@MadeFromPolygons_1

No I would still expect changes, but I mean for instance if a system has been built to be say LWRP, I dont expect the entire architecture to change after its gone into preview (turning into URP - just one example ofcourse - lots of this all over the place). That shows serious lack of foresight on the design part. Again, early docs would highlight this as users would tell you their pain earlier if they knew how to use the system. The version number means nothing really, but when a flashy blog post comes out saying something is in preview, it shouldnt have massive fundamental changes (features added or removed or completely changed) after that point unless its literally do or die. Once people read that stuff they get excited and make plans based on it, so big breaking changes and u-turns on design decisions will affect them and create user pain - even if justified.

If we were to communicate these massive changes earlier in the process, would that help? Want to drill in a bit more on the version number here - let’s say we release URP 2.0.0 and everything’s solid and stable. A few weeks later, you see a URP 3.0.0-preview version appear and in the notes section there’s information such as “URP 3.0.0 deprecates MacOS Metal as we’re transitioning to Vulkan for our graphics API’s” - is that acceptable at the point where we start working on something to communicate that in the first iteration of the next major version? I guess I am trying to suss out what an acceptable level of change is when something is in preview.

@MadeFromPolygons_1

Yes absolutely, but I do believe that the user engagement on your part (you and rest of unity team) and the new release structure proposed will help somewhat.

Expect to see a lot of this as we really dig in to better understand the needs and requirements of our users

[JoNax97]

And does that expectation also carry over into packages when you see an update? What do you look for to tell you a package is “good” to install or upgrade? Are there other metrics of evaluation you use for deciding on an editor version to upgrade to?

With packages I tend to be more flexible, because I can downgrade a feature if it’s bringing me trouble and I don’t have to wight in losing completely unrelated features. I normally look into the package docs and watch the forums closely, that usually gives me a sense of what i could call “inertia”. That being, is this package advancing toward where I need it to be, or is it pretty much stalled?
Good examples of this are the input system and quick search. The level of interaction and willingness to assess feedback is reassuring.

Also, I agree that the preview label is not enough. Having distinct branches with alpha/beta/final tags, and having the same rules and expectations than with the engine would be ideal. The first public alpha should showcase the initial offering of the package, during alpha period there should be openness to add/change features, API and workflow, and during beta there should be focus in stability, docs and UX.

If you don’t mind me asking, is this ideal for you? If not, is there an ideal world where you can get QoL and workflow improvements without having to jump through hoops? What’s the blue sky situation here if everything “just worked” for you?

Interesting. So in cases like this, the strict rules of backporting doesn’t improve the situation for you but instead puts you in a more precarious decision of sticking to the LTS with the missing features or jumping to the tech releases to get the new feature enhancements? What’s the ideal situation here or is there one from your perspective?

Hey. I’ve spent the last 15 minutes trying to answer this 2 questions, and realized I’ve been contradicting myself. I think the gist of the situation is that you’re in an uncomfortable middle ground between being non-disruptive and moving forward. I think you should choose on or the other. Personally I would much prefer that you stopped releasing versions in a fixed schedule and gone back to releasing when you feel the tech is there. Make changes without fear of upgradability, don’t linger on old stuff forever, and when you feel you have a well-rounded package, bump the major version and signal clearly that people wanting stability should stay behind until their project ends.I think it’s preferable to have a big jump every 1 or 2 years that it is to be in a constant state of flux. But of course that’s only my point of view.

I’m sorry if this is not the answer you were expecting but I’ve realized it’s very difficult to put some sensations in coherent words.

[PeterB]

From Unity 2019.3 Is Now Available page-5

People here are not upset because it’s not perfect, we’re upset because we invested everything into it based on our perspective that [Unity] were professional/tidy, and we’re all running into ridiculous setbacks left and right, and for many of us, this is our livelihood.

Exactly. Nailed it. For smaller projects – and there’s nothing wrong with them – the pain isn’t quite as noticeable. However, if you try a larger project you will quickly run into problems. There is then the added problem that different types of developers get very different impressions of the state of Unity depending on their experience and background and thus have trouble communicating with devs with other types of experience and background.

The problem with Unity is that there’s never been a really stable release, not even an LTS one. This forces people to upgrade to tech releases in the hope that a crucial bug finally might have been fixed. This is especially so if your project pushes the engine or the editor in any way.

I think it’s important to view features promised to us, and features given to us in a first implementation, purely as marketing rather than tech. All these promises are there to keep us hooked. Same thing goes for all the demos: they represent not the state of the engine available to all devs at the time the demo was made, but an idea of what Unity might become. Fine, you can create something similar to the forest in The Book of the Dead if you work really hard, but it won’t be an area large enough for gameplay. Also, the official demo you took as inspiration probably only will work for the specific version it was written in. Even minor version upgrades breaks the demos most of the time. Thus, they are marketing ploys directed towards subscribers in order to keep us hooked.

The problem for me, who have been using the engine since 2010, is that all those promises made during a full decade never have been delivered upon fully. “Oh, yes, multi-terrain handling is coming soon,” “There will be a new multiplayer networking layer really soon,” “The new GI system will be fantastic,” etc, etc, ad nauseam. I’ve waited for 10 years for Unity to create something which is usable for my type of game. I’ve finally come to the conclusion that it will take several years for Unity to stabilise even if they manage to add all those features which they’ve promised us for many years now. I can’t wait that long. Thus I’m simply using the wrong engine and need to change. Consequently, I have downgraded my subscription from Pro to Plus and now Free. Why pay for being an alpha tester for something which claims to be a colossus but still has clay legs?

On the other hand, if Unity works for someone, all power to them. The whole thing boils down to choosing the right engine for your type of game. However, the sad bit is that Unity has misled us all as to the current state and plans for their engine, so that choice has been very difficult to make due to all the … ahem, “fake news” we’ve seen over the years.

[system]

@PeterB

From https://discussions.unity.com/t/774087 page-5

Exactly. Nailed it. For smaller projects – and there’s nothing wrong with them – the pain isn’t quite as noticeable. However, if you try a larger project you will quickly run into problems. There is then the added problem that different types of developers get very different impressions of the state of Unity depending on their experience and background and thus have trouble communicating with devs with other types of experience and background.

The problem with Unity is that there’s never been a really stable release, not even an LTS one. This forces people to upgrade to tech releases in the hope that a crucial bug finally might have been fixed. This is especially so if your project pushes the engine or the editor in any way.

I think it’s important to view features promised to us, and features given to us in a first implementation, purely as marketing rather than tech. All these promises are there to keep us hooked. Same thing goes for all the demos: they represent not the state of the engine available to all devs at the time the demo was made, but an idea of what Unity might become. Fine, you can create something similar to the forest in The Book of the Dead if you work really hard, but it won’t be an area large enough for gameplay. Also, the official demo you took as inspiration probably only will work for the specific version it was written in. Even minor version upgrades breaks the demos most of the time. Thus, they are marketing ploys directed towards subscribers in order to keep us hooked.

The problem for me, who have been using the engine since 2010, is that all those promises made during a full decade never have been delivered upon fully. “Oh, yes, multi-terrain handling is coming soon,” “There will be a new multiplayer networking layer really soon,” “The new GI system will be fantastic,” etc, etc, ad nauseam. I’ve waited for 10 years for Unity to create something which is usable for my type of game. I’ve finally come to the conclusion that it will take several years for Unity to stabilise even if they manage to add all those features which they’ve promised us for many years now. I can’t wait that long. Thus I’m simply using the wrong engine and need to change. Consequently, I have downgraded my subscription from Pro to Plus and now Free. Why pay for being an alpha tester for something which claims to be a colossus but still has clay legs?

On the other hand, if Unity works for someone, all power to them. The whole thing boils down to choosing the right engine for your type of game. However, the sad bit is that Unity has misled us all as to the current state and plans for their engine, so that choice has been very difficult to make due to all the … ahem, “fake news” we’ve seen over the years.

Imagine if every Jetbrain release broke every package and people’s workflow or if everytime Apple released a product it would not work with any of the prior applications - I would stop using them. Similar to this person, there is no way I will continue to pay for a subscription. I expect my tools to be Jetbrains/Apple solid. I got things I need to get done.

[smcclelland]

@JoNax97

With packages I tend to be more flexible, because I can downgrade a feature if it’s bringing me trouble and I don’t have to wight in losing completely unrelated features. I normally look into the package docs and watch the forums closely, that usually gives me a sense of what i could call “inertia”. That being, is this package advancing toward where I need it to be, or is it pretty much stalled?
Good examples of this are the input system and quick search. The level of interaction and willingness to assess feedback is reassuring.

Also, I agree that the preview label is not enough. Having distinct branches with alpha/beta/final tags, and having the same rules and expectations than with the engine would be ideal. The first public alpha should showcase the initial offering of the package, during alpha period there should be openness to add/change features, API and workflow, and during beta there should be focus in stability, docs and UX.

This is great feedback and insight into approaches to package readiness. Thanks for that!

Does Preview and Released/Verified currently cover this well? In the Editor we have three states, should that also be mirrored in package land from what you’re saying i.e. Alpha, Beta, Released?

@JoNax97

Hey. I’ve spent the last 15 minutes trying to answer this 2 questions, and realized I’ve been contradicting myself. I think the gist of the situation is that you’re in an uncomfortable middle ground between being non-disruptive and moving forward. I think you should choose on or the other. Personally I would much prefer that you stopped releasing versions in a fixed schedule and gone back to releasing when you feel the tech is there. Make changes without fear of upgradability, don’t linger on old stuff forever, and when you feel you have a well-rounded package, bump the major version and signal clearly that people wanting stability should stay behind until their project ends.I think it’s preferable to have a big jump every 1 or 2 years that it is to be in a constant state of flux. But of course that’s only my point of view.

I’m sorry if this is not the answer you were expecting but I’ve realized it’s very difficult to put some sensations in coherent words.

Honestly, I don’t expect any answer specifically so whatever you feel or is on your mind we’re happy to take as feedback. If we move to a release when ready model, how can we better leverage the Alpha/Beta to ensure we’re ready from our users perspective? The same for packages, how do we make it better for you to jump on board and help drive these things and tell us when it’s feeling good and ready for an official release? Really appreciate you taking the time to dive into details on all of this!

[smcclelland]

@PeterB

…snip…

From your experience, what have been some of the challenges you faced when communicated with the devs?

This is a really interesting anecdote. There was a similar sentiment further up in the thread about having to basically bounce around if you wanted to take additional functionality outside of bug fixes in the LTS. Do you feel that LTS is the avenue we should be taking to ensure stability? What about tech releases if we shifted focus to solidify those even more?

When you say features promised, can you expand on that one a bit? Are these things we’ve said at trade shows, blog posts, or through our roadmap? Are we setting poor expectations for our users and over-promising? When we make an announcement such as multi-terrain tool, what is your expectation alongside that announcement? Stable and production ready? Room for iteration and enhancements based on feedback? I apologize that you’re left feeling this way after a decade and hope we can rebuild some trust going forward with our users.

[smcclelland]

Imagine if every Jetbrain release broke every package and people’s workflow or if everytime Apple released a product it would not work with any of the prior applications - I would stop using them. Similar to this person, there is no way I will continue to pay for a subscription. I expect my tools to be Jetbrains/Apple solid. I got things I need to get done.

A real quick question on this but what about Beta versions? For example Rider Early Access releases? If there are bugs or issues there, is that expected? If it has some deal-breaker bug is that ok? If there’s a breaking change that carries over to the next major release, when should that be communicated to you and how do you expect that to be handled so you can prepare?