As a counterpoint for example, code running on servers should totally be built for the long haul: it's gotta evolve continuously with requirements, it has to cope with edge conditions and especially it has to be secure. You can't get away with the same type of spaghetti in your ACL checking that you can in the code that handles player physics in a platformer.
That does not mean video game devs are bad coders. They are just optimizing for different scenarios.
When someone is trained in OOP, the requirement "flexible behavior" triggers a search for answers through polymorphism, but polymorphism is much more structured than a copy-paste-modify code path. It creates limits to scope and requires more explicit names for things. That is the point, of course. You have write more code and do more complex things to get the same level of flexibility, and it'll be harder to debug since the call stack will have to jump around throughout the layers of abstraction. In a "time from idea to production code" latency analysis, OOP structures lose to copy-paste.
And that's why, across the bulk of game codebases I've seen, there tends to be a big jump from hardcoded assets straight into data-driven ECS-style approaches. Small games start with the former, and if they get big enough switch to the latter. The ECS approach still exacts a debugging penalty because more bugs will exist in data, where they're harder to analyze with IDE tooling, but more behaviors are encoded as explicit patterns with limited scope, which is good in a team environment, and it's possible to go data-driven in an incremental rewrite: simply find all the truly redundant stuff, replace it with a parameterized pattern, expose the pattern as data. For the stuff that isn't easily parameterized, consider encoding a small state machine interpreter so that an imperative program definition may occur in data. In the entity system, add some notion of dynamic compositions of state and behavior at initialization. Between those three you can cover just about everything, and you never have to do it 100% to ship: it's there to assist the things that benefit from additional structure, which probably isn't all of the game. (rather, in the AAA environment the data-driven approach can tend to get out of hand - it's a move that allows the designers to avoid needing explicit code support for longer and longer periods of time, with the predictable result of enterprise anti-patterns that abuse scripting in a fashion that is much harder to debug than the hardcoded equivalent.)
This distinction is also basically why you don't see Jon Blow, for example, really get excited about discussing the runtime architecture of his game projects: If the bulk of the game is assets all the way down, there's nothing to talk about, and the only part that concievably could be exciting is some of the core algorithms that drive the interactivity.
It's also why so many gamedevs are apologetic about their code: half of them try to escape this reality by finding a magic mix of abstractions(which eventually blows up and causes rewrites once sufficient complex behavior hits the codebase), the other half run with it and stay in the local optimum of inlined, hardcoded, primitive-heavy functions.
And Minecraft is one of the best examples for a game that is still paying for such a development style.
At the end of the day no one really knows what fun is so the more chances you have the better the opportunity to strike on something "fun".
But most games aren't in continuous development to the extent Minecraft is
A game like VVVVVV is, once a class is created, unlikely to be changed a thousand times. It wouldn't scale if you had 200 people working on it with new people coming in and leaving all the time. But at the end it doesn't really matter much in this case, and isn't the right thing to focus on while coding up a game.
> Maybe these supposed anti-patterns don't really matter as much as we think they do for successful software
They matter a lot for some software more than others. All software is a set of tradeoffs in some ways or another - in this case its attention to things like perfect class naming.
Right now, I'm working on a piece of personal productivity software and trying ideas and patterns that I couldn't get away with in building software with others and to the requirements of other people. I can get away with things that are traditionally anti-patterns because I'm the only one it has to pattern to.
I have to imagine indie game dev is a similar sort of getaway.
Edit, I've been informed that the direct link has a NSFW redirect, so using archive.org instead
"It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing."
This is like Facebook.
What did showed for you?
There's more than one variable involved. You can write successful software full of anti-patterns, but you'll probably pay for it in some other way (like increased QA effort or a low bus-factor [1]).
e.g., bus factor has to be weighted a lot more highly on software that needs to be maintained indefinitely than it does on software that is going to be shipped on a fast-approaching deadline and then (probably) never touched again.
Also, bus factor's importance depends on the size of the team. In the limit case - a 1-developer project like VVVVVV - it's meaningless.
Doesn't 'success' encompass all these variables at the same time?
If you can be successful with a very high QA effort then fine. If QA costs were too high then you wouldn't be making money and you wouldn't be successful.
If you can stay successful with a very low bus-factor then good for you.
And so on with other variables.
But trying to figure out what a successful game is by its source code is like trying to find what makes a painting good analyzing the chemicals used to make the pigments.
> This is not really out of the ordinary for successful, released, real games.
Maybe these supposed anti-patterns don't really matter as much as we think they do for successful software? Given that plenty of successful software has them.