4 ms·
> This is not really out of the ordinary for successful, released, real games Well said. A lot of people will nitpick and talk big about how they would use pro
by ehsankia 7y ago
> This is not really out of the ordinary for successful, released, real games
Well said. A lot of people will nitpick and talk big about how they would use proper abstraction and write very clean code, but probably none of those people have ever had a successful indie game out.
- klodolph 7y agoTo 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.
- gcpwnd 7y agoYeah 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.
- klodolph 7y agoI 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.
- GordonS 7y agoI fully agree with this. Guiding principles are a good thing, but the one principle that should top them all is "no dogma".
- mstade 7y agoRight, 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.
- chrisseaton 7y ago> To be fair, one of the most vocal advocates of higher code quality is Carmack His code is full of these antipatterns! One concrete example - magic numbers in Quake. https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/QW/client/view.c#L135 https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac... Doesn't seem to cause him any problems in achieving success.
- klyrs 7y agoThat'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?
- chrisseaton 7y ago> How would you produce this effect without numbers? That's not what 'magic numbers' means. The idea is that you factor out the number into named variables so they don't appear unnamed in the body of expressions.
- klyrs 7y agoOk, 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.
- fiblye 7y agoCarmack 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.
- audunw 7y ago> 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.
- to11mtm 7y agoI 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)
- lojack 7y agoFrom a pragmatic point of view I would actually expect it to be pretty common for games to sacrifice code quality. You build a game with a set end date, and do a small amount of maintenance on it moving forward. As opposed to an engine where it's a product you're building on and you want to grow over a much larger timeframe, and those unfamiliar with a piece of code are likely to maintain it down the road.
- koonsolo 7y agoExactly this! I was a mobile game developer for several years. The technical dept at the end never needs to get paid .