This post is going to address how seemingly good UX design generates a ton of bad UX when some things are not taken into consideration. I will mostly focus on the use of “Revive” tools in multiplayer games, because they are a topic of great controversy among game developers and gamers alike.
Technically speaking, a concept that is meant to help others and give them a second chance can really quickly ruin the game for them. In theory, you give someone a tool to help their comrade. It can only be a good thing, right? As long as you ensure that the UX of using the tool is fun for the Medic, you’re settled. Unfortunately, the playtesting feedback one gets is limited and one can easily get complacent with players saying they are happy with the way their defibrillator works, how many points they get per revival, the range of their healing tool, etc. More often than not, the experience of the receiving end, the player being healed/revived/affected, is completely ignored. And that can have fatal (in-game) consequences. In simpler words, testing whether a Medic thinks their Revive tool is fun to use is not enough. You must get an opinion on whether other players think the same.
Taking an example from World of Warcraft, by Blizzard Entertainment, there is a spell that I used constantly on my friends when we played: the Priest spell Leap of Faith. It would pull an ally to my character’s position. The theory behind it: you help an ally to move out of danger by instantly moving them to your location. The truth of it: I could randomly relocate and annoy any ally in a group by pulling them to me. Their experience was an unexpected loss of character control over which they had no say. The point being: when there is another player on the receiving end of things, you must ensure their experience is not disrupted by the first player. MMORGPs often implement “Accept/Reject” messages when another player wants to trade with you, so that they cannot spam you with trade requests and open up windows you don’t want. It is surprising to see how this trend has not been adopted in more online interactions across various genres.
I will present a few examples of games that have a Revive mechanic and that got it wrong, making their feature from annoying all the way to catastrophic: not for the players using the Revive, but for the ones receiving it.
Warframe, by Digital Extremes, has self-revivals. While on the ground, you can see your character’s surroundings where they died. This means that you know what dangers lie around you, and you can choose for yourself when to get back up. The obvious move here is that player-to-player interaction was gotten rid off, which avoids any kind of frustration over loss of character control.
In Battlefield 4, by DICE, a soldier equipped with a defibrillator can automatically revive someone, that person is then revived with 50% health, but they get a few seconds to decide in-action whether they want to get up and keep going or respawn at a base. This means that if the player decides that the zone where they were revived is too dangerous, they can opt to respawn safely at their base. This way, the first player gets their points for reviving a fallen ally, and the ally has control over what their character can do.
Brink, by Splash Damage, allows Medics to give a Revival syringe to fallen allies, so that they have full control over whether they want to get back up or not. However, the fallen player has only limited vision as they are stuck looking in the direction they were looking at the moment of their death. Still, the decision to take the risk is in their hands.
Planetside 2, by Sony Online Entertainment, has an “Accept/Reject” alert show up when a Medic is reviving the player, but the revived player has no visibility of their body’s surroundings where they died. This means that there is a chance that the zone where they died is still dangerous, yet they have to take a quite random risk on whether to accept or not because they might instantly die again.
The above games shows various way developers have tried to tackle the dilemma of someone’s fun (the Reviver’s) not ruining the fun of someone else’s (the Revivee’s). The following two examples illustrate what happens if you don’t think about the global experience of everyone involved: players will find a way to enjoy themselves and ruin the game for others.
In Battlefield Bad Company 2, by DICE, this would sum up the average experience of having a medic reviving a player in a dangerous zone: A player dies, gets revived, gets shot again, gets revived, etc. During all of this, the Medic gets experience points, while the player that is stuck in an endless loop of death has his time wasted in a horrendous way, with no control over the situation whatsoever. This clip illustrates what I describe really well (starting from approximately 0:35):
Finally, the worst offender of all: Dust514, by CCP Games. In the game, friendly fire is enabled. Killing an ally subtracts 50 points from a player’s experience points. Reviving an ally, however, rewards 60 points. The math is not complicated: by repeatedly shooting their own teammates and reviving them, a Medic could have the time of their life racking up points while their ally is experiencing the worst possible type of in-game behaviour: betrayal.
As a closing word, I would like to sum things up: A cool idea can be turned into a nice feature that then provides players with a fantastic and rewarding UX. When player interaction is involved, every player’s UX needs to be considered. I am sure that the medics in Battlefield Bad Company 2 just want to do their job when they spam-revive a fallen comrade. It is not the player’s fault for playing their role. It is the developer’s fault for allowing one player’s UX to ruin another’s. That is why it is so important to examine the UX of all parties involved when designing any feature that involves player interactions in online games. Because when given the wrong tools, players will take advantage of all the wrong developer decisions.
Images are in-game screenshots
Cover image from dark.pozadia.org