Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice

Unity Future .NET Development Status

Discussion in 'Experimental Scripting Previews' started by JoshPeterson, Apr 13, 2021.

  1. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,289
    Our philosophy for this project indicates that we won't likely try this, unfortunately. Breaking projects or forking the ecosystem in a way that requires some projects to stay on older versions of Unity is not something that we are willing to try.

    With that said, part of our plan is to aggressively deprecate and replace things that have been replaced (e.g. the Mono scripting backend) when we have viable alternatives. So we're trying to walk the line between compatibility and deprecation. We'll see how well we can accomplish that, but it is definitely a goal.

    With that said, I don't yet know any dates for deprecation of anything. But we will announce those as soon as we are confident.
     
    Luxxuor likes this.
  2. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    367
    The existing compilation pipeline is deeply entangled within the Unity Editor between C++ and C# code, so the work involved is requiring to approach this in steps:
    1. First working on decoupling the compilation pipeline from the editor, and using a separate process. Make sure that this decoupling is compatible.
    2. Transition to csproj

    The team just started to tackle 1. with a hope to land it for 2023.1. Then step 2. could happen at best for 2023.2, or at worse for 2024.1, if we are encountering more trouble for this transition.
     
    Anthiese, cxode, Tanner555 and 8 others like this.
  3. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    120
    This is very unfortunate. I also feel like following a harder feature migration enforcement policy would be beneficial for BOTH Unity and any unity projects.
    It would encourage users to remove technical debt from their projects, read up on new features and how they can benefit their projects, follow best practices and enforce somewhat of a 'code standard'.
    And Unity would be free to move forward at high speed without having to look back.
    As I've proposed before, a deprecation cycle of 3 years should be plenty of time for any developer to migrate to the new features.
     
  4. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    I would also like to second this, your "modernisation" is akin to Microsoft rewriting .NET into .NET Core (many of the API's are the same) but it was a chance to strip out the years of baggage and bad practices, I strongly feel that you should do the same, consider this your "Unity Core". Microsoft decided to strip away many of the staple parts of the framework that had been deemed bad in hindsight, WCF for example.

    There are many problems existing with the API today, namely inconsistent naming and casing practices, the fact is, they have been wrong for years and are due a change. Common practice across the entire .NET ecosystem is the following:
    • Classes - PascalCase
    • Methods - PascalCase
    • Properties - PascalCase
    • Fields - camelCase (should almost never be public, use properties instead. So private fields should start with an "_" e.g _camelCase - some people use this.camelCase but most feel the _ adds clarity at a glance)
    I think Unity should seriously consider adhering to this if they plan to adopt the nuget ecosystem as every other package will be consistent with the above stated, leading to confusion when using Unity API's where everything is accessed via public camelCase fields. You should switch to using properties just for the benefit of having the ability to change how the accessors work which you don't get with a field, which will make everything more flexible in the future and less resistant to change.

    I know this will likely be overlooked but I can't overstate how much of a pain point this is. Please please please use this chance to fix the problems of the past. All legacy code can end with e.g Unity 2024.2. Going forward it should be like .NET Core in that it's main focus is new projects and long term support for them, instead of trying to support the past 15 years of mess.
     
    Last edited: Apr 30, 2022
  5. PixelizedPlayer

    PixelizedPlayer

    Joined:
    Feb 27, 2013
    Posts:
    641
    Is there a reason Unity has that mindset that maybe I do not understand. Since people should not be upgrading a major project to a latest engine version in the first place (due to deprecation and assets not working anymore etc) then it should already be in people's minds not to always upgrade to latest unity version once you commit to a project - stick to the long term support of their version.

    For an example, if you commit to a project on 2021, you should never go to 2022, stick to all versions of 2021. Since 2022 could be a complete breaking of the project. At least i assumed thats how most developers have thought about Unity versions.

    That said Unity does have this mindset for the graphics pipeline, at some point you are going to drop the standard shader pipeline for URP/HDRP entirely - granted you did make a tool to upgrade projects to the new pipelines (is that possible for this too?).

    I want to see Unity making big leaps in tech/features not the continuous delicate balance of pleasing everyone on projects from the past which adds limitations on your end when making new features, adds complexity that could be avoided, and features that take forever to appear because it has to cover previous projects - this slows development of many features.
     
    Last edited: Apr 30, 2022
  6. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    307
    Would you happen to have a source for this? I’d like to bookmark it.
     
  7. PixelizedPlayer

    PixelizedPlayer

    Joined:
    Feb 27, 2013
    Posts:
    641
    There is no source as such just look at peoples code and see that most people do it that way. Though typically for me fields are _camelCase and variables locally scoped at camelCase. So theres a bit of variation here and there.
     
    ScottKane likes this.
  8. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    307
    Thaina and VolodymyrBS like this.
  9. PixelizedPlayer

    PixelizedPlayer

    Joined:
    Feb 27, 2013
    Posts:
    641
    I'm not the original person you were replying too, I just chimed in. Although there is a general convention, some people have minor differences in their convention to the standard. So i wouldn't worry too much about what sources say as long as your code is consistent and clear between them all.
     
  10. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    307
    On one hand I agree with standardizing the naming conventions in Unity, on the other I’m not completely sure if it has to be according to Microsoft’s guidelines. What I am noticing is that different Unity packages may use different conventions, and that is unhelpful. It would be great if Unity could develop their own set of rules and conventions that can be added to the docs with an accompanying vs and rider ruleset (or whatever they’re called).

    Don’t get me wrong, I love the C# guidelines, but I don’t see such a complete library overhaul happening to Unity anytime soon, so this could be a cool compromise.
     
    Xepherys likes this.
  11. YegorStepanov

    YegorStepanov

    Joined:
    Oct 10, 2017
    Posts:
    9
    I've never seen this o_O

    The naming conventions doesn't matter for private scope.
    You can name private members like you want or even mix styles in different files (renaming can break the code and bloat the commit).

    For reflection or reading source code it's is a minor inconvenience.

    But for external usage, there is one simple rule - PascalCase.

    .NET BCL, Nuget packages, user's Unity packages and your code are looking and calling the same.

    But not the Unity Technologies® methods/properties/fields.
     
  12. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    See https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions for a simple but non-comprehensive list or https://www.c-sharpcorner.com/UploadFile/8a67c0/C-Sharp-coding-standards-and-naming-conventions/ for some more in depth usage (this also mentions abbreviations which I would generally avoid, use descriptive full names where possible. But don't go too far, e.g you have a class "User", some people would name a method "GetUser" where I would just call it "Get". The User bit is implied by the class itself.), the coding styles I mention come from years of work in enterprise where this is extremely strict, you would get a PR rejected for poor naming and/or capitalization. This standard is widely used across almost all open source projects. Take a look into some of JetBrains open source stuff or anything under the .NET Foundation.

    You are correct in that some use s_camelCase for static members, and even as far as b_camelCase for booleans. I'm not as big a fan of these although for some they have merit (I prefer using language to differentiate bools e.g _isTrue or _hasThing), these ones specifically come from legacy C/C++ developers who would commonly do this. I don't personally find static members being defined in this way as helpful as generally speaking the fact that a member is static is only useful when calling from a static context anyways (you can usually get away with having a static _instance field on the object through which you can access it's non-static members).

    e.g:
    Code (CSharp):
    1. public class Example
    2. {
    3.     private static Example _instance; // You can make this readonly if you use a static constructor
    4.     // but that is unlikely if you use dependecy injection
    5.     private string _nonStatic = "Hello World";
    6.  
    7.     public Example() => _instance = this;
    8.  
    9.     public static void Do() => Console.WriteLine(_instance._nonStatic);
    10.     // Notice I can access the non-static member within a static context
    11. }
     
    Last edited: Apr 30, 2022
    Thaina likes this.
  13. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    This is exactly the problem, there's been too much "not anytime soon" in the Unity space for too long. These problems basically NEED to be addressed if they plan on playing nice with the rest of the .NET ecosystem. I suspect a lot of the casing is a remnant of the javascript scripting system of old, but it has no place here now.

    I think the general consensus from Unity is that they don't want to break anything for everyone. But the general consensus from the community is that we want you to break as much as humanly possible in favour of a more robust and standardized API. All you have to do is tell people that if they want the new hotness 3 years into a project, it's on you to deal with all of the breaks and that it's meant for a File -> New experience like .NET Core was.
     
    Mindstyler likes this.
  14. OndrejP

    OndrejP

    Joined:
    Jul 19, 2017
    Posts:
    230
    I'm against using properties everywhere, there's a lot of cases where fields are better.
    You mean more complex classes, right? We can probably agree that simple data structs/classes can use public fields. Also fields can be passed by ref, which can be advantage in some cases.

    I agree that properties should use PascalCase and I don't like that Unity's using camelCase.
    I prefer PascalCase for public fields as well, private fields does not really matter (not part of API).
     
  15. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    This is more a question of mutability, you can't stop someone setting a field unless it's readonly. Properties can be made immutable by default. As for passing by reference, you can just use an Action or LINQ expression to get around this limitation. Also if you create your own backing field for the property, that can be passed by reference without the field being public. I honestly think public fields are generally a bad idea.

    I'm not saying fields in your own code are necessarily bad, it's more that in an API that is being consumed, you should be far more conscious of what state you are allowing people to change. There is also a case for internal fields (with InternalsVisibleTo to allow access from another assembly) that will get the job done without exposing the raw field to every consumer of an API.
     
    Last edited: Apr 30, 2022
    Mindstyler likes this.
  16. YegorStepanov

    YegorStepanov

    Joined:
    Oct 10, 2017
    Posts:
    9
    ref semantics are performance related:
    Code (CSharp):
    1. Vector3 vec = this.FieldVector; //copy 12b or aligned 16b
    2. vec.x = 0f;
    3. this.FieldVector = vec; //set 12-16b
    4. //vs
    5. ref Vector3 vec = ref this.FieldVector; //copy 8b
    6. vec.x = 0f;
    Action has an indirect call and quite easily has a closure and an implicit delegate creation(yet another GC pressure).
     
  17. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    Lets be real, a saving of 4-8b on modern processors is minimal (especially if it's only happening once) and is an extreme edge case here. I can scarcely remember the last time I needed to pass something by reference from a public API that I wasn't ok with copying an initial instance. Looking at the vast majority of Microsoft code you can see their use of properties on public facing API's. I would like to see a benchmark run against this to check the actual outcome but I'm willing to bet the perf will be negligible. Not to mention with the addition of Span<T> you could mitigate most of this if really needed. Or just go unsafe and pass a pointer, if this is a performance concern for something specific.

    Also as I mentioned, the main concern here would be mutability, you don't want to allow things to be openly mutable by default, it leads to misuse and hard to diagnose errors when something that is not expected to change has been somewhere.

    This would be the benefit of having open source access to the engine though, as the specifics of whether or not something should be accessed via field or property could be debated on a case by case basis.
     
    Last edited: Apr 30, 2022
  18. YegorStepanov

    YegorStepanov

    Joined:
    Oct 10, 2017
    Posts:
    9
    NET 6. A question mark is a bug in the output in BenchmarkDotNet, it cannot divide 0.4301 by 0.0675 :(

    Untitled.png

    Ofc don't do this for MonoBehaviors. But you can speed up algorithms by simply reducing the copying structs. If not you, then library authors or programmers at Unity. Unity started moving from c++ to c# because these low-level features exist.

    Also you will break this:
    Code (CSharp):
    1. Vector3[] array = ...;
    2. array[0].x++; //array indexer returns value by ref, not by value
    You want greatly slow down core Unity code. Core immutable structs are not good for gamedev and not good for C#. Next .NET language will be immutable by default, but not C#.

    [edit]
    If you want immutably from your code only. You can write ImmutableVector3 with implicit conversation from/to Vector3. Add Microsoft BannedApi analyzer to ban usage of Vector3 (you should add each structure manually). Or write new analyzer, that will ban mutable structs automatically and share it to github :)
     
    Last edited: Apr 30, 2022
  19. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    Thanks for this, I'm really surprised at the difference in single calls here. The difference was bigger than I expected. I was more referring to this.transform or this.gameObject on a MonoBehavior in terms of these being properties as opposed the fields of vectors but I think this will be a good area for discussion for the community/Unity team. Regardless of that I feel the casing strategy for the API's should definitely be made consistent with the rest of .NET.

    Also worth noting that the single copy performance is nothing if it only happens once for you to cache the value in your own code to then pass by reference for the rest of the lifetime, I'm assuming in your looping benchmark there was a copy in each iteration.

    I'm not sure I agree here. All the recent work Microsoft has put into readonly ref structs shows that they think there is definitely value here for C#.

    Also would be interesting to see the allocation differences with all these changes in mind. Also we have to take into account the switch to .NET 6 making huge perf gains across the board with a far superior GC than what is currently shipped with Unity.

    On another note it would also be interesting to see a RAII (resource acquisition is initialization) based runtime. I think this is something that has been overlooked in .NET in general, but a resource acquisition model somewhere near the realm of Rust could be incredible for C#. This means no GC for anyone who hasn't used C++ or Rust.
     
  20. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    Another case for properties over fields is that it lends itself to composition over inheritance with interfaces which cannot contain fields. Imagine a future where we have all sorts of interfaces to compose exactly what each behaviour needs. As opposed to just deriving from MonoBehaviour or not (composition of exactly what you need vs all or nothing).
     
    Ghat-Smith and Mindstyler like this.
  21. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    927
  22. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    120
    ^^That's great. Standard c# conventions. PascalCase for properties and "_ " prefix for private fields.
     
  23. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    662
    As far as I know, there is no naming convention for private fields, so everyone can name them whatever they like, important only that it is consistent throughout assembly/project. Personally, I've changed my style several times over the last few years, first "_" prefix, then "this.", currently "m_" or "s_" (static fields). You can see quickly whether it is a static or dynamic field.

    By the way, public fields are against Microsoft's design guidelines. Simple properties should be optimized away from the JIT in production releases/builds and hardly produce overhead.
     
  24. koirat

    koirat

    Joined:
    Jul 7, 2012
    Posts:
    1,777
    My convention is like this.
    All my fields are private/protected except fields on a struct this are always public.
    If I need public field I'm making it a property.
    No prefixes of any kind.

    Property always PascalCase
    Field always cammelCase
     
    RunninglVlan likes this.
  25. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    754
    It does matter for development team and for opensource contribution or debugging by investigate the source code
     
  26. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    662
    I also meant the official coding guideline, not the internal team/project. I also said that they should be consistent. Such as Unity uses m_PascalCase for private fields, and also ignores the prefix for the inspector.
     
  27. JoNax97

    JoNax97

    Joined:
    Feb 4, 2016
    Posts:
    597
    This getting offtopic guys :rolleyes:
     
  28. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,289
    Regarding the conversation around our philosophy for this project regarding changing/breaking things - I really appreciate the feedback. We're certainly open to changing our approach. I don't think any of the current work we have in-progress will change based on our decisions around future breaking changes. But there is work on the horizon (likely starting in some time frame the order of months), when we will need to make these decisions.

    Other features are Unity have been (rightly) criticized for chasing the shiny new feature while leaving unimplemented or incomplete parts of an old solution still in use. This is the kind of thing we want to avoid. Our goal is to ship something that works for all Unity users! This is also becoming more and more difficult, as the use cases for Unity users become more and more diverse. On the flip side though, the diverse use cases give us a great opportunity to build a stable, robust product, so we welcome the many use cases.

    So in the near term, we will evaluate the suggestions here. As we approach decisions about whether to ship something faster and break existing projects or delay shipment to ensure compatibility, we will weigh the pros and cons of each case, using this feedback an important input.

    This might all feel a bit hand-wavy now, but I think it will become more concrete in the coming months. So as always, thank you for the excellent conversation - please keep it up!
     
    Anthiese, NotaNaN, cxode and 14 others like this.
  29. Iron-Warrior

    Iron-Warrior

    Joined:
    Nov 3, 2009
    Posts:
    816
    I don't personally mind breaking changes between major editor versions (e.g., 2020 to 2021), since as it stands I typically treat upgrading as something that may cause breaking changes anyways and always allocate engineering time for it, treat it as a spike with unknowns, etc. Most of the teams I know that work on larger projects with Unity tend to stick to a single version for fairly long, with upgrading being a major event (one large team I'm familiar upgraded last year from from 5 to 2019).


    Unrelated: I've noticed this thread sometimes goes a bit off topic into general Unity technical feedback, which have been nice conversations to read and see other users' perspectives. Is there a place for these kinds of discussions that the Unity team would interact with? Things like the Scripting or Editor forums tend to be more focused on support rather than general discussion/feedback.
     
    NotaNaN, CaseyHofland, bdovaz and 3 others like this.
  30. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    307
    I second the idea that e.g. 2020.2 and 2020.3 don’t introduce breaking changes, but 2021.1 does: peeps working on a prototype now can upgrade to LTS later while newer prototypes use newer API.
     
  31. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,289
    I think that this section of the forums is the right place to ask these questions (although often not this thread specifically): https://forum.unity.com/forums/experimental-scripting-previews.107/

    Multiple members of the .NET Tech Group watch this section of the forums. So any ideas or new discussions about such topics will be followed.
     
    Iron-Warrior likes this.
  32. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    307
  33. simon-ferquel-unity

    simon-ferquel-unity

    Unity Technologies

    Joined:
    Apr 1, 2021
    Posts:
    49
    Unfortunately, due to the size of the effort, and the amount of very specific behaviours the current script compilation pipeline has that we need to port in an efficient way to MSBuild, it is a long term effort. My dear hope is that we have this land at the same time as CoreCLR lands in the editor, but this is far from being guaranteed.
     
  34. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    I have this working for Unity right now using MSBuildForUnity (https://github.com/microsoft/MSBuildForUnity). It might not be perfect but it works well for what it is. It hasn't been updated in a while so if you're using netstandard2.1 you will have to make a slight source change to an enum to support that instead of netstandard2.0.
     
  35. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    927
    The same can be said about source of all Unity's packages. I really don't understand why they are not on github to improve communication and involve community in development. It wouldn't be open source but source available just like Unreal https://www.unrealengine.com/en-US/ue4-on-github .
     
  36. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    538
    When .Net Core is integrated, will it be decoupled so that we can update the .Net version independently of the Unity version? Or will the .Net version be tied to the Unity version?
     
  37. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,289
    The .NET version will be tied to the Unity version very much like it is today. Unity is a native (C++) application that hosts the .NET runtime, rather than a "normal" managed C# application. This means it is pretty tightly coupled to the .NET runtime. See our GDC talk listed here for some more details: https://forum.unity.com/threads/gdc-2022-the-future-of-net-and-unity.1255956/
     
    Thaina and OndrejP like this.
  38. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    754
    That's what's another things I wish unity should be planned to change. Unity should be dotnet or have pure dotnet version. For these years I have urge to change into waveengine or playcanvas because the engine was the same as the editor (for wave aka stride) or at least the platform is the same (for playcanvas) which have lesser fragment and more seamless development experience
     
  39. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,289
    This is something we considered, but the cost of such a change was very high, and would have long delayed our our timeline to ship a CoreCLR-based player and editor. So we decided not to try this.

    I'm unclear what you mean here by the engine and editor being the same. Can you elaborate? In Unity's case, the editor is very much using the engine code behind the scenes. But maybe you mean something else.
     
  40. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    754
    Wave/Stride are based on dotnet. Unlike unity that actually based on C++ and try to use C# engine code. The editor are using C++ underlyingly and so many times it got limitation from the layer. One is as you describe that it was hard to change dotnet version in unity and as I see I think it's because unity has dependency on many layer. Layer between C++ and C# is one of them
     
  41. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,289
    Thanks for clarifying! Yes, the architecture of Unity is not something that we are planning to change for this effort. I go into a bit more detail about it in the GDC talk, if you are interested.
     
    Thaina likes this.
  42. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    120
    It would definitely be nice if this was maybe considered / worked on AFTER the migration to .net core. It could bring benefits.
    For now though i agree that the player migration to .net core is the most important part.
     
  43. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,289
    Yes, this is certainly on the table for the future. Although we have enough work now that this is not something we actively considering.
     
  44. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    307
    Quick question: if Coroutines are going to be upgraded to async Tasks, will you ensure they’ll work in the Editor as well? Currently there’s the Editor Coroutines package which has always felt more like a solution to a self-inflicted problem.
     
  45. simon-ferquel-unity

    simon-ferquel-unity

    Unity Technologies

    Joined:
    Apr 1, 2021
    Posts:
    49
    @CaseyHofland That was not yet on my radar, but yes, that totally makes sense. I'll had that to our requirements.
     
    Jes28 likes this.
  46. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    927
    And for unit tests (Unity Test Framework). UniTask supports it as:
    Code (CSharp):
    1. [UnityTest]
    2. public IEnumerator Test() => UniTask.ToCoroutine(async () =>
    3. {
    4.  
    5. });
    Honestly Unity should think about adapting UniTask instead of reinventing the wheel. https://neuecc.medium.com/unitask-v...for-unity-with-asynchronous-linq-1aa9c96aa7dd . If not are there plans to make new implementation as performant as UniTask?
     
    Nad_B, NotaNaN, kevdome3000 and 7 others like this.
  47. JoNax97

    JoNax97

    Joined:
    Feb 4, 2016
    Posts:
    597
    +1 to adopting/ copying/ following UniTask
     
    kevdome3000 and Thaina like this.
  48. dpeter99

    dpeter99

    Joined:
    Sep 29, 2013
    Posts:
    7
    What I would like to see is more of those good old forum-only unity versions. Where you shared custom builds of the editor that were not meant to be used for any serious work but to see how a new feature would work. For example, there was one for the new input system. I hope we will get some similar releases for these big scripting changes. It would allow us to see how exactly some of these changes are planned to be implemented and give meaningful feedback on them.
     
    bdovaz likes this.
  49. KeinZantezuken

    KeinZantezuken

    Joined:
    Mar 28, 2017
    Posts:
    53
    This question was brought up a few times when they first showcases their async stuff a few pages back. They said they are "closely working with Unitask creator" but I have no idea what this means.
    I wouldn't mind just adopting UT, even if with some compromises.
     
    Nad_B likes this.
  50. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    This is what an alpha build should be for, not sure if you mean downloading a custom editor from a forum thread but I would strongly disagree with that in favour of editor versions marked as alpha in Unity Hub serving this purpose.

    There should then be a relevant thread for discussion for each editor version as it moves from alpha -> beta -> public release. Would be nice to be able to see this directly inside Unity Hub if possible.