To be fair, one of the most vocal advocates of higher code quality is Carmack, who has put out a few games.
What I’ve seen is that it’s hard for someone who’s not released a game before and supported it post-release to know where and how you can sacrifice code quality for a faster development time.
Right, but at the same time what Carmack considers quality code may well be considered low quality by non-game devs because it's too complex, too magical, not documented enough or whatever. Context matters; some code is one game developers beauty; while it's some other developers nightmare.
I'm not a game developer, but I've worked with enough game developers to realize they have a completely different mindset and point of view from mine. It doesn't make them wrong, and it doesn't make me wrong either, it's just that – different points of view, different contexts, different constraints. I have immense respect for game developers.
I'll play Battlefield 1 or Horizon Zero Dawn and marvel that they can get a stable 60 or 30 FPS despite seemingly infinite complexity, all the while I'm struggling to filter a grid with 250 rows in a web browser...
You're absolutely right – no one knows better where to sacrifice quality (whatever that means) for dev time or performance, than game devs.
Carmack is also generally writing foundations and engines that are reused in multiple games. If it's not readable, it's useless.
Most indie devs are trying to crank out a game fast because they have a vision and/or they just want to sell it while the market's hot. Most have no plans on touching the game beyond maybe a couple tiny absolutely essential bugfixes shortly after release. Writing cleaner code is ideal, but that takes planning, foresight, and refactoring. That's loads of time for solo devs or tiny teams to devote which could be otherwise spent making new content entirely.
Yeah but carmack style quality isn't as SOLID as people want to. Game devs have always also factor in performance, that's what other dev communities have lost. Apart from embedded devs.
I would caution people against taking SOLID as a measure of code quality. That’s a trap. SOLID is just a set of object-oriented design principles, not laws. If you take the guidelines too seriously, you will end up with a damaged code base which is difficult to read or understand.
Having spent quite some time in id Software code bases, I will defend them as being high quality, but whether or not they are SOLID is not something I really care about. The SOLID guidelines also regularly conflict with YAGNI.
> To be fair, one of the most vocal advocates of higher code quality is Carmack, who has put out a few games.
I'm working on a port of Doom right now, and have worked with the Quake 2 source code before. I also took a quick look at the Wolfenstein source code yesterday.
It's very clear that Carmack and his colleagues have developed their craft over time. Wolfenstein doesn't seem to have much structure to it at all. Doom is still a mess of global variables and ugly code. But you're starting to see some nice abstractions, like the WAD loading (which made it modder friendly) and the sound module system.
It's been a while since I worked with the Quake 2 code, but I remember it being quite elegant. From what I've heard the Doom 3 source code is excellent.
I think the point is, for your first projects, for small indie-style games, you really shouldn't worry too much. In my experience, it's really hard to learn to use good abstractions effectively unless you've tried to do things the hacky way first, and actually have a solid feeling for what the abstractions try to solve. I still notice this, that I really have trouble getting some projects off the ground if I try to do it the elegant way from the start. Sometimes you spend too much time with an abstraction that turns out to be a bad fit. If I just hack it together, and then refactor it later, it's much easier to get things started.
It's also important to remember that the more people you're collaborating with, the more important it is to have a clean structure.
I think the code bases prove it in their own right...
When I look at how many games Raven was able to churn out with the Quake 3 engine (and most of them were pretty good! Elite Force and Soldier of Fortune are both games that I remember quite fondly).
Carmack saw the value of clean code in providing a quality experience. I'd also wager that was a big part in their ability to iterate on the engine so quickly.
> Wolfenstein doesn't seem to have much structure to it at all. Doom is still a mess of global variables and ugly code.
Part of me asks how much of that was by necessity, and by that I mean whether some of those things were intended as ways to get every last bit of performance out of the code (especially things like globals, and for something as old as wolf3d one starts to also ask about things like segments shudder)
That's a weighed average with, presumably, hand-chosen coefficients to make a nice visual effect. I fail to see how these numbers are "magic." How would you produce this effect without numbers?
Ok, sure. Even so, this is about the least compelling example of "magic number" that I've seen. They're used once, the intent is clear, and you don't have to go hunting for the definition.
What I’ve seen is that it’s hard for someone who’s not released a game before and supported it post-release to know where and how you can sacrifice code quality for a faster development time.