That's actually something kind of funny to me. I've never worked in the game industry but I have done game jams in the past and I am very interested in making games as a hobby.

One of the biggest barriers to me is getting over my need to make code that I think is clean. And every time I try to read about best practices in game code I come across the same mentality: Who cares, write code quick and dirty, as long as it works it's fine.

And that's fine, it's just intimidating for me to write code like that. Too much perfectionism or something. Maybe too much "What if I do it wrong and introduce a bug so entangled in everything that I can't unravel it".

I wish there were even some bare minimum best practices suggestions for game code.

Let me offer you some advice, based on a few years in the games industry: I think every other industry's approach to code cleanliness breaks down for complex, intertwined simulations with strict performance requirements.

If Google cared at all about the targets that game developers cared about, my Gmail wouldn't take 10 seconds to load and run at 2FPS once the page is there.

I've read some of the best code I've ever seen, written by programmers in the games space. Code with very few tests, heavy intertwined behavior, wide-reaching global effects, and lots and lots of state.

Ultimately, treat the code as an artifact of the project: make it as clean as you need to get the game done, but any extra scaffolding you add will only come back to bite you later once you want to change how something is wired. From that end, all the usual suspects apply: make code easy to delete, make it have clearly-defined boundaries, and depend on other code as little as possible. Push yourself to use copy/paste more than you think you should, you'll be surprised how easy it is to delete wild experiments if you don't have to untangle the web of dependencies.

I worked at EA for eight years and have worked at Google for the past ten. Google and the GMail team most certainly understand how to write performance critical code. Your favorite game would take 10 seconds to load and run at 2FPS too if it had to be pushed over the Internet every time it started up and run inside any of a few only mostly-compatible VMs for a dynamically-typed scripting language never designed for anything more important than making buttons light up when you hover over them.

You're correct that optimized code is generally harder to maintain. Optimization often requires punching through abstraction layers or calcifying certain constraints or assumptions in the code.

If the GMail team understands how to write performance critical code, then there must be something else to explain why they no longer do. Hmmm... by making old hardware unusable, they cause hardware upgrades, and somehow that drives licensing? The simpler explanation, fitting Occam's razor, is that the GMail team does not understand how to write performance critical code.

FYI, about a dozen years ago I comfortably used GMail on a 450 MHz PowerPC with 512 MiB of RAM. The javascript ran without a JIT, completely interpreted. It all ran just fine. Now here I am, on a multi-GHz multi-core box with gigabytes of RAM and a JIT, and I have to keep GMail in HTML-only mode. I simply can't run the javascript and still operate my computer. Mail is piling up because I can no longer select lots of email for deletion; it isn't practical to click every single item.

I'm a game dev, and I work on high-performance websites in my spare time (e.g. https://noclip.website/#mkwii/beginner_course ). It's actually possible to make stuff that runs fast in "mostly-compatible VMs for a dynamically-typed scripting language never designed for anything more important than making buttons light up when you hover over them" if you actually try. But Google does not, so we end up with gmail.

Thank you for the advice. :)

over DRY code is the bane of my existence

Look into Jonathan Blow's work. He doesn't churn out garbage code. He cares about his craft and that includes artisanship in the games he builds.

With all due respect to Jon Blow (and I respect him a whole lot!)-- I don't think he'd be able to do what he does if he didn't make a boatload of money off of Braid.

Braid itself was novel because it took game state and made it immutable, immutability often needs a lot of consideration

This is definitely speculation on my part but maybe he didn't become a coder focused on his craft because of the finances afforded to him from Braid, maybe he created Braid a quality game because he was a coder focused on his craft?

But he made a boatload off of Braid after he coded it. Not sure I understand this point.

To me Braid was literally the first example of him doing what he does.

You say he doesn't write garbage code, yet none of his source code has been released so you've never seen it. How do you know if it's good code or not?

Do you have some examples?

I've never been in the gaming industry, but what I've heard from some developers is that writing very dirty throwaway code is the norm, since most of it is thrown away anyway when the game is done. Which leads to the buggy mess we get even from many triple A games, and a never ending cycle of re-writing the same things for each game, even within the same studio.

Engine code is very often a small, small part of what makes games "buggy". Bugs come in all sorts of shapes and sizes, but a majority of the bugginess of games that I've seen stems not from code, but from the large matrix of combinatorics that game developers can create for themselves in their designs.

Simple, contrived example: if I create an open-world game with open-world design, I can complete quests in any order. Maybe I can start doing a quest, and then decide to stop doing it halfway through, or maybe I can switch quests halfway through.

The test case matrix for this is now: every quest x every other quest. If some quest spawns a timer that will do something in 3 minutes, and something else forgets to stop it when I switch quests, that's a bug. Maybe the timer spawns some NPC, and it should stop when I switch quests. Or maybe the timer will reset some world state, and should fire immediately once I switch quests. But maybe not always -- if I complete the quest but the game internally 'switches quests' to the next one in the cycle, I don't want to despawn the NPC.

Is this code? Not really engine code, it's more like data, or scripting? It's not really the code that's reusable between games, and between engines; it's custom-built for the game's flow itself. That's where, in my experience, a good majority of "AAA bugginess" happens.

Ex-game dev. This is really what it's about.

Every engineer knows interacting mutable state tends to make code buggier. Well, a game simulating a virtual world is essentially a huge ball of deeply interacting mutable state by design.

I work in game development; the amount of care and craft depends on whether I am working on a reusable component / shared system, or one-off code for a specific feature.

The real hell comes when you think you're working on one and it's actually the other; you either burn time on an overcomplicated solution or invent a maintenance nightmare.

Just like any other development, you need to make guesses about what will change and what will stay the same and your efficiency depends on the accuracy of those guesses.