To get to what I mean with that enigmatic title, I should start with an example. A few days ago, with a fellow designer, we started working on the level design of a puzzle game. Because the project is in early development, we try and playtest different approaches. One of them is a large level with a lot of open space. Near the end, there is an empty corridor longer than the screen’s width.
Two out of five playtesters, while crossing that corridor, immediately asked for a sprint feature. Of course we expected that reaction: it takes just too much time to simply cross that level. But that’s why it’s a great example of the phenomenon I want to talk about. Is the scale of the level too big? Or the character too small? Maybe, but what players wanted, running through that corridor, was to press a button and sprint.
* * *
While playtesting a game, players notice problems but often tell you the solution they would apply instead of explaining the problem first. A designer knows to analyse a problem deeper before designing a solution. As much as possible, we want to avoid quick patches that are inconsistent with the game direction. A player may not know that, but that’s not a reason to forget to talk about the problem at all. So, why do they do that?
Probably because when you are playing a game with the developers right next to you, it’s easier to talk about a proposition than a problem. It’s an implicit social rule to try not to hurt other people’s feelings. You want to help, be constructive, not just point out mistakes. If you don’t have a solution, you think it’s not helpful to speak up. In other words, if there is no solution, there might be no problem at all.
That being said, I think it also depends on the way we experience the game (and its flaws). Most of the time, players (and designers) can feel that something is wrong but cannot clearly identify the problem. That feeling of wrongness develops while playing, and only makes sense to you when you picture a way to solve the problem. Then the difference between the “bad” and the “good” experiences appears to you and you can say with confidence “you should add this feature”. It seems that some problems can only express themselves through their solutions.
* * *
Here is another example for you. During the development of Epistory, I received indirect feedback from someone who played an underground area of the game that has lava ponds as blockers. After playing, he proposed that lava should kill you. Or, because a game over was too much for a misstep, at least remove some life points. But the game doesn’t have life points, so, why not add a life gauge?
For reasons that I don’t have time to develop here, we didn’t want a life point system in Epistory. But, more importantly, we did not want to ask the player to move precisely to avoid stepping on the lava. Being a typing game, we recommended an unusual key binding that kept all fingers on the middle row of the keyboard. Putting challenge on movement would have been really frustrating for players trying to use that finger placement. That player was trying that key binding for the first time, so I’m sure he figured how frustrating avoiding lava would be. Then why did he proposed such a thing? To what problem was it a solution?
The reason appeared clearly when I watched someone playing at a game convention. I often say that worse than a player not understanding a game rule, is a player understanding a rule that does not exist. That player tried to avoid lava because he initially thought it was dangerous. This is easy at first, but gets really complicated when you have to follow a narrow path enclosed by lava (It was obvious watching him play that he carefully avoided the lava). At that point, he inevitably missed and understood that lava had never been a threat. After the frustrating realization that he had put much efforts into nothing, he exclaimed “lava does not kill me?!”
I know lava naturally conveys that meaning (and it’s used regularly in video games for that reason). It was not the smartest idea to use that as a simple obstacle in the first place, like a red barrel that doesn’t explode. But keep in mind that only a few players got the wrong idea. Knowing what really caused the problem, we reduced the risk of it occurring by placing small lava ponds early in the level so that players get used to it as scenery or bump into it and understand that it’s not dangerous.
* * *
What can we remember from all of this? I’ve heard managers say “don’t come to me with problems, bring solutions” (because they want their team to be involved instead of relying on them for anything). As a designer, I would rather say “come to me with problems, not solutions”. Not because I think I’m the only one who has the right to have ideas, but because you have to clearly defining your problem before evaluating solutions. Focusing on a first impression will narrow your thinking. You have to trace back the players’ feedback to the core of the problem, and then solve it the best way possible.