Remix.run Logo
makotech221 a day ago

Yeah I think Unity just doesn't have the technical skillset anymore to make the migration to coreclr. It keeps getting delayed and their tech leads keep dropping out.

Might I suggest https://github.com/stride3d/stride, which is already on .net 10 and doesn't have any cross-boundary overhead like Unity.

WillPostForFood a day ago | parent | next [-]

Progress has been painfully slow, but Unity does seem to be moving forward.

Unity updates on their plans and progress:

2022 - officially announced plans to switch to CoreCLR - https://unity.com/blog/engine-platform/unity-and-net-whats-n...

2023 - Tech update - https://unity.com/blog/engine-platform/porting-unity-to-core...

Unite 2025 - CoreCLR based player scheduled for Unity 6.7 in 2026 - https://digitalproduction.com/2025/11/26/unitys-2026-roadmap...

teraflop a day ago | parent | next [-]

Maybe they are making progress. But given that they first started talking about this in 2018, and then in 2022 they announced that they were planning to release a version with CoreCLR in 2023, and then in 2024 they said it would be in beta in 2025, and now in 2025 they're planning to release it as a technical preview in 2026, but they're still talking about an "internal proof-of-concept" as though it's something coming in the future...

As an outsider, it certainly seems like there's reason for skepticism.

whstl a day ago | parent | next [-]

I've seen similar things from the inside in other companies. Even existential threats (like lack of Apple Silicon support for performance-critical software), getting heavily delayed because the feature treadmill won't stop and the actually important thing is a pet project of some engineer. It is basically death by a thousand papercuts, where nobody can say what the focus is.

People complain about web development but working with native apps can be depressing sometimes.

cheschire a day ago | parent | prev [-]

Well they made some business decisions in the middle of that timeline that cut their funds quite a bit, not to mention probably scared off some good talent.

ACS_Solver a day ago | parent | next [-]

Not just probably scared off some good talent, they had xoofx leave over disagreements with higher management. xoofx was one of their most senior devs, the guy who started the CoreCLR migration and was leading it.

They'll get there eventually, but the current roadmap says experimental CoreCLR in late 2026, which then in the best case means production ready in 2027. Unity isn't going anywhere, but at least as a dev who doesn't care about mobile (which is Unity's real market), competing engines have gotten much more attractive in the last couple years and that seems set to continue.

whstl 11 hours ago | parent [-]

The funny thing about his resignation is that xoofx had a CoreCLR prototype already working around 2016-ish, but the company had "other priorities" and only took it seriously until recently.

The guy should just have been left alone and shielded from company bullshit to do the migration, or empowered to fight.

I know this is one sided but: Whoever from high-management lost this guy is an absolute loser waste of space who didn't do his job and will blame xoofx for “not fighting harder” or some other bullshit. Fuck companies, and fuck loser managers.

ACS_Solver 10 hours ago | parent [-]

I think 2016 is a bit too early but yeah, xoofx first wrote about CoreCLR in 2018 and said he'd made considerable progress with something like himself and two other engineers doing it as a side project. That is four years before Unity as a company announced the migration as a priority, which in turn is another four years before the current estimate for when they may ship it.

From my perspective, Unity seems very poorly managed in recent years. The editor experience isn't improving while they continue the usual pattern of shipping features in a poor state where they need another couple versions to become properly usable, and of course they make terrible decisions like the runtime fee, a total insanity that caused a huge loss of trust and boosted Godot development enormously.

Of course my perspective is biased by me not being Unity's main target market. I work on PC strategy games, which are on Steam. At our studio, we don't do mobile, advanced graphics features aren't very relevant, and we may have the most complex UI that ever shipped in a Unity game.

chris_wot a day ago | parent | prev [-]

Scared off a lot of customers, too.

bentt a day ago | parent | prev [-]

Nice link, thanks.

999900000999 a day ago | parent | prev | next [-]

Stride has a fraction of the features as unity.

Godot is the only real open source competitor, their C# support is spotty. If I can't build to Web it's useless for game jams as no one should be downloading and running random binaries.

A real sandbox solution with actual GPU support is needed.

dustbunny a day ago | parent | next [-]

Writing C# in godot is a bad choice. Use GDScript and directly write c++ as a module. Skip "HD extension" completely. Godots build system is easy enough to use. Just add new classes to the engine using c++ if you don't want to use GDScript. The GDScript workflow is honestly great. Using C# is like the worst of all worlds.

enbugger 12 hours ago | parent | next [-]

GDScript is not very maintainable as the code base grows. It lacks proper refactoring tools (e.g. the ones from Jetbrains Rider), static type checking, flexible object system and many 3rd party libraries which might be needed

dustbunny 6 hours ago | parent [-]

My main point is: if GDScript isn't good enough, go straight to c++ directly in the Engine.

I won't even get into how big of projects I've written in GDScript successfully.

2 hours ago | parent [-]
[deleted]
pjmlp 12 hours ago | parent | prev | next [-]

Problem is, GDScript still doesn't have at least a JIT, and the whole GDextensions boilerplate seems more complicated than it needs to be.

dustbunny 5 hours ago | parent [-]

"not having a JIT" is not a problem, it's you speculating that a JIT will improve performance, the real problem is "GDScript has poor performance", which in this context (me saying C# in godot sucks) is you speculating that C#'s performance is better than GDScripts. Do you have any data to back that claim up? Like real world data from a real product? Or are you just speculating with vibes?

If performance is a concern, skip C# and go straight to c++. Now your ripping at max speed with the smallest binary! That's my whole point. GDScript + c++ is my point. Ditch C# it's not worth the squeeze.

pjmlp 3 hours ago | parent [-]

Some people like nice tooling with performance.

Interpreter code is never faster than a dynamic compiler, otherwise what about doing games in Python?

As mentioned on my comment, GDextension experience kind of sucks.

joha4270 12 hours ago | parent | prev | next [-]

Are there technical reasons to prefer GDScript over C#?

GDScript is undoubtedly better integrated in the engine, but I would have expected C# compare more favorably in larger projects than the game jam sized projects I have made.

et1337 6 hours ago | parent [-]

Performance is one issue with C#: https://sampruden.github.io/posts/godot-is-not-the-new-unity...

joha4270 5 hours ago | parent [-]

I don't see how this article could possibly support the argument that C# is slower than GDScript

It compares several C# implementations of raycasts, never directly compares with GDScript, blames the C# performance on GDScript compatibility and has an strike-out'ed section advocating dropping of GDScript to improve C# performance!

Meanwhile, Godot's official documentation[1] actually does explicitly compare C# and GDScript, unlike the the article which just blames GDScript for C#'s numbers, claiming that C# wins in raw compute while having higher overhead calling into the engine

[1]: https://docs.godotengine.org/en/stable/about/faq.html#doc-fa...

et1337 5 hours ago | parent [-]

My post could have been a bit longer. It seems to have been misunderstood.

I use GDScript because it’s currently the best supported language in Godot. Most of the ecosystem is GDScript. C# feels a bit bolted-on. (See: binding overhead) If the situation were reversed, I’d be using C#. That’s one technical reason to prefer GDScript. But you’re free to choose C# for any number of reasons, I’m just trying to answer the question.

joha4270 4 hours ago | parent [-]

At least in my case, I got curious about the strength of /u/dustbunny's denouncement of Godot+C#.

I would have have put it as a matter of preference/right tool with GDScripts tighter engine integration contrasted with C#'s stronger tooling and available ecosystem.

But with how it was phrased, it didn't sound like expressing a preference for GDScript+C++ over C# or C#++, it sounded like C# had some fatal flaw. And that of course makes me curious. Was it a slightly awkward phrasing, or does C# Godot have some serious footgun I'm unaware of?

et1337 4 hours ago | parent [-]

Makes sense! I think dustbunny said it best: C# is “not worth the squeeze” specifically in Godot, and specifically if you’re going for performance. But maybe that’ll change soon, who knows. The engine is still improving at a good clip.

999900000999 a day ago | parent | prev [-]

I don't like C++.

It's very difficult to me, I generally stick to high level stuff , C#, JavaScript, Python, Dart, etc.

chris_wot a day ago | parent [-]

If you can code in C#, how is C++ difficult? Are pointers and the stl that difficult?

Not denigrating, genuine question.

999900000999 21 hours ago | parent | next [-]

One word.

Headers.

That's just the start. The C++ build system and package managers are the stuff if nightmares. Modern languages are significantly easier to use.

Don't get me wrong, if you offer a job with a 200k base salary and give me 6 months to learn C++ I'll do it. But I won't enjoy it, and I definitely won't do it as a hobby.

runevault 21 hours ago | parent [-]

If you use an existing template (and are willing to use scons) GDExtension doesn't really have the standard build problems of rigging everything up with CMake/etc in my experience. The template is set up to handle the "set up the build" problem for you. Still have the header problem though cannot deny that one.

Kwpolska 14 hours ago | parent | prev | next [-]

You're asking if going from a high level language to a low level language on steroids is difficult?

Pointers, manual memory management, and the design by committee standard library are not fun.

atraac 14 hours ago | parent | prev | next [-]

I write mostly backend stuff for a living, big chunk of it in Node/TS but also C# with modern .NET. I also have to dabble with Unity and Unreal both for work and a hobby project. I technically learned C++ in uni but really, I hate every single second I have to spend doing Unreal Engine work. I genuinely despise how obsolete and hard to write C++ is compared to modern languages. It didn't bother me in university because that was all I knew at the time but it's hard to justify existence of header files today. Add macros everywhere, really bad compilation errors, really hard to read syntax with a lot of unnecessary bloat and you get something that is just not likable. I'm sure you can get used to it given enough time spent in that ecosystem, but I can tell you as someone writing 4 different languages on day to day basis, C++ is difficult, and it's not because of pointers.

dustbunny 6 hours ago | parent [-]

Yeah that's why GDScript is great.

You only dabble in the c++ for the sliver of the project that needs it. 90% of game development is animating stuff and user interface development. GDScript is great for that.

DonHopkins 17 hours ago | parent | prev [-]

Java was designed to make fun of C++, then C# was designed to make fun of Java, so you're missing two layers of fun.

999900000999 16 hours ago | parent [-]

I can tolerate Java. I've worked a Java dev role recently.

I think it's overly verbose and probably has a lot of unneeded legacy stuff, but in terms of making money so I can afford donuts, it's not bad.

My personal favorite language is probably Dart, but it's basically useless outside of Flutter and I don't have faith in Google to keep Flutter going.

I don't like low level programming. My dream language is literally an LLM that processes a markdown document where I sorta just describe what I want to happen. With options to call defined functions in a normal programing language

If I had money ( VC money) I'd be working on this.

CyanLite2 18 hours ago | parent | prev | next [-]

I think WebAssembly could become that sandboxed solution. .NET Blazor WASM is moving away from mono to CoreCLR (just like Unity, with an early preview in late 2026). WASM now has really good SIMD support, native GC, large memory support, and with WebGPU we could finally see some native WASM games running at native speeds.

bloomca 8 hours ago | parent [-]

Wait, what, WASM has native GC now?

WorldMaker 6 hours ago | parent [-]

It's still not JS-level/JS-compatible GC (yet?) and it is still quite low level (more about corralling buffers of bytes than objects, a bit closer to OS-level page management than JS or C# level GC), as it is intended to be lower level than most languages need so that different languages can build different things with it. It is also a tiny stepping stone to better memory sharing with JS APIs (and the eventual goal of WASM "direct DOM"), but still not quite finished on that front as more steps remain.

eole666 a day ago | parent | prev [-]

Godot 4 C# web export is coming soon : https://github.com/godotengine/godot/pull/106125

999900000999 a day ago | parent [-]

We'll see when it actually ships.

I've seen this issue before, they're making progress but theirs no firm release date.

Plus you then have to extensive testing to see what works in Web builds and what doesn't. I REALLY enjoy vibe coding in Godot, but it's still behind Unity in a lot of ways.

ramon156 a day ago | parent [-]

Naive question but why not use GDscript? I haven't had any issues with it

999900000999 a day ago | parent | next [-]

I'll vibe code stuff in GDscript, and I guess I more or less understand some of it.

But C# is what I've used for over a decade. C# has vastly better IDE support. It's a more complete language.

Plus a lot of C# assets/libraries don't really have GDScript counterparts.

eole666 13 hours ago | parent | prev [-]

I'll add that C# have better performances than gdscript. It doesn't make a difference for most of the things you code in a game, but it comes in handy when needed.

linguistics__ 10 hours ago | parent | prev | next [-]

> Yeah I think Unity just doesn't have the technical skillset anymore

It's not a technical skillset issue, it's a case of lacking resources, leadership changing priorities and changing requirements mid-development, causing a lot of work to be redone.

We still have highly skilled developers working in this area, if we can just actually be allowed to do (and keep) we work we have.

darubedarob 14 hours ago | parent | prev [-]

Imagine you have to communicate that rewrite and drop of support for bought "addons" to the people who went on that shopping spree. Who then would have to explain the "wecan"-value drop + cost of recovery of the same abilities to the shareholders and customers. The magpiesnest of bought companies tech is a tarbaby for any tech lead, the rewrite a career ender for the CEOs office.