[weli]

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.

[Latty]

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.

[skeeter2020]

IME you have so little reuse, and ship on a fixed schedule regardless of code quality & bugs this really isn't as critical as software built with the intent of lasting a long time & evolving. The games I've worked on (in hindsight) feel a lot like "vibe-coded without AI".

[captainbland]

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.

[grebc]

This is pretty anti-thetical to most good practices but the older and more experienced I get the more(13 years as a C# dev) I think copy & pasting sections of code is wayyyyyy more appropriate than extracting into a method/class/library or other forms of abstraction.

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.

[tranceylc]

I agree with everything except for it being anti-thetical to good practice. I have noticed a lot of experienced devs agree with that sentiment.

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

[MattRix]

100% this. All the abstractions and OOP stuff make you end up with a codebase where half the code doesn’t actually DO anything in the product itself, it just connects to other code! It also becomes impossible to follow the flow of execution because it passes through dozens of files and layers of abstraction.

[jayd16]

KISS is also good practice.

[jrecursive]

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.

[rcxdude]

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.

[vhab]

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.

[999900000999]

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.

[orthoxerox]

I would say that C# is "less colored" than Rust. Handling a moved argument, a borrowed argument, a copied argument is different in Rust, you have to think upfront about memory lifetimes. If you are wrong the first time, changing the ownership is not a simple localized refactoring.

[999900000999]

To be 100% fair, it’s much easier for llms to start new projects and Rust is simply a more difficult language.

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.

[wheybags]

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

[chrysoprace]

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

[Sharlin]

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.

[chrysoprace]

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?

[ablob]

A game is finished at some point. You might not need to evolve the code any further. Why optimize for a use-case that rarely applies to indie-games?

[badsectoracula]

FWIW sometimes when making games it helps to have everything in one place, even though later you may want to split things up for later projects :-P so sometimes you get big balls of mud with lots of checks everywhere for the actions you want.

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

[groundzeros2015]

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

[kdheiwns]

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.

[leloctai]

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

[PacificSpecific]

Based on your comment it sounds like you have a personal problem with that person which compromises your argument

[MattRix]

I mean it’s not that bad of a practice, it depends on the context.

[grebc]

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

[jayd16]

Solo dev also just doesn't need a lot of abstraction. You're adding a lot of noise for what sounds like zero benefit to developer and especially not the player.

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.

[slopinthebag]

It's also because gamedev is very highly iterative, so if you're abstracting stuff you end up throwing away your abstractions when things inevitably change. And that costs more than just changing some if statements.

[WhereIsTheTruth]

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

[PacificSpecific]

You think that's bad. Wait until you see some non game developer coders (I'm being sarcastic of course. The comment I'm replying to is incredibly naive).