C# in Unity 2026: Writing more modern code(darkounity.com) |
C# in Unity 2026: Writing more modern code(darkounity.com) |
Having said that getting the code working properly with a nice 3D UI is my priority, not having a slick game with some code doing some mundane stuff in the background.
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.
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 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.
I had the same need and found Raylib_cs suit very well for that
Unity inherited a much simpler Boehm GC from Mono. Under a (single generation) Boehm GC allocations are a bit more expensive and garbage collection sometimes a lot more expensive. (A Boehm GC was much easier for C++ engine code to understand/interact with, which is also part of why the .NET modernization project for Unity got so complicated and still has such a ways to go left.)
[0] Fun aside: in fact, modern docker advice for .NET is to switch "server applications" to use "Workstation GC" if you need to stack multiple containers on the same host because of differences in expected memory usage.
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.
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.
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 conditions for that dialog to trigger for that NPC as some sort of finite state machine that can be represented with a series of sequential flags. He had a single file that was about 15k lines full of `if (condition && condition) || (condition && condition)` statements. He didn't seem to see the issue, it just worked.
That's when I understood some people just care about game development and doing cool stuff and don't care at all about programming, good practices or structured code. And that's perfectly fine.
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 messy and powerful, so Java and C# would be more "managable". But I never got into C#. Java is not a pretty language, it is also quite boring, but modern Java is somewhat acceptable - you get the job done. And it is not an extremely difficult language either for the most part, just with an addiction on pointless verbosity. C# is ... strange though. TIOBE has it ranked #5 right below Java, so there must be many C# users, but I don't get to see them really in the Linux ecosystem. So where are these people all? Using Windows only? When the question is "most developers don't use feature xyz", do all of them actually KNOW these features? You can still find many java tutorial where people use archaic ways to, for instance, iterate over a collection. Perhaps it is similar to the C# ecosystem, people are slow to adopt. Or, and this may also be a reason, people could have moved to other languages. This may not be a huge percentage, but you see that some languages suddenly struggle with old devs and failing to get new devs (ruby is in this problem right now; it may overcome it but right now it is sinking hard, even though I would reason that the language is, for the most part, better than it was in, say, 2010).
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 just mail you a check every month. How the times have changed...
then claude code swung everything back in the other direction. things are accessible again. does any of what the article says matter anymore? games are the ultimate, "if it looks good and works correctly, it is good" software product, nobody is going to care if you use [field: SerializeField] or records or whatever.
so yeah, will Claude Opus 6 mail you a check every month? who even needs Unity?
But then AI will help good game design stand out? Wouldn't it make such a problem much much worse?
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.
It's also worth noting that Unity does all sorts of OO-breaking filth before passing to IL2CPP.
- 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.
Others increase readability. A LINQ statement is a lot easier to parse than a long block inside a foreach.
New doesn't mean good but a lot of these are new and good.
LINQ on the other hand is like another language entirely, awkwardly squished into your C#, reminds me of SQL code inside a big string inside another language's code. It's also not clear what it's actually doing which can be death for performance in games as LINQ usually allocates shittonnes of new stuff. (I'm certainly not advocating for premature optimisation, but I defo am advocating for knowing precisely what you are writing) The benefit of LINQ is that its a bit faster to write compared to a little function, but length-of-time-it-takes-to-actually-write-code is very rarely an important constraint in my experience.
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.
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 by yourself, and you're not concerned about onboarding other developers and having them understand your code. The upshot is then that as a single person "bad code" is often highly effective code, and "clean code" is expensive code that buys you a lot of stuff you don't need or want.
I say this as a boring enterprise developer who at work is highly concerned with appropriate abstractions etc. imo there's no universally good approach, what is optimal is context dependent. Although there are some core features of code like consistency and strong conventions which are fairly universally helpful, this represents a small fraction of best practices.
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’ve seen that happen so much and then that simple clean abstraction eventually ends up being a horrible 1000 line monster that barely anyone understands and no one wants to change.
This leads to e.g., everyday AoS vs. SoA, pooling and burst compile, to the classic fast inverse square root because of hardware at the time. Relentless optimization of hot paths produces code that's about performance, not abstraction. Then there's shaders, which are effectively a different programming model targeting different hardware entirely. Now add support for multiple operating systems, consoles, whatever. The list goes on.
Now, all of that doesn't obviate the value of design and craft, so I don't agree that it's "perfectly fine". There are plenty of programmers weak on these two axes in most any domain, but it's worth noting gamedev is a special case that significantly distorts what good code, or at least good-enough code, looks like.
Games start as little experiments and end up as Frankensteins. This is their nature; you're more sculpting a thing by building it and experiencing it rather than designing it a priori with systemic elegance in mind.
If anything, the most competent developers in terms of getting the most performance out of hardware are game developers.
I’ve seen worse in enterprise shops and then I’ve gotten into nasty arguments with people who don’t care about programming. They can’t be wrong.
C# is a high level language that can handle a degree of sloppy programming.
I was working on a small tool yesterday. It was easier to vibe code it from scratch in C# than to modify an existing Rust project.
The only weird part is VS Code Copilot couldn’t figure out how to build it via the dotnet cli and I had to install VS Studio. After that everything was fine.
Combine that with actual hard performance constraints, and if you're a "normal" software dev casually browsing some game code, it can be shocking (eg Celeste movement code: https://github.com/NoelFB/Celeste/blob/master/Source/Player/...).
Every web developer I've met has specialised in one area or another, even if they claim the title of "Full Stack".
As an example, most of the gameplay logic for Post Apocalyptic Petra[0] (a 3D platformer/adventure/riddle solving game i made for an MSDOS game jam a few years ago) is in the entity class for the player character[1] - including things like collisions, etc :-P. It is a bit hacky, but it works.
Though if i ever made that sequel i wanted to where i want to have an extra character following you around, i'd need to move a bunch of things to other more generic places so that they can be shared by both the player character and the AI.
[0] https://bad-sector.itch.io/post-apocalyptic-petra
[1] https://codeberg.org/badsector/PetraEngine/src/tag/pap-0.99o...
And for professional game dev projects, it's all built on a foundation of some scrappy little indie project from decades ago.
Some industries are all about making their code public and making it super clean and polished as a point of pride. Games, like movies and sausage, are disgusting to see behind the scenes. They're just piles of scraps and weird tricks that look great unless you get down and examine it too closely. And most people aren't looking that closely, so wasting that time and effort is pointless.
For solo hobby dev it is a lot more acceptable. After all they're also terrible 3d modeler, concept artist, musician, writer, marketeer, community manager,...
Game dev is also a lot more agile than other projects. Solidifying structure is just more to rip up later unless you really know what you want to ship.
I personally use it quite a lot - but I came as a windows user writing all my utilities in C#. Also, afaik C# is mostly used in corporate environments that don't open-source their projects. You're unlikely to hear from it unless you're working on it for this very reason.
Also, yeah today Linux support is officially maintained in modern .NET and many corporate environments are quietly using Linux servers and Linux docker containers every day to run their (closed source) projects. Linux support is one of the things that has saved companies money in running .NET, so there's a lot of weird quiet loyalty to it just from a cost cutting standpoint. But you don't hear a lot about that given the closed-source/proprietary nature of those projects. That's why it is sometimes referred to as "dark matter development" from "dark matter developers", a lot of it is out there, a lot of it doesn't get noticed in HN comments and places like that, it's all just quietly chugging along and doesn't seem to impact the overall reputation of the platform.
- 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 when you're doing 3D graphics, because that's going to be absolutely unusable.
- Access to a relatively low-level substrate for basically-native performance when needed - extremely useful when you're trying to actually ship something that runs well.
Taken in isolation, C# isn't best in class for any of them, but no other language offers all three, especially not if you also want things like a really good debugger and great IDE tools.
To my knowledge, Java has none of these features (yet), and they aren't really important in a lot of the areas where Java is popular. But this is why C# in particular is very strong in the video games niche.
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#.
The first bullet is possible with the JetBrainsRuntime, a fork of OpenJDK: https://github.com/JetBrains/JetBrainsRuntime
The second bullet is a headline goal of Project Valhalla, however it is unlikely to be delivered in quite the way that a C# (or Go or Rust etc.) developer might expect. The ideal version would allow any object with purely value semantics [1] to be eligible for heap flattening [2] and/or scalarization [3], but in experimental builds that are currently available, the objects must be from a class marked with the "value" qualifier; importantly, this is considered an optimization and not a guarantee. More details: https://openjdk.org/projects/valhalla/value-objects
The third bullet (IIUC) is addressed with the Foreign Function & Memory API, though I'll admit what I've played around with so far is not nearly as slick as P/Invoke. See e.g. https://openjdk.org/jeps/454
[1] value semantics means: the object is never on either side of an == or != comparison; the equals and hashCode methods are never called, or are overridden and their implementation doesn't rely on object identity; no methods are marked synchronized and the object is never the target of a synchronized block; the wait, notify, and notifyAll methods are never called; the finalize method is not overridden and no cleaner is registered for the object; no phantom or weak references are taken of the object; and probably some other things I can't think of
[2] heap flattening means that an object's representation when stored in another object's field or in an array is reduced to just the object's own fields, removing the overhead from storing references to its class and monitor lock
[3] scalarization means that an object's fields would be stored directly on the stack and passed directly through registers
Sounds like you're just in a part of the ecosystem that doesn't touch C#. Aside from gamedev, C# is mostly a back-end web language, and almost all new builds are going to deploy to some Linux based serverless offering or something like Kubernetes. At my work, we're a mix of Python/Typescript/C# deploying to Google Kubernetes Engine and Cloud Run.
As for the language, your parallels to Java are accurate but outdated. Older versions of C# were very very similar to Java, but C# progressed when Java didn't. For better or worse (depending on your tastes), C# is more comparable to Kotlin or Swift these days than Java.
That's to say nothing of C#'s contributions to other programming languages; async/await and unsafe{} blocks were both first seen in C# before being adopted elsewhere.
We have not touched a Windows server in years.
In 2026 .NET is deployed like anything else into Linux containers and Lambdas. Obviously there are still people who love their ui based servers but that is because of that and not because of .NET.
Adoption of new features is gradually and explorative, obviously in an enterprise everything is on a LTS 2-3 back but adoption after that delay is rather quick to my observation.
.NET like Java have this "it is there and we extend it. And the new platform is also .NET because you have your dozens of devs already"
If you know Java, you should give C# a try. Its a slicker Java with some good decisions that actually make it viable for a lot of things Java struggles at, like better interop with pointers and things like native UI (Maybe Loom will eventually overtake async/await for UI dev but not quite yet).
It works very well on many more use cases than it used to. .NET has followed with the Linux servers in the cloud industry reality and is very stable.
Its just a good language. Try it out.
Many issues people associate with C#, are actually only relevant in Unity, because of this.
It has been a pretty common trend for the last few years of people breaking out of the “OOP style programming” and practices they were taught at university. I am not saying avoiding things like over abstraction is new, but I do think there is a newer generation of programmers who have been taught and warned about drawbacks from practices like that.
Similarly, my anecdotal experience tells me more newer game devs are aware of basic memory practices being better than overly complex OOP code. Think flat arrays and simple cache alignment over something abstract and over engineered
They still have a big problem gaining .NET adoption among those that were educated in UNIX/Linux/macOS first.
Mandy Mantiquila and David Fowler have had such remarks, I can provide the sources if you feel so inclined.
I have what I need working in C#, and as a C# developer I actually understand what’s going on.
The only downside is now instead of having a portable Rust project, I have something which heavily leans into Windows APIs.
I assume with high level languages some smart people figured out all the memory stuff.
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?
if only by rewriting half of the Godot codebase. With design choices they made, Godot will never be performant enough for RTS/Crown simulation games.
https://github.com/godotengine/godot/issues/101494
>How's the whole DOTS adoption going?
I'm quite impressed to what people build on top of it: https://github.com/Dreaming381/Latios-Framework https://assetstore.unity.com/packages/tools/animation/mesh-a... and many more
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.
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.
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 toolchain was integrated into .NET Core, CoreCLR was a rewrite and immediately solved this problem.
- 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 allowed to access managed memory period; instead, you set up an arena to be shared between managed and native code
- MemorySegment is kinda like Memory<T>/Span<T> but harder to actually use because Java's type-erased generics are useless here
- Setting up a MemoryLayout to describe a struct is just not as nice as slapping layout attributes on an actual struct
- Working with VarHandle is just way more verbose than working with pointers
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<T>/Span<T>.)
> 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<T>/Span<T> but harder to actually use because Java's type-erased generics are useless here
It's the ease of use that really makes Memory<T>/Span<T> 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<T> in one fashion or another for easy performance improvements (especially with the C# compiler quietly preferring Span<T>/ReadOnlySpan<T> overloads of functions over almost any other data type, when available). Span<T> 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<T>. It's really wild some of the micro-benchmarks of before/after Span<T> migrations.
Related to the overall topic, it's said Span<T> 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.
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.