4 ms·

Also why the games industry remains stuck on a lot of bad practices. The experienced people keep getting driven out.

bluefirebrand 6y ago
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.
- slowmovintarget 6y ago
  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.
  - smrq 6y ago
    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.
    - slifin 6y ago
      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?
    - deleted 6y ago
      [deleted]
    - gameman144 6y ago
      But he made a boatload off of Braid after he coded it. Not sure I understand this point.
    - sjtindell 6y ago
      To me Braid was literally the first example of him doing what he does.
  - kayamon 6y ago
    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?
- Jasper_ 6y ago
  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.
  - bluefirebrand 6y ago
    Thank you for the advice. :)
  - katbyte 6y ago
    over DRY code is the bane of my existence
  - munificent 6y ago
    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.
    - 6y ago
the_duke 6y ago
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.
- xsmasher 6y ago
  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.
- Jasper_ 6y ago
  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.

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.

slowmovintarget 6y ago
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.
- smrq 6y ago
  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.
  - slifin 6y ago
    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?
  - deleted 6y ago
    [deleted]
  - gameman144 6y ago
    But he made a boatload off of Braid after he coded it. Not sure I understand this point.
  - sjtindell 6y ago
    To me Braid was literally the first example of him doing what he does.
- kayamon 6y ago
  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?
Jasper_ 6y ago
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.
- bluefirebrand 6y ago
  Thank you for the advice. :)
- katbyte 6y ago
  over DRY code is the bane of my existence
- munificent 6y ago
  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.
  - 6y ago

the_duke 6y ago

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.

xsmasher 6y ago
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.
Jasper_ 6y ago
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.