3 ms·
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
by 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 agoEx-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.