Anyone who has ever worked in Software development knows the unique pain and torment that is bug testing. After months of making a program a group of people are hired, given basic instructions, and then tasked with BREAKING the software. Not checking to see if it works, but rather checking to see if they can break it.
There are a million reasons to hate bug reports. Badly written, found using cheats, mis-labeled, and mis-attributed to the wrong thing. I could write dozens of posts on the worst practices of QA testers, but really, the one that gets me annoyed most often is that bug that is repeatedly entered and finds it’s way to me, despite having been closed several times. Occasionally they re-open the original bug, but more often it is a duplicate, showing that they do not search the database for the bug before creating a duplicate. The most common cause of this is bugs that are closed “As Designed.” Meaning that what the tester marked as a bug, really isn’t. It was intentionally created that way. An active choice was made and scripted to do exactly that.
Best case scenario this is something like “Player 1 gets a bit more gold than Player 2.” Respond with “As Designed, we needed a solution for rounding odd numbers and Player 1 just gets the lions share rather than deleting the extra coin.” Relatively simple. And usually, the bug is closed, no one ever notices it again, and the matter fades into obscurity.
But what happens when it isn’t that easy? I recently designed a timing puzzle. I intended for it to be a simple move – wait – move puzzle. A senior designer saw it, loved it, and worked with me to make it more complex and puzzling. Now, fast forward 3 months and I have received no less than 5 bugs on the puzzle. After having marked 4 of the bugs “As Designed” with increasing annoyance, I got the last one and began drafting a rather annoyed email to QA to tell them to 1. quit bugging this issue and 2. do a search of closed bugs to make sure it hadn’t already been bugged in the past and closed “As Designed.” I was halfway through the email when suddenly I had the thought – well, clearly as designed in this case is wrong, or else I wouldn’t keep getting the bug. Five people saw this and immediately thought, this is not what is supposed to happen.
One of the hardest things to get used to as a Game Designer is the universal truth that while you know something is a good idea, it may not be a good thing for your game.
To build on the earlier example: Two players split any money earned in the level. There is a drop of 11 coins. What do you do with the extra coin? My immediate response was, Round it up to 12, and both players get 6. Stick a fork in it. (It’s done.) Another designer replied with “Lose the extra, no one will know you were supposed to get 11, so they will just think they were supposed to get 10.” It is a common saying among developers that players never miss something that is cut, but they will complain about the things that they see that are broken. The thing is, each of the money amounts are tied to art. The art always gives the same amount, thus quick counting players will be able to see that there were 2 4 coins and 1 3 coin. So either solution could lead to a “bug” in the player’s view. My idea, to err on the side of plenty meant that at least if they saw it, then they wouldn’t care. They got more than they thought they would so that’s just gravy.
In the end the decision was made to just give the excess to the first player. The players have the ability to trade coins, so it isn’t a huge issue. But what about when it is? The puzzle example – it is very confusing. As soon as it is explained to the player they say “Oh.” And complete it in one try. But the solution isn’t obvious. This lead to the complex design discussion of how do we fix this?
Solutions included everything from highlighting the correct path with coins to cutting the puzzle all together. I suggested that we simply return the puzzle to it’s earlier, simplistic, state. It was clear what you needed to do and honestly, it would be a much cheaper solution than adding a ghost to lead you through the puzzle or coins appearing along the path. One designer immediately argued, but that puzzle is so fun and it really is one of the better puzzles. We shouldn’t cut it or dumb it down. I understand what he is saying, but at this point in the project, it isn’t logical to ask people to work on adding something new when we can just as easily simplify it and polish something else. The player will see a broken addition to help them through the puzzle. They won’t see the puzzle that was overly complex if we replace it with the simpler version.
This lead to the standard Holy War of “Smart Player vs. Stupid Player” and how we shouldn’t punish our good players by dumbing everything down for the stupid player. I won’t recount the tale here, but eventually I won, not because the decision was good, or logical, or whatever, but because there was simply not enough time to do otherwise. Do I think it was the best solution? No. The best solution would have been to go in, rework the puzzle and art to make it very clear what was supposed to be done and set the complex puzzle up better with a series of smaller puzzles leading up to it. Was it the right decision? I think so. It solved the problem in an elegant way, without introducing new bugs, content, or functionality.
This experience has made me realize that “As Designed” is a terrible thing. Too often we just say, that’s the way it should be, and don’t stop to consider that maybe it isn’t. We control the worlds we create when perhaps we should sometimes realize that the correct solution is the one that allows the world control.