🚀 go-pugleaf

On Sat, 18 Mar 2017 09:34:04 -0400, Spalls Hurgenson
<spallsh...@gmail.com> wrote:

>And the poster is correct; Bethesda games /have/ always been very
>buggy. Daggerfall was the absolute worst of all their games, though;
>it was so bad they included cheat codes in the game so players could
>get past the broken parts of the game. I am not sure if this is a
>fault of the expansiveness of their worlds and complex interactions of
>its various systems that make comprehensive testing impossible,

This.

>just bad coding practices at Bethesda HQ (or possibly an intended
>feature to differentiate their games from everyone else? :-) but
>Bethesda is famous for its roster of bugs. 

Most of Bethesda's *action* games that I've played (admittedly not
all) have been better than average in QA out the door.

Because Bethesda is most known for their open-world RPGs, you're right
that they've come known for bugs.  

It's exactly your first guess.  In software development, the more
effort you put into trying to create an open game with that sense of
"anything can happen" (whether its regarding physics, or how quests
are completed, the degree of variation of interaction with NPCs or the
environment), the more permissive the game is with possible ways to
play it, the greater the exponential expansion of possible test cases.
At some point when you make the game big enough to give players what
they've been asking for, the cost of play-testing with 100% coverage
(particularly on multiple platforms) becomes outside of the realms of
human possibilities, both in terms of time and cost.

A directed or guided experience that doesn't let the player just go
anywhere and do anything is much easier to test.  Multiplayer games
are harder and costlier than a directed single player game because of
course the unexpected network conditions that can occur in an online
game, but because the playing field is usually limited to a map, it's
not as difficult to QA as a huge open world RPG, where something as
simple as the character attributes or loadout of a player can invoke
strange consequences in an actual play test session that would not be
detectable with standard unit-testing practices, or any other method
other than the remote chance that the play tester happened to build
and progress their character the exact same way, make the exact same
choices, and follow the exact same sequence of keystrokes/mouse moves
with the exact same timing.  

In reality, typical play testing can eliminate a huge number of
problems, and sometimes it's amazing it all works as well as it does.
But usually that last 5% of bugs are the ones that take up 95% of the
testing time to investigate, reproduce and fix.  Then, when less than
1% of players are ever likely to encounter that bug, some reasonable
judgement calls have to be made.