Unity has developed the habit of cancelling running systems and replacing them with unfinished ones

Unity Engine
, ,
1

Let me start by saying Unity has been a valueable tool for me throughout the years. You may realize this is my first (and perhaps last) forum post and thus decide not to pay too much attention to it. The truth is, I have been using Unity for more than 5 years now, spent probably more than $1000 on the asset store and maintain a small team of developers. I filed the occassional bug report but never posted on here, because for the most part, things were running fine. The fact that I have resorted to finally post my feedback on this forum mostly means one thing: things are no longer running fine.

This post will be an attempt to phrase this criticism in a constructive way. I do not have high hopes for this to change much, but I feel it is at least worth to give it a try. Now where to begin?

As of recent, it feels as if Unity has had the habit of proudly presenting new features that are to be released soon™. The most ironic example for this is the feedback system being transitioned to these forums in 2019, the same post saying that a new solution is on its way. So here am I am, 2022, posting feedback on the forums.

  • I recall waiting several years for the new Sprite 2D system when it was announced.

  • I recall waiting for the Entity Component System to supposedly become the new standard for developing in Unity and never hearing of it again.

  • I recall waiting for the new USS based UI system which, years later, is still in preview.

  • I recall waiting for PlasticSCM to become useable, then getting forced out of Collab and being left with disfunctional version control.

  • I recall waiting for the editor performance issues in Unity 2020+ to get fixed.

  • And I recall waiting for a non-deprecated Multiplayer System - to this day.

This list goes on, filled with features that I have forgotten about, because their announcement dates so far back. Now inherently, this is no major issue. It is an annoyance for sure, but it has never stopped me from developing. There were times when I was thinking to myself “I will just wait for a couple more weeks, then the new feature will be out and I do not need to implement it myself” and I was disappointed, but beyond that, things are fine. Unity, as it stands right now (or stood, more on this below), has all the features that I could wish for.

I, like any other developer, understand that implementing these features takes its time. Whether it is reasonable to announce them years before release is subject to discussion, but in principle, there is no harm in this.

However, and this is the main point of this post. These developments stop being an annoyance and start being a serious problem when with the announcement of a new system, the support for the old system is cancelled. This happened with Multiplayer, with us developers having no solutions without resorting to third party systems for years now. It happened with Version Control, when support for Collab was cancelled and we are now left with PlasticSCM, which still has system breaking bugs and a setup more large, invasive and complicated than Collab ever had. And I think it is fair to assume that eventually, LTS for Unity 2019.x will end, so that we are then forced to use a newer Unity version, probably without their performance issues ever being fixed.

Now there are ways to deal with this:
Instead of using the Unity Multiplayer Servers, I can simply pick one of the alternatives on the asset store, like Photon. I may have bought the server resources from Unity, but if there are alternatives that work, I will gladly pay for them instead.
Instead of using the flawed version control, requiring an additonal 500MB client for each individual and crashing at files of more than 30MB, it is easier to set up a workaround using GitHub. Well sure, I might have considered buying additional seats for the team members on Collaborate, but if both are equally inconvenient to set up, I might as well take the one that is more stable.
And if support for Unity 2019 eventually ends, I will probably grudgingly invest in better hardware to run the new versions, instead of using that money on the asset store.

The point that I am trying to bring across is: these recent developments have forced me to patch up and find workarounds for an initially perfectly running system again and again. It did not benefit me as a developer and neither did it benefit Unity. Everyone involved would have been better off if literally nothing had changed.

Am I suggesting to just stop development on Unity completely and maintain the old systems infinitely? Of course not! If that had been the case, we would not have a lot of the amazing features we know and love today. But what I will suggest is that support for old systems should not simply be dropped before replacements are ready and proven. Do not force users to adopt new systems. If they are decent, they will be adopted by themselves. I understand there will be a point where it is just not worthwhile to support old systems, but in my mind, the idea for this should be that ~90% of the users first transition and then the old system may be shut down. Allow the users to choose which system they want to use. Once they decide the new system is better than the old one, go on.

You, at Unity HQ, are the only ones who know the numbers on this, but from my perspective, the way it currently works is that a grace period is provided, during which users are requested to transition to a new system. The majority does not respond to this. And perhaps I can provide some new insights by saying that, at the very least in my case, this does not happen out of ignorance, convenience or laziness. It is simply because the new systems are often objectively significantly less stable or not ready. At the end of the grace period, the users are then forced to transition anyways, leaving them with a worse or disfunctional setup.

This post is obviously too late to undo what has happened so far. We will not get functional multiplayer for a long time and who knows if there will ever be a lightweight solution for version control again. But for the future, in the interest of everyone, for flip’s sake, please stop cancelling working systems and replacing them with something that does not work. No one benefits from this. And if it continues and the experience with Unity becomes waiting for systems to get fixed or finding workarounds for them, this seriously affects the quality of Unity.

I understand this has become a lengthy post. Thank you for taking the time to read it, and if any questions arise from it, I will be happy to provide my opinions on them.

6 Likes
2

Hi @Brightsi , thank you very much for taking the time to write this post! We definitely hear your point here and understand the frustration when some of your critical workflows do not evolve the way you need them to from one major version to another.

I am pinging some other folks over here on topics I cannot fully cover, but I am glad to be able to bring some light to 2 topics, namely product feedback and DOTS.

You have been around for a while with Unity, and thank you for this, as you mention the feedback system, I believe you refer to the platform we closed in 2019. We came to this conclusion because the amount of feedback we were receiving was not triaged fast enough by our product team to be able to incorporate it into our decision-making process. Additionally, you are not mentioning it but we had similar challenges with our roadmap page, it was not always up to date and did not equip you well to make informed decisions.

You were definitely not alone in telling us this had to evolve in a better way. We then decided to merge those 2 concepts together in a single place, a roadmap you can explore and directly share feedback into: unity.com/roadmap. If you use functional cookies and log in with your Unity ID, sharing feedback takes 2 clicks, and goes straight to the right Product team! We receive hundreds of ideas and feedback through those pages every single month since its launch in March 2021, and use them for driving product development. If you didn’t know that space, please give it a try, or if you knew it already, can you please tell us if this is useful to you?

Regarding DOTS, we understand that the experimental status of this development has caused challenges for you all because you critically needed to overcome Unity architecture limitations, and our experimental phase has taken way too long to become a mature product feature by the time you needed it. We have decided to accelerate making it available to you all by targeting a first released version of ECS fully compatible with gameobjects, so that you all can start to build more ambitious games even though not all of Unity is ECS-based, and nicely upgrade to a new version of Unity by adopting new systems progressively.

We announced this plan very recently, first in December with this post , and more recently made the first milestone of this plan available with Entities 0.50 , last week! Here is our latest DOTS roadmap post that goes into more details for our plan toward a 1.0 supported for production. We also present this at GDC on Monday in the DOTS roadmap session with 2 guest developers explaining how they used ECS in their games.

I fully realize I am not addressing the multiplayer, 2D, editor, and source control topics here, we’ll try to get other folks to jump in. Please let us know if any of this is helpful!

Thank you!

Laurent

4 Likes
3

Hi Laurent, first of all thank you for response and drawing attention to this! The fact that feedback was merged into the roadmaps was indeed new to me. However, I will say it is a bit difficult to find, unless you know it is there. When Googling for “Unity3D Feedback” you usually land on either the Unity support website (https://support.unity.com/hc/en-us/articles/205692319-How-do-I-submit-feedback-about-Unity-) or this very forum ( The Future of Unity Feedback ) with neither of them making mention of the roadmap system. Perhaps this is something that could be addressed. Still, this is good to know for the future, thank you!

As for the rest of your response, I would just like to stress that for me this is not about being impatient for new systems to be released. As I said, things being announced in an almost finished state and then having to wait several months or even years for them is an annoyance, but it does not obstruct development per se. After all, Unity is a great tool as it is.

It is more about the overarching issue of how these new systems are introduced and how the old ones are rotated out. Taking DOTS as an example, to me it is perfectly fine if its development takes however long it takes. Perhaps do not necessarily use it as a marketing point if developers can not expect to see it for several months, but other than that, this is perfectly fine for me.
However, if there ever comes a day where it is decided to drop support for any of Unity’s old features in favour of DOTS, it must be in a state where it is objectively superior to the old solution. In the past, this did not happen for all the systems. The old solution just became deprecated without the new one being ready.

On that note, some of the issues that I listed are resolved at this point. The Sprite 2D Animation System in question is out since 2020 or so from what I recall, after being announced in 2016.

For networking, honestly it is hard to tell. When I wrote this post, I was under the assumption it was still not released to this day. After doing some research, apparently there exists a tutorial from 2021. When checking the Unity Documentation, it still says that the current solution is deprecated and links to the roadmap. On that roadmap, Version 1.0 is out, but tagged as “Pre-Release”. So there is a bunch of conflicting information there. Best case this is simply a matter of the documentation being behind.

Still, this is not about the individual systems themselves. Even if all of them were released tomorrow, this would not solve the underlying issue of how they were introduced, i.e. with a year long gap between their release and the end of life of old systems, in which their functionality was simply missing completely. Even under the assumption that the new Multiplayer System is ready to go now, from 2019 to 2021, you could not develop multiplayer games without using a solution that was already deprecated at the time. Now, with Collab and PlasticSCM, we have a similar issue. Most of us found workarounds in the meantime, but my sole point is that I would simply prefer if in the future, these workarounds, caused by systems being dropped without their replacement being ready, did not become necessary anymore.

4

Hey @Brightsi , thanks for sharing your thoughts with us. I can certainly feel the frustration, which seems to come from different sources, with two of them sitting on the same spectrum: Slow development and maintaining features until the get replaced. We share the same frustrations internally, even though we believe we’re doing the right thing (hopefully).

I’ll take UI as a use case since I’m covering this area. The USS based UI system, known as UI Toolkit, was out of experimental in 2019 for editor extensions, and got support for runtime in 2021.2. Now admittedly, it has not reach parity with either solution it’s planned to replace, but we’re committed to maintaining IMGUI and UGUI for the foreseeable future, until our users can safely transition to UI Toolkit. Until then, the message is very clear, existing UI solutions are still recommended for most use cases and UI Toolkit can be used as an alternative when you can workaround its limitations. In 2022, UI Toolkit will be the recommendation for Unity Editor Extensions, and we’re planning to unify our solution for runtime UI as well.

This of course has a significant overhead on our development velocity but given the circumstances, even though it’s not ideal, we’re confident it’s the right thing to do.

As for Editor performance, there’s been constant improvements within each release, but the experience will be different for every project and context. It would be super useful if you could provide more details about where and when you experience these performance issues, in which kind projects. It’s always challenging for the team to replicate the conditions in order to identify those issues.

This is just my perspective though, which is most certainly biased, but I’d be very interested to know how we could improve from your point of view.

Thanks!

3 Likes
5

Unity has taught me a valuable lesson in managing my expectations when it comes to new feature hype, so thanks for that I guess. 8)

1 Like
6

Good catch, thanks for that. We had published a blog post to highlight feedback options and recommendations a couple of months back, and we should also include this information in those places.

1 Like
7

Hi @Brightsi , thank you for taking the time to write this feedback. I’m the Product Lead for version control - and before I jump in I just wanted to say that I am sorry to hear that your experience upgrading to Plastic SCM from Collaborate has been painful. We have been doing our best to provide the tools to make the migration as painless as possible but know that this has not been the case for all projects. Upgrading version control backends is, unfortunately, a very complicated task due to how Collaborate was built. I’d really love to sit down with you to talk in more detail so that we can improve the experience for others. For example, we are unaware of system breaking bugs and need a lot more information so we can fix the issues. Please send me a DM if you’d be open and we can schedule a time.

Our goal with Plastic SCM is to find a balance between the simple project sharing of Collaborate and the robust (but still easy to use) features of version control that so many creators have been asking for. We have spent the last year working with Collaborate users through UX studies to ensure Plastic SCM for Unity would allow you to achieve workflows similar to Collaborate in the Unity Editor.

We know that a big benefit to using Collaborate is that it just works - there’s no complicated setup or high learning curve. We have (and will continue) to make sure that routine version control actions, such as the ones available in Collaborate, can be done in the Version Control Package without downloading the standalone client. These features include getting notified of incoming changes, checking in changes to files (publish), updating, reverting individual files, consulting project history (changesets). However, your project does need to be on a supported LTS version or on the current tech stream. This is due to how the engine release process works to ensure stability and is not something we can fix. This means that projects that are not on supported Editor versions don’t have access to this in-Editor integration and do need a separate client install.

We wish we could have kept Collaborate around until all projects were on supported editor versions, but the upgrade process for projects is very slow and some never even move. We had to balance that with the hard truth that Collaborate is incredibly difficult to maintain and any energy (which is a lot) we spend bug fixing there is taking away from our ability to build a better version control for you.

We have been open in the past about the need for Collaborate to be rebuilt on a stronger foundation and the Plastic SCM foundation is that. We still have work to do to continue to build a deeply integrated, and easy to use UX in the editor. The sooner the Collaborate migration is done, the faster we can work. That being said, we will strive to get better with these types of transition plans, including better communication, which are understandably disruptive to you. I can tell you we have learnt a lot through this process and are continuing to adjust as we go to create a better experience for those who have not yet migrated.

2 Likes