Achievements do a lot of things, but one of them is to direct player attention. This can be a safety net - say you’re making a game that includes fishing as an important source of food and materials and you’re worried the player might not realize it’s an option and thus have a harder time than intended. In addition to putting in signposts pointing to the fishing hole and having friendly NPCs talk about how great fishing is and such, you could add in an achievement for catching a fish. Like with the signs and NPCs, it won’t solve the issue for every possible player, but it will for some and won’t really affect anyone else. It’s basically just an additional guard rail.

Suppose you instead set the achievement to require catching ten fish. There are a lot of reasons you might do this - maybe catching one fish feels insultingly trivial to reward. But once the player has caught a fish, they definitely know that fishing is an option. They should be able to decide whether it’s something they want to invest time in - maybe they enjoy the minigame enough that they’d fish for fun, or maybe they dislike it enough that they’d rather avoid it in favor of other sources of food and materials, or maybe they’re somewhere in between and will do it when it’s an efficient way to meet a particular goal.

For players who care about achievements, some of them would have gotten ten fish anyway and the ones who wouldn’t now have to either forgo an achievement or spend time on an activity they dislike, making the game worse for them. All because the game wasn’t content to let the player try it once and then decide for themselves.

I’m sure there’s a better name for this, but I call it “insecure design” - game mechanics that use extrinsic rewards to encourage the player to spend a lot of time with certain game modes or content as though the designer is worried that content isn’t enjoyable enough on its own for players to want to bother with it. And much like using engagement rewards, I think it almost always backfires.

Read more...