3 ms·

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 no

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

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.

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