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.

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.

Something I've noticed about software dev vs game design: software is better (easier to read, understand, maintain, etc) when you have clean, separated modules. Game design is better (more fun) when everything is connected (eg in an fps, everything relates to gunplay, damage systems, environmental destruction, in a building game, everything relates to building, the building ui, inventory, resources etc). I think this mismatch shows up in game code.

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/...).

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.

This goes for devs in all industries, it's not a problem unique to games.

If anything, the most competent developers in terms of getting the most performance out of hardware are game developers.

The other day a professional gamedev was arguing with me that's Transform.GetChild to get a reference to a component was not a bad practice. His argument is that it's what every other firms in his area is also doing. I do hope that was not the truth and he was just trying to win the argument.

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,...

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.

I don’t see the issue. Real software problems are when the logical model is insufficient for the given problem.

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".

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.

I’ve met plenty of these types in enterprise jobs too.

It's an indication that programming languages are the wrong abstraction for creative work