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’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.
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.
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.
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.
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.
If you’re a solo developer, if it works.
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.
I’ve met plenty of these types in enterprise jobs too.
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.
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.
[0]: https://github.com/Cysharp/ZLinq
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.