First I can declare I don’t work on console platform, ever. I only making game for PC, web, and mobile. And it actually unlikely that dotnet coreclr will have any problem relate to console anyway. And I think you can see the console platform already in downturn. XBox is crashed and Sony just desperate on their PS5 selling tank. Only switch is somewhat decent but I think they will just become android in the future
If I don’t really care that I love C# I can just write HTML/JS, I can write ThreeJS and there are a bunch of JS engine that can export to mobile and PC. I even consider writing engine myself with Silk.NET which can be exported to all platform I work with
And that exactly the reason I really frustrate that I have invested myself in unity for 10 years of my life because it was C# game engine but now I stuck to the ancient C# just because unity just not update itself and waste their time on anything except just using C# correctly in their engine. I don’t want to mention that they don’t even support dictionary or tuple in the engine and don’t let us writing custom serialization system
Second. Using modern C# is practical in development quality and production. There are uncountable amount of dotnet library and code technique that could be used in unity if unity just correctly support dotnet ecosystem. We have been argue about why dotnet migration is important in every dimension of game development for 2 years since Josh are the one actively response in here til now that Josh are not with us anymore. And all of those benefits are actually opportunity cost we have lost for years
We all were being baited by promise from unity that we should just wait for them to fix these problem. While Riccitiello actually siphon the development fund from these feature into something like Muse and IronSource and acquiring company that now the team was dissolved such as Weta
Many people have been vent all of this concern since the old unity forum. You should not made me have to all of say these things over again in this new thread
I think 6.1 is the more unified render pipelines updates and then after that is the DOTS connected to game objects update. They said the CoreCLR is not 6.1 specifically.
For anyone worried about a long timeline think about it this way one version of Unity has a major engine upgrade in the form of DOTS new implementation. Then after that we get another major engine upgrade in the form of CorwCLR. Remember it isn’t just the CoreCLR that is a major engine upgrade it is also the DOTS linked with game objects. I think doing one major update at a time is safer because they can focus on fixing one side of bugs and stabilizing instead of worrying about two major updates that could create bugs.
Isn’t one of the major complaints about Unity is introducing bugs but having a slow turnaround for fixes. So, they are kind of listening to our feedback by doing this.
As far as I understood .Net Core does not support many platforms that Unity supports, so essentially they’re rewriting the entire engine from the ground up and working on their 20+ platforms support all over again, it’s like changing the engine of a car while it is speeding in a highway, it not a simple task by any means. We all have frustrations with the current state of the engine, my biggest ones are no support for new versions of C# and the super slow domain reloads. We made these points clear long ago and this .Net Modernization team understands them and is actively working on solving them, so our obligation is to be patient, excited as hell as we are we should remain respectful to the colossal work this team is undergoing, being impatient is not suddenly going to make them work night shifts to satisfy you, we should be grateful we finally got a word about it, about how it’s going to be part of the Beta program, so it’s definitely coming, just not next month.
No one has forced you to use only Unity and lose some imagined, theoretical opportunities. Godot wasn’t really viable until 4.3, which dropped very recently. Go use that if Unity doesn’t meet your expectations. Just be ready for subpar C# experience, like Inspector only supporting Godot native types, not even regular C# collections. And have to cast to Godot specific types when interfacing with engine API, which loses a lot of performance. Furthermore, none of the alternatives have Burst or Jobs, Unity is still the most performant even with their decade old Mono fork.
Beginner advice is to never wait for anything promised to materialize in future. Use what is available now. Whining about it won’t make things happen faster. Also, they merged with ironSource - didn’t spend a cent on it. And Riccitiello is gone - why are we bringing that guy up again?
This is the old thread, just on a different platform. The full history can be read. So can we stop repeating the same talking points we’ve heard for years now?
Ah, didn’t notice due to naming similarities. But yeah, the argument still stands. Use Unity if it fits your needs, don’t if it doesn’t. Very simple stuff. No need to repeat the same crap for years and years. Unity got the message a while back.
This argument also already countered in the old thread and I have been said that the point is it should have been start the process since 2020. Unity also actually use IL2CPP to translate IL into CPP for support all the platform so it should not matter on most platform with IL2CPP, be it Mono or CoreCLR
But they insist on developing their own fork of Mono while mono is gone and CoreCLR is Open Source since 2015. 2015 you know? 10 years of CoreCLR being opensourced and unity still not able to have it
I will say it again. CoreCLR is Open Source since 2015. While unity not care about it for 5 whole years and just start working on it on the 7 year. Then waste their time integrate muse and ironsource and distraction on runtime fee. All those time they should focused on developing CoreCLR in unity. And now they just postpone it to the next year and next year and next year and next year
We already heard these same word of promises in the exact last year too. As I have written this comment people have digging the old thread to point out, they are very accurate, this is the exact same situation. Only progress is more images and pictures. While they try to extort us with runtime fee last year and increase pricing in this year
Yes, it was even more disappointed that they announce the increase of pricing, even they cancel the runtime fee the increase pricing still hit us with bad taste. And we just wait for unite just to be shove in the face that the feature we actually waiting for was nowhere near finished. Not only dotnet but also the new animation system
No one invest in current. Everyone invest in future
I am not wait for development with the future. But we all here actually invest our time study and polish unity skill or even learn it codebase not only for current unity but also the future of unity. So when it came out disappointing or crumbling all those investment are lose. Such as many companies that was making game for SEGA platform and wasted their investment for the license to develop on console that not being sold
I’m not sure that’s the case. I don’t live in the future, and I develop and ship games now. So do most devs, I think. People ship with Unity every single day.
Sure, it was iffy before Riccitiello got ousted - it looked like Unity might slowly decay into tech debt and obscurity. But new leadership is in place and are actively addressing tech debt, so the platform will remain strong years into the future. CoreCLR migration will also eventually release even if takes another year or two. And there is no true Unity alternative. I’ve tried them all.
No one invest in current. Everyone invest in future. I am not wait for development with the future
The development surely about what we currently have as engineer. I actually use unity 2022 for developing everything serious, such as company’s project
BUT for any tech demo or personal experiment we likely do it on beta or alpha. That’s what the kind of investment I am talking about. And even we are here watching unite keynote and reading this official post is also investment. We spend our time to learn what would happen and prepare ourselves to be ready for the next big thing we can do
And so when it was being disappointed, that was I would call opportunity cost
And I am doing this for 10 years, when it was disappinted so much I need to reconsider my future with unity, that was sunken cost
the things is, we’re being strung along in the migration process for over 4 years now. It should have taken them 2. maybe 3 since they have to change their cpp code for the new gc. but we’re now over 4 years and there’s still not even an alpha in sight. literally put every single developer at unity to this task before doing anything else. instead unity and everyone depending on them is falling behind of .net evermore. what do i care that unity wants to move burst and tmp into the engine itself, if they work perfectly fine as packages right now?? or optimizing a feature that will run twice as fast already after the migration already anyway?? that stuff has benefit but that slight benefit i am very willing to take after the foundation is done.
That was under old Unity leadership and organization. Before they closed off half their offices, restructured and had a full blown coup at the top end. These things take time to sort out.
It was known for a very long time that CoreCLR won’t come to Unity 6 so there are no surprises. Furthermore, we have an open beta date set for 2025, which also isn’t a surprise considering Unity 6 timeline.
Why are people throwing a fit over obvious things again? Rein in your expectations. Unity are not doing anything to you, you are stringing yourself along with overblown expectations.
Adding manpower to a late software project makes it later. See Brook’s law: Brooks's law - Wikipedia
You can’t really make those judgements based on some surface details they’ve revealed. Core integration and ECSification of core systems is a sound approach. Next Gen Unity will be a much larger step forward than just an incremental improvement year over year we’ve had for so long since they switched to the yearly model. They are returning to proper releases with significant changes in them.
A question if I may - My experience up to date with Unity’s Burst is that it adds another ‘process’ to every code change with extra few seconds (up to half a minute) of compiling Burst whenever I change code that doesn’t even deal with Burst. As a result, myself, and other threads & users have a common suggestion of disabling burst as we iterate. Do the changes such as Code Reload plan to mitigate this? Can they?
I’d hate not being able to turn the burst step off and watching it trying to build after every change…
Will we also be able to manually register and unregister? (such as for a case of registering multiple parameterized versions of the same class?)
Eagerly waiting to try out and compare Code Reload to see just how quick project iteration gets!
Does that mean MonoBehaivours will become CLRBehaviours?
Making the real questions here jokes aside, would be interesting to know if they are going to get rid of the messaging system (Start, Update, etc.) in favor of using virtual methods
Yeah I feel the same reading recent updates on other topics. CoreCLR will definitely ship. I don’t mind waiting for another year or two though. This thing is too deep in the foundation, not to mention the vast amount of 3rd libraries and assets which also have to accomodate this kind of changes.