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

91–100 of 105 posts

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

#91

Post by drzaiusx11 »

seabrookmx wrote: post #75
drzaiusx11 wrote: post #38

Earlier quoted context omitted.

Mono was in a usable state on Linux for literal decades before becoming official and integrated into what is core today, that is unless you needed windows forms, which much like MSFT UI frameworks today had multiple failed attempts spanning those same decades...

Only if you didn't care about performance. We attempted a move to mono for backend web services maybe 3 years before .NET Core released, and it was a complete no-go. 10x reduction in performance on the same hardware. This wasn't specific to our workload either. I was big into the game Terraria at the time, and I saw similarly poor performance when running it's game server under mono vs .NET 4.x While some of the mono…

Great context, thanks! I knew it worked (I closely followed mono development at the time) but I didn't have a windows license/windows machines at the time it was ongoing to compare it to. 4x is pretty bad, any ideas what went wrong? Lack of jit maybe? I forget the exact architecture of mono at that time, being like 20 years ago...

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

#92

Post by drzaiusx11 »

tryfinally wrote: post #61
drzaiusx11 wrote: post #28

Earlier quoted context omitted.

Zero allocation impl? very cool! Arguably, the original runtime should have done this in the first place given the limitations/tradeoffs aren't so bad, but I guess that ship sailed 20 years ago (man that hurts)

The modern .NET runtime can get devirtualize interface calls and eliminate temporary object allocations in some scenarios. It's a bit of a black box - who knows when it actually works? - but still, it's a nice boost here and there.

I assume it's not a black box anymore, but maybe that's a non-free lang extension? I had assumed linq was part of .net core these days, but I haven't gotten around to checking (10+ years since I've had a serious .net project)

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

#93

Post by PacificSpecific »

AppleBananaPie wrote: post #72
rustyhancock wrote: post #57

Earlier quoted context omitted.

I can't comment on Godot or Unity which both use primarily C#. Unreal engine which uses C++ primarily, has the problem that it's a humongous mostly legacy code macro heavy system . If anything being proficient in C++ before you start is harmful because of the puckering of orifices when you hear about it's mostly quirky powerful macros all the way down.

Never worked with it myself but I've always heard the people who do describe it as Unreal c++ because to them it's completely different than regular c++ and this must be one of the reasons why

That's pretty much correct. I kind of have to switch to "unreal c++" context whenever I'm working in it. They have their own standard library etc

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

#94

Post by gamblor956 »

doctorpangloss wrote: post #90
jayd16 wrote: post #89

Earlier quoted context omitted.

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…

There are hundreds of sites devoted to discussing game design and literally millions of posts.

This isn't a game design forum, it's a tech forum, so the focus is on the tech part of games.

Unity is very easy to use. If you want to make a game for Steam or iOS it is almost as simple as drag-and-drop, then selecting Publish from the main menu. The difficulty in getting a game on Steam or iOS is in the administrative roadblocks thrown up by the stores themselves, not the engines. You don't need to ever deal with C# in Unity. If you have difficulty using Steam, neither programming or game design is for you.

Claude and vibe programming don't lead to shipped games. They lead to crap that nobody wants to play because they aren't games. They're just poorly performing tech demos with bad art because they can't design games. They can just copy parts of other games without understanding why they work...but based on your comments about turning board games into software games it appears that is what you actually want.

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

#95

Post by hacker_13 »

everyone wrote: post #23

I'm a very experienced Unity C# programmer, and I certainly don't equate "good" with using all the new fancy features of a language. Fancy features are less maintainable imo. Less programmers will know about them and they're less likely to have equivalents in other languages. Making something more exotic / confusing / hard to parse is defo not worth saving a few lines of code.. I'd much rather see a longer function u…

It's why Golang is my favorite language now. I am not learning 30 ways to learn the same thing :)

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

#96

Post by seabrookmx »

drzaiusx11 wrote: post #91
seabrookmx wrote: post #75

Earlier quoted context omitted.

Only if you didn't care about performance. We attempted a move to mono for backend web services maybe 3 years before .NET Core released, and it was a complete no-go. 10x reduction in performance on the same hardware. This wasn't specific to our workload either. I was big into the game Terraria at the time, and I saw similarly poor performance when running it's game server under mono vs .NET 4.x While some of the mono…

Great context, thanks! I knew it worked (I closely followed mono development at the time) but I didn't have a windows license/windows machines at the time it was ongoing to compare it to. 4x is pretty bad, any ideas what went wrong? Lack of jit maybe? I forget the exact architecture of mono at that time, being like 20 years ago...

It did have a JIT, it just wasn't a very performant one. I recall the GC implementation also being quite slow. GC is an area where .NET is still making strides.. we got a new collector in .NET 10.

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

#97

Post by PacificSpecific »

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,…

Based on your comment it sounds like you have a personal problem with that person which compromises your argument

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

#98

Post by Archit3ch »

simonask wrote: post #47
shevy-java wrote: post #19

> The Unity engine has evolved a lot in modern days, but I noticed a trend where Unity developers are still using "outdated" techniques when writing their C# code. Some years ago I tried to get into C# + Mono. Eventually I opted for Java instead, for many reasons; I'll skip that here. C# is very strange to me. In a way I feel that C# belongs like Java in the same "post C++" family; C kind of paved the way, C++ was me…

C# has a unique powerful position in the video game space. In almost every other niche, there are better (or just trendier) solutions, but C# is the only major language that actually gives you a combination of features that are important in video games: - Dynamic runtime with loose coupling and hot reload of code - extremely useful during development. - Value types. You don't want every Vector4 to be heap allocated w…

> no other language offers all three

Julia. Of course with the added downside that it's not deployable (asterisk here), which is somewhat important for games. IDE and debugger could be better, but at least it doesn't insist on classes like C#.

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

#99

Post by pjmlp »

rustyhancock wrote: post #57
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 can't comment on Godot or Unity which both use primarily C#. Unreal engine which uses C++ primarily, has the problem that it's a humongous mostly legacy code macro heavy system . If anything being proficient in C++ before you start is harmful because of the puckering of orifices when you hear about it's mostly quirky powerful macros all the way down.

Godot uses C++, and even though there is a C# version, most folks either use GDScript, or GDextension with C++, Rust.

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

#100

Post by pjmlp »

drzaiusx11 wrote: post #92
tryfinally wrote: post #61

Earlier quoted context omitted.

The modern .NET runtime can get devirtualize interface calls and eliminate temporary object allocations in some scenarios. It's a bit of a black box - who knows when it actually works? - but still, it's a nice boost here and there.

I assume it's not a black box anymore, but maybe that's a non-free lang extension? I had assumed linq was part of .net core these days, but I haven't gotten around to checking (10+ years since I've had a serious .net project)

LINQ has always been around since it was introduced, the only non-free language extension in .NET were contracts that required VS Enterprise license.
Post reply on HN