Live data from Hacker News

C# in Unity 2026: Writing more modern code

darkounity.com

21–30 of 105 posts

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

#21
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…

To be a bit more charitable: I'd say that generally games involve a lot more special-casing than most code, and more planned out scripts (in the movie sense) of things happening, which tend to be antithetical to good coding practice, and encourage spaghetti, which begets more. In my experience, games that are procedural tend to be much cleaner code-wise, because they tend to fit the model of cleaner code better.

I think game engine tooling tends to encourage bad code too, lots of game engine make it hard to do everything in code, rather things are special cased through UIs or magic in the engine, which means you often can't use all the normal language features, and have to do things in awkward ways to fit the tooling.

Of course, this varies a lot by engine.

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

#22

What C# version does Unity currently support? 2024 I chose Godot over Unity due to its better C# support and I can’t say that I came to regret my decision.

C# 9, but with some hacks you can bump it up to C# 10 - actually works and surprisingly stable. Can't wait for them to finally migrate to CoreCLR, though.

I got out of doing Unity development 7 years ago because I was tired of waiting for them to migrate to CoreCLR (among many other reasons).

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

#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 using absolute bog standard elements of the language (and thus being clear, easy to comprehend for everyone, easy to modify at any point) rather than a super short, super "elegant", super "clever" solution.

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

#26
Game developers are not paid to be good developers. They're paid to be young, naive, and easily brow-beat into working unpaid overtime.

I think one of my biggest problems with Unity is that it enabled a massive market of me-too "business men" who "employ" unpaid and underpaid interns to hack together asset-store-ware they then dump on the app stores. When a gem game stutters, people blame their crappy phones rather than the company who probably stiffed its developers.

I've seen a lot of my friends do this constant churn of signing up for the next game shop that will hire them. Places that throw many, many red flags the second you even walk in the door. They work hard to get a game done on a budget 1/10th what it should be, the game ends up being a flop, and they never get a chance to grow their portfolio or skills to eventually get a better job.

This isn't something you can lay at the feet of Unity Technologies, but I do think it is a reason to avoid Unity: the job ecosystem is just awful.

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

#27
post #10

Earlier quoted context omitted.

Since it's a multi-discipline craft it's hard to get good at every aspect for indie development, focusing most of the effort on one or two aspects. I think the programming aspect for indie games typically matters very little unless it hurts performance or causes bugs, and the things the user interacts with end up mattering a lot more. Every web developer I've met has specialised in one area or another, even if they c…

Problem is that this kind of code often is brittle, full of bugs and unhandled edge cases, and evolution and maintenance is horror. But if it’s all you know you might never question it.

A game is finished at some point. You might not need to evolve the code any further. Why optimize for a use-case that rarely applies to indie-games?

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

#28

Fans of LINQ may enjoy ZLinq[0], which is a less versatile but much more performant way to write LINQ-like queries. I certainly use a lot of (Z)Linq in my code; the performance tradeoff is just fine for one-off initialization, UI code, editor tooling, etc. [0]: https://github.com/Cysharp/ZLinq

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)

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

#29
Doesn't hn clean article titles? This is a classic click baity one. Most of these are just basic features. Some are unused for good reason.

- Property: the inspector doesn't call your getter or setter. I do use them still because i like to centralize my validation logic. But need custom machinery to make them behave consistently.

- Tuple: well-known. Good but only in moderation.

- Linq: people avoid it due to allocations, not runtime. While it is possible to avoid dynamic alloc, it is not obvious and best avoided. Also the point about the linq syntax being "cleaner" is debatable.

- Record: good. Lesser known as it's the newest in the article. No footguns like the other.

While it is nice that this is human written, the seo format is nearly as annoying as those ai articles.

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

#30
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…

It's an indication that programming languages are the wrong abstraction for creative work
Post reply on HN