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 having a slick game with some code doing some mundane stuff in the background.
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
I agree. I came to Unreal with only a basic level of C++. Having Unreal handle memory management for you was useful, but I can imagine the chaos an Unreal-only C++ developer might cause when unleashed on another C++ codebase.
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.
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.
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.
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)
Most .NET projects that Linq originally targeted ran in so called "Server" and/or "Workstation" GCs (.NET has had very generic public names for its GCs for a long time which were also somewhat misnomers because even some Desktop apps would run in "Server" GC and it was possible for vice versa [0]) where allocations were cheap, garbage collection was relatively cheap (because both GCs were multi-generational, had strong [but different] tuning for their generations, etc).
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.
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)
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.
Languages that seem to indefinitely grow more features over time (like c++, c#, rust, etc) evitably become bucketed by epochs unless the consuming application code also operate across the same time scales. Feature deprecations tend to go hand in hand with newer features, leaving you with basically "multiple sublanguages" in a supposed single language, exacerbating fragmentation of the community. I don't want to have the mental load of contextually understanding "which" sublanguages I need to care about depending on the year a consuming application was written. This is why I tend not to reach for new fangled features and stay with the core runtime stuff in evergreen langs.
I don't know... I feel like a lot of these features do increase developer intent without breaking muscle memory. Properties are got and set like fields. Record types feel like classes with restrictions so the linter can warn you about broken assumptions. etc etc.
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.
I disagree about LINQ. You can easily do the same job in a little function with only stuff people learn in week 1 of programming, just for and if else and arrays. It's very clear precisely what's happening in this case, and its easy to alter. (Everyone is gonna know that stuff, not everyone is gonna be using LINQ regularly enough to understand it completely)
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.
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.
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 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.
I started using .Net with 2.0, learned the api and framework and was very happy with all the functions. i never had the need to switch to the more idiomatic idoms. Sometimes on the go i picked up some new tricks and adopted some new types. Form me a good programmer knows how to avoid cognitive overload and how things work under the hood. Why use LINQ when i can use a foreach or a hashmap. Most of the time people don't understand how i get so much performance out of C#, then i tell them KISS. And know your type system.
Unity's C# has always felt like C#'s mentally challenged cousin. C-not-so-sharp. The custom == convinced me that allowing operator overloading on built-in operators is one big mistake.
I am not a game developer (I've made a few in the past but didn't use any frameworks besides direct libsdl calls), but if this article rings true for anyone in that field I'm a bit surprised things as basic as properties, structs and tuples are "not used" by unity devs, this is some basic stuff that has been supported even by Mono for decades. Just basic syntactic sugar though, so not a big deal either way. Just surprising to me at least.
> 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 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).
c# 14 added field backed properties where you dont need that _health in the first place you just write public int Health { get => field; set => field = Mathf.Clamp(value, 0, 100). that way you never accidentally use the internal field without the checks. problem is unity still stuck on c# 9.0 so it might be years before you can actually use this in a game
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 just mail you a check every month. How the times have changed...
I prefer Godot over Unity honestly. Not just because the engine feels better but because it's accessible, which is what matters to me. Unity isn't and probably never will be, so meh. Sure you can make accessible games in it but the editor itself isn't accessible so it kinda defeats the point of being able to make accessible games in it in the first place. And don't even get me started on Unity's licensing model. Godot's superior C# support is, IMO, just a cherry on top.
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.
idk, maybe the youtube algorithm just gets people to click on the video, what do they care why a video is clicked on as long as it generates revenue. so when they talk about videos being useful, take that to the bank.
102 comments
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 don't want to design anything in any UI.
I had the same need and found Raylib_cs suit very well for that
[0]: https://github.com/Cysharp/ZLinq
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.
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 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.
> 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 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).
_healthin the first place you just writepublic int Health { get => field; set => field = Mathf.Clamp(value, 0, 100). that way you never accidentally use the internal field without the checks. problem is unity still stuck on c# 9.0 so it might be years before you can actually use this in a gameI 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...
https://www.youtube.com/watch?v=_t6xVfrmEWU
It's also worth noting that Unity does all sorts of OO-breaking filth before passing to IL2CPP.