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.
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.
Gamedev at a high level is similar in spirit to distributed systems or compilers in that it's intensely multi-disciplinary with hard constraints. In gamedev you have a main thread that you're always sweating about submilliseconds, especially with worker threads interfering with it. Processor, memory, bus characteristics, GPUs, cooling, etc. all matter.
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.
And that first bit only really matters if you're making a fast-paced game with sophisticated graphics. Most indie games can get away with horribly inefficient code.
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 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.
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.
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 claim the title of "Full Stack".
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.
Often but not always, and if they're a solo developer then maintenance might not be too bad as they might be able to keep all the logic in their head. I'm not advocating for that kind of approach, but if it lets people focus on things that the player will actually notice like the gameplay, graphics, sound, story or art then hey, what's a little shortcut?
Most indie game dev projects start as some small weekend project just to feel things out. Then it starts to become fun so we work on it another week. Then after a couple months we start to think that maybe the game has potential. Then we're 5 years into a project and have no clue how we got there. It becomes a giant jenga tower where moving any one block can completely collapse the whole project, so we learn the hard way that nobody should ever refactor. Pretty much the only people who do refactor end up restarting their project from scratch, getting frustrated because they can't capture their original feel of the game, then ultimately abandon the project entirely.
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.
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.
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.
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)
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.
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.
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.
> 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# has had the reputation of not being viable for Linux for a long time.
Therefore, the people already on Linux didn't have a reason to use it or even try it.
If you're already doing stuff in other languages it's hardly worth it to switch to C#.
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.
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 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.
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.
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.
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.
Every web developer I've met has specialised in one area or another, even if they claim the title of "Full Stack".
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.
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.
https://www.youtube.com/watch?v=_t6xVfrmEWU
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.
Yes, "dot operator can throw a NRE" is of course a big mistake. A billion-dollar mistake, you can even say.
[0]: https://github.com/Cysharp/ZLinq
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.
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 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.