Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C# in Unity 2026: Writing more modern code

darkounity.com

Post reply on HN
Print view View original

81–90 of 105 posts

Re: C# in Unity 2026: Writing more modern code

#81

Post by enbugger »

pjmlp wrote: post #31
coinfused wrote: post #25

Looking forward to when Unity will migrate to CoreCLR. Soon! https://www.youtube.com/watch?v=_t6xVfrmEWU

That soon is like a decade in the making. And with many folks going into alternatives like Godot, it means C# ends up losing the mindshare it got. Yes, you can use C# with Godot, but most folks end up with GDScript, or GDextension.

Godot is nowhere near to something like C# HPC, Jobs and Burst. And I’m afraid even GDExtension can’t help with that. At least not with Godot’s scene structure which prioritises simplicity over performance.

Re: C# in Unity 2026: Writing more modern code

#82

Post by MattRix »

grebc wrote: post #35
captainbland wrote: post #14

Earlier quoted context omitted.

I think as a solo developer there's actually a good argument for increasing code density and coupling (things which in large multi developer projects are seen as spaghetti), as it can help you keep a lot of that code in mental and visual context at one time. It loses flexibility and readability for others, but you don't usually have enough time to concern yourself with such flexibility if you're working on a project…

This is pretty anti-thetical to most good practices but the older and more experienced I get the more(13 years as a C# dev) I think copy & pasting sections of code is wayyyyyy more appropriate than extracting into a method/class/library or other forms of abstraction. Everything starts out with good intentions when someone comes along and says “hey you could make that an abstraction” and I just clench my jaw because I…

100% this. All the abstractions and OOP stuff make you end up with a codebase where half the code doesn’t actually DO anything in the product itself, it just connects to other code! It also becomes impossible to follow the flow of execution because it passes through dozens of files and layers of abstraction.

Re: C# in Unity 2026: Writing more modern code

#83

Post by MattRix »

leloctai wrote: post #39
weli wrote: post #2

A lot of game devs are terrible programmers. A friend of mine 10 years ago asked me for help with his Unity project. He is not a tech savvy person but we both took programming in high school, enough for him to make small games with a lot of tutorials and stack overflow. His codebase was horrible, a lot of logic that I would have already though of abstracting away. For example saving dialogs on json files and the cond…

The other day a professional gamedev was arguing with me that's Transform.GetChild to get a reference to a component was not a bad practice. His argument is that it's what every other firms in his area is also doing. I do hope that was not the truth and he was just trying to win the argument. For solo hobby dev it is a lot more acceptable. After all they're also terrible 3d modeler, concept artist, musician, writer,…

I mean it’s not that bad of a practice, it depends on the context.

Re: C# in Unity 2026: Writing more modern code

#84

Post by WorldMaker »

kbolino wrote: post #80
WorldMaker wrote: post #71

Earlier quoted context omitted.

The third bullet is also presumably referring to C#'s ancient wider support for unsafe { } blocks for low level pointer math as well as the modern tools Span and Memory which are GC-safe low level memory management/access/pointer math tools in modern .NET. Span /Memory is a bit like a modest partial implementation of Rust's borrowing mechanics without changing a lot of how .NET's stack and heap work or compromising a…

The FFM API actually does cover a lot of the same ground, albeit with far worse ergonomics IMO. To wit, - There is no unsafe block, instead certain operations are "restricted", which currently causes them to emit warnings that can be suppressed on a per-module basis; it seems the warnings will turn into exceptions in the future - There is no "fixed" statement and frankly nothing like it all, native code is just not a…

> - There is no unsafe block, instead certain operations are "restricted", which currently causes them to emit warnings that can be suppressed on a per-module basis; it seems the warnings will turn into exceptions in the future

Which sounds funny because C# effectively has gone the other direction. .NET's Code Access Security (CAS) used to heavily penalize unsafe blocks (and unchecked blocks, another relative that C# has that I don't think has a direct Java equivalent), limiting how libraries could use such blocks without extra mandatory code signing and permissions, throwing all sorts of weird runtime exceptions in CAS environments with slightly wrong permissions. CAS is mostly gone today so most C# developers only ever really experience compiler warnings and warnings-as-errors when trying to use unsafe (and/or unchecked) blocks. More libraries can use it for low level things than used to. (But also fewer libraries need to now than used to, thanks to Memory/Span.)

> There is no "fixed" statement and frankly nothing like it all, native code is just not allowed to access managed memory period; instead, you set up an arena to be shared between managed and native code

Yeah, this seems to be an area that .NET has a lot of strengths in. Not just the fixed keyword, but also a direct API for GC pinning/unpinning/locking and many sorts of "Unsafe Marshalling" tools to provide direct access to pointers into managed memory for native code. (Named "Unsafe" in this case because they warrant careful consideration before using them, not because they rely on unsafe blocks of code.)

> MemorySegment is kinda like Memory/Span but harder to actually use because Java's type-erased generics are useless here

It's the ease of use that really makes Memory/Span shine. It's a lot more generally useful throughout the .NET ecosystem (beyond just "foreign function interfaces") to the point where a large swathe of the BCL (Base Class Library; standard library) uses Span in one fashion or another for easy performance improvements (especially with the C# compiler quietly preferring Span/ReadOnlySpan overloads of functions over almost any other data type, when available). Span has been a "quiet performance revolution" under the hood of a lot of core libraries in .NET, especially just about anything involving string searching, parsing, or manipulation. Almost none of those gains have anything to do with calling into native code and many of those performance gains have also been achieved by eliminating native code (and the overhead of transitions to/from it) by moving performance-optimized algorithms that were easier to do unsafely in native code into "safe" C#.

It's really cool what has been going on with Span. It's really wild some of the micro-benchmarks of before/after Span migrations.

Related to the overall topic, it's said Span is one of the reasons Unity wants to push faster to modern .NET, but Unity still has a ways to go to where it uses enough of the .NET coreclr memory model to take real advantage of it.

Re: C# in Unity 2026: Writing more modern code

#85

Post by thegrim33 »

MattCruikshank wrote: post #77
Fred27 wrote: post #52

As a primarily C# developer who has done some game engine work, I recently gave Godot a go for licensing reasons. Apart from some quirkiness I'm fairly impressed. Much nicer C# support compared to Unity. I've done a fair bit of Unreal C++ but to be honest unless you really need the performance that's just too much hard work. Having said that getting the code working properly with a nice 3D UI is my priority, not havi…

I don't want to design anything in any UI. I want to use a game engine as a library. I'm curious, as a primarily C# developer, how do you feel about Godot, in this respect?

It's 100% completely usable for that purpose. To the point where I'm internally using Godot as a backend for my engine, using it for rendering/system events.

It's also really good for a hybrid setup where you use their editor to design scenes, and then you can load/instantiate the scenes at runtime how/when you want. Or, just programmatically creates scenes yourself from code. You can really do whatever you want.

Re: C# in Unity 2026: Writing more modern code

#86

Post by mzhaase »

MattCruikshank wrote: post #77
Fred27 wrote: post #52

As a primarily C# developer who has done some game engine work, I recently gave Godot a go for licensing reasons. Apart from some quirkiness I'm fairly impressed. Much nicer C# support compared to Unity. I've done a fair bit of Unreal C++ but to be honest unless you really need the performance that's just too much hard work. Having said that getting the code working properly with a nice 3D UI is my priority, not havi…

I don't want to design anything in any UI. I want to use a game engine as a library. I'm curious, as a primarily C# developer, how do you feel about Godot, in this respect?

You can do everything from C#, rider launches the player only for debugging if you want. The only thing you probably do want to use the UI for is for... building UIs.

Re: C# in Unity 2026: Writing more modern code

#87

Post by pjmlp »

enbugger wrote: post #81
pjmlp wrote: post #31

Earlier quoted context omitted.

That soon is like a decade in the making. And with many folks going into alternatives like Godot, it means C# ends up losing the mindshare it got. Yes, you can use C# with Godot, but most folks end up with GDScript, or GDextension.

Godot is nowhere near to something like C# HPC, Jobs and Burst. And I’m afraid even GDExtension can’t help with that. At least not with Godot’s scene structure which prioritises simplicity over performance.

I agree, however most indies don't need them, and most pros are getting into Unreal instead.

Also something like Burst is a workaround for using Mono with C#, which gets solved in Godot with C++.

How's the whole DOTS adoption going?

Re: C# in Unity 2026: Writing more modern code

#88

Post by simonask »

WorldMaker wrote: post #84
kbolino wrote: post #80

Earlier quoted context omitted.

The FFM API actually does cover a lot of the same ground, albeit with far worse ergonomics IMO. To wit, - There is no unsafe block, instead certain operations are "restricted", which currently causes them to emit warnings that can be suppressed on a per-module basis; it seems the warnings will turn into exceptions in the future - There is no "fixed" statement and frankly nothing like it all, native code is just not a…

> - There is no unsafe block, instead certain operations are "restricted", which currently causes them to emit warnings that can be suppressed on a per-module basis; it seems the warnings will turn into exceptions in the future Which sounds funny because C# effectively has gone the other direction. .NET's Code Access Security (CAS) used to heavily penalize unsafe blocks (and unchecked blocks, another relative that C#…

Yeah, coming to C# from Rust (in a project using both), I’ve been extremely impressed by the capabilities of Span and friends.

I’m finding that a lot of code that would traditionally need to be implemented in C++ or Rust can now be implemented in C# at no or very little performance cost.

I’m still using Rust for certain areas where the C# type system is too limited, or where the borrow checker is a godsend, but the cooperation between these languages is really smooth.

Re: C# in Unity 2026: Writing more modern code

#89

Post by jayd16 »

doctorpangloss wrote: post #67
m_w_ wrote: post #56

Some nice tips in here ([field: SerializeField] for example) - but as others note, it's not about modern code, as many of these features have been available for an embarrassingly long time. It's always felt to me that there's some fundamental friction between idiomatic C# and Unity. I remember, after reading about new features C# 8.0, someone wrote that C# 9 would write all your code for you, and that C# 10 would jus…

game development for steam and mobile audiences became so inaccessible due to Unity, iOS and Android's complexity & evolution, a lot of "game" development was programmers engaging in an intellectually curious but otherwise meaningless engine-twiddling circle jerk of sorts. people with good game ideas were not necessarily able to tackle the complexity of those engines - and, based on how bad the games on Roblox are, t…

What a strange take. Self publishing stores and cheap capable engines make things less accessible? I think you're saying this is because its hard to stand out with game design?

But then AI will help good game design stand out? Wouldn't it make such a problem much much worse?

Re: C# in Unity 2026: Writing more modern code

#90

Post by doctorpangloss »

jayd16 wrote: post #89
doctorpangloss wrote: post #67

Earlier quoted context omitted.

game development for steam and mobile audiences became so inaccessible due to Unity, iOS and Android's complexity & evolution, a lot of "game" development was programmers engaging in an intellectually curious but otherwise meaningless engine-twiddling circle jerk of sorts. people with good game ideas were not necessarily able to tackle the complexity of those engines - and, based on how bad the games on Roblox are, t…

What a strange take. Self publishing stores and cheap capable engines make things less accessible? I think you're saying this is because its hard to stand out with game design? But then AI will help good game design stand out? Wouldn't it make such a problem much much worse?

This isn't complicated.

We're reading a post about engineering. Why? Why aren't we reading posts about game design? Why does engineering even matter for games?

The status quo is, if you are good at engineering, you can ship games, even if they're bad.

If you're good at game design and bad at engineering, before Claude code, you will not ship any games.

So engineering mattered back then.

Unity is very hard to use. If you want to make a game on Steam or iOS or whatever you need to know a lot of engineering.

Okay, now you don't. Claude code can engineer for you.

Now game designers can ship games. Do C# features matter to them? No. So does it matter for shipping games anymore? No.

Will this help them make money or get distribution? Time will tell. Very different questions. It is a CERTAINTY that you don't need the developers as much anymore.

If Steam had an easy way to turn photoshop files or board games into product SKUs, it would also be a different story. It doesn't. The App Store doesn't. The Switch doesn't. Are you getting it? They are still really complex to deploy for. Unity is hard to use. We put up with engineering stories because it was meaningful. Now it's not so much anymore. Now it's, what helps GAME DESIGNERS ship games? C# features? Not anymore.

Post reply on HN