The architectural decisions are at the engine level and that stuff has a massive influence on the likelihood of bugs in the code running in that engine.
For example, traditional Unity (not ECS) runs all game code (so the code provided by those coding the game) in a single thread, which avoids A TON of multi threading bugs (as that’s one of the hardest parts in programming to master) but is very bad for performance in multi-core CPUs. Game programmers can fire up separate threads using the standard libraries of the programming language itself and manage them, but everything in the development framework that’s part of the engine pushes them to use that single-threaded model, so only advanced devs bother and only for very specific things.
Also the choice of programming language forced by the engine itself has a huge impact in the likelihood of bugs, but since I don’t want to start a Holy War I’m not going to star pointing fingers at specific languages and criticizing them ;)
True, resolving bugs depends on how effective debugging tools available to the developers are.
But there is no perfect game engine. All have quirks and bugginess of a game usually just comes down to how willing the team is to find and squash them. That’s why all games need patches after launch.
Language is not really an issue here since the Creation Engine uses Papyrus for all game logic, which is good enough for what it does.
Different, high level software designs (i.e. architectural designs) which are normally imposed by the game engine, have different probabilities of the developers who are making the code for those to produce bugs, because of lots of factors including things like of how they approach error validation and handling in the engine itself and in which domains does the engine leave the most freedom to coders and which ones does it leave less - some things are pretty safe to leave in the hands of even bad developers, others are not.
The example of multi-threading in Unity should’ve been clear: put a game engine that doesn’t impose a single thread pattern in front of somebody with little or no experience in multi-threaded programming and you will have a huge rate of bugs (mainly critical race conditions) and as it so happens most developers out there have little or no experience in multi-threaded programming. Yet multi-threading can yield far more performance in modern CPU since they’re all multi-core. For that specific game engine a software architectural choice was made to go with a structure that is not as performance but significantly less likely to lead to a higher bug rate when used by the average coder, probably because Unity targets less experienced coders.
Good Senior Designers and Technical Architects don’t design the high level structure of the software for themselves as coders, they do it for the kind of coders that are likely to be coding for it.
Of course the developers themselves also have different capabilities and hence different baseline rates of creating bugs, hence why I said “both”.
Whether a game is buggy or not depends on the competency of the developers building the game, not the engine.
The engine is just a platform, like a canvas to an artist. How effectively it is used depends on the skill of the person using it.
It’s both.
The architectural decisions are at the engine level and that stuff has a massive influence on the likelihood of bugs in the code running in that engine.
For example, traditional Unity (not ECS) runs all game code (so the code provided by those coding the game) in a single thread, which avoids A TON of multi threading bugs (as that’s one of the hardest parts in programming to master) but is very bad for performance in multi-core CPUs. Game programmers can fire up separate threads using the standard libraries of the programming language itself and manage them, but everything in the development framework that’s part of the engine pushes them to use that single-threaded model, so only advanced devs bother and only for very specific things.
Also the choice of programming language forced by the engine itself has a huge impact in the likelihood of bugs, but since I don’t want to start a Holy War I’m not going to star pointing fingers at specific languages and criticizing them ;)
True, resolving bugs depends on how effective debugging tools available to the developers are.
But there is no perfect game engine. All have quirks and bugginess of a game usually just comes down to how willing the team is to find and squash them. That’s why all games need patches after launch.
Language is not really an issue here since the Creation Engine uses Papyrus for all game logic, which is good enough for what it does.
It’s not about debugging tools.
Different, high level software designs (i.e. architectural designs) which are normally imposed by the game engine, have different probabilities of the developers who are making the code for those to produce bugs, because of lots of factors including things like of how they approach error validation and handling in the engine itself and in which domains does the engine leave the most freedom to coders and which ones does it leave less - some things are pretty safe to leave in the hands of even bad developers, others are not.
The example of multi-threading in Unity should’ve been clear: put a game engine that doesn’t impose a single thread pattern in front of somebody with little or no experience in multi-threaded programming and you will have a huge rate of bugs (mainly critical race conditions) and as it so happens most developers out there have little or no experience in multi-threaded programming. Yet multi-threading can yield far more performance in modern CPU since they’re all multi-core. For that specific game engine a software architectural choice was made to go with a structure that is not as performance but significantly less likely to lead to a higher bug rate when used by the average coder, probably because Unity targets less experienced coders.
Good Senior Designers and Technical Architects don’t design the high level structure of the software for themselves as coders, they do it for the kind of coders that are likely to be coding for it.
Of course the developers themselves also have different capabilities and hence different baseline rates of creating bugs, hence why I said “both”.