(Original image for header found here)
I’ve always found Player vs Player (PvP) games to be fascinating, and so I’ve both played and created quite a few PvP games over my lifetime. I wanted to share some of the lessons I’ve learnt doing so. These lessons are by no means meant to be a Definitive Guide to Making PvP Games, but just a few nuggets of wisdom I’ve collected along the way. I hope you find them useful when making your own PvP games in the future.
Terms: Mastery vs Social
Before I can get into the lessons themselves, I think it’s important to define a few terms so that we are all on the same page. It’s important to clarify what kind of PvP games we are talking about.
I find it useful to think of PvP games as existing on a spectrum: at one end are games that are focused on “player mastery”, and on the other are games focused on “social connections”. If on one end of the spectrum we have Counter-Strike, at the other end would be Mario Party.
Games that are focused on mastery are about fostering competition, and encouraging players to improve themselves. The goal of the game is to give players the satisfaction of mastering a skill and proving their superiority over others. Thus, these games will want to ensure players have plenty of ways to express their skill level, ensure that players constantly have ways to improve at the game, and constantly reward players for their improvements. They want to avoid overly-relying on random chance affecting the outcome of a game, as that will cheapen the victory for victor, and lead to frustration for the loser.
Social focused PvP games, however, have very different goals. The goal of these games is to facilitate players forming social bonds with each other. Thus, these games will want to ensure that they have plenty of mechanics that encourage interacting with each other, and relying on each other. If a player wins through a stroke of extreme luck, as long as it’s memorable for everybody involved and makes the players grow closer to each other, the game designer is probably okay with that, even if the players express frustration at the game.
Most games will exist somewhere in between on the spectrum. Even in the examples above, Counter-Strike has systems for socializing and meeting people, and Mario Party has ways to get better at the game. Very few games exist at the extreme ends, and I don’t think any game you make today should be 100% one or the other, but it is important to know which you are focusing on to guide your steps.
The rest of this article will be focused on techniques for making mastery focused, competitive games.
Lesson 1: Fun > Balance
Make your game fun first, and balance it later.
Of any lesson I could impart, I think this is the most important, and the most universally relevant. Make your game fun, then balance it.
I see too many beginner game designers that try to do this the other way around, and it’s painful to watch. There’s a fallacy in many peoples’ minds that because you’re making a game, the fun is already assumed. In reality, making a game fun is no easy feat and you have to devote all your will to it. If you try to take shortcuts and treat the game being fun as a secondary objective, then you are setting yourself up for failure.
I can’t think of a game that actually failed because it was too unbalanced. Yes, there’s plenty of games that players bitch about being unbalanced, and there will always be players that leave the game over it, but I can’t think of a game where it was actually the defining reason why the game failed.
There’s literally thousands of games that failed because they weren’t fun enough.
I once met a group of designers who asked me what my guiding principle was for balancing a game, and I said this lesson. The designers suddenly looked very uncomfortable and one of them said, “Well, that’s all well and good, but you can only do that if you have a lot of resources, like Blizzard. I don’t believe in that.” I was shocked. I felt they had given up without even trying, because it was too much work. I won’t say what their game was out of courtesy, but I assure you their game was not fun.
Balance is an important aspect of making a competitive game, but it’s not the primary goal. I think that a lot of designers have misplaced priorities because we all started games as players, and when we are playing a game ourselves we care a lot about balance. What you must understand, however, is that you are only playing the game in the first place, and caring about that balance, because the game is fun.
Lesson 2: Asymmetrical Gameplay
Prefer asymmetrical gameplay if you’re looking for long-term player retention.
In the past, most games were “symmetrical”: games where both players had access to exactly the same resources. The classic example is Chess, but older video games like Warcraft 2 were also symmetrical: while the players could pick ostensibly different races, each unit had an identical counterpart on the other race. Symmetrical games are far easier to balance, they’re basically balanced right out of the gate, but also generally less fun.
These days the game industry has evolved into preferring “asymmetrical” games, where both players have access to completely different units, resources, or goals. Balancing such a game is far more difficult, but it also tends to be a lot more fun for the players, and I would recommend trying to make an asymmetrical game if you are making something that is meant to have a long-term player retention pattern.
Example of asymmetric gameplay mechanics in games:
- Hearthstone allows players to enter a match with different decks.
- Overwatch allows players to enter a match with different characters, and on some maps each team has a different objective.
- League of Legends allows players to enter a match with different characters, and different runes and masteries.
- World of Warcraft allows players to develop their character in hundreds of ways before entering the arena. (I would consider the arena in WoW to be a game-within-a-game.)
The most successful examples tend to allow players to enter a match with their own pre-game customization. Player customization is a powerful tool in its own right, it makes players personally invested in your game.
This lesson ties into the first lesson: you make the game asymmetrical in its design because that’s more fun, then pull your hair out balancing it later. If you went the other way around and valued balance first, you’d always end up making symmetrical games.
Lesson 3: Clear Points of Improvement
Include obvious skills for players to improve on, so they always have a guiding light in their quest to improve. These skills should be measurable, impactful, and obvious.
When the goal of your game is mastery, it’s important to have clear points of improvement. These are skills that players can focus on to become measurably better at your game.
Here are some of the best examples from existing games:
- Last hitting minions in MOBAs like League of Legends and Defense of the Ancients 2.
- Aiming in first person shooter games like Counterstrike and Overwatch.
- Actions per minute in real time strategy games like Starcraft.
When you don’t have an obvious improvement skill, some bad patterns start to emerge with your players. Some players will feel like they are skill-capped practically as soon as they start playing the game, due to the Dunning-Kruger effect (I feel very much this way when playing Hearthstone and Heroes of the Storm, even though I should know better). If players can’t clearly see the next skill threshold, it’s easy for them to assume it doesn’t exist. Other (more self aware) players will feel frustrated because they don’t know how to improve at the game.
Several genres struggle to include clear points of improvement, for example strategy games. In strategy games it can be very subjective if what you’re doing is correct or not, and it takes a lot of experience to correctly evaluate.
When a game doesn’t have clear points of improvement in the gameplay itself, players will often fall back on other areas you probably don’t want them to. For instance, in Hearthstone players will start believing the only reason they are losing is because they don’t spend enough money getting the best cards in the game, and their clear point of improvement becomes “get better cards”. They aren’t entirely wrong either, but a good player can climb very far even with the most basic cards. Unfortunately for these new players, it’s very hard to know what to improve on in Hearthstone when you start playing.
The core of this lesson -like so much of game design- is communication.
Lesson 4: Leaning on the Early Game vs Late Game Paradigm
The paradigm of “early game vs late game” is a strong pillar to guide design choices in an asymmetrical game.
If your game is asymmetrical, one of the most useful concepts that can serve as a cornerstone for your design is the concept of “Early Game vs Late Game”. Basically, as a designer you can lean on the idea that one side will be aiming to gain a large advantage early on in the game, and the other side will be looking to not give up too much ground early so they can come back.
This is an idea you’ll find in a lot of games: players of card games like Magic: the Gathering or Hearthstone will be familiar with the concept of “aggro vs control” decks. In MOBAs like League of Legends or DotA will have “lane bullies vs scaling” characters. Regardless of how they term it, the paradigm is the same.
An advantage of this paradigm is that it introduces a narrative to your game, something you should be looking to do whenever possible. Ideally, you’ll get narratives like, “I was so close to losing the game, I didn’t think I could win, but then I managed to make an amazing comeback!” or “I absolutely bullied him at the start of the game, but then he started to play all these super strong cards, so it was a tough win, but I made it!”
It’s not perfect, the danger is you can often get narratives you don’t want, like an early game player losing the early game and feeling like there’s no hope of comeback, or a late-game player just getting steamrolled so fast he never felt like he had a chance.
When I was making Infinity Wars, an early iteration of the game actually didn’t have a health bar, and rather the win condition was based on the players losing all their units on the board. However, I changed the game’s win condition to a more traditional health bar because I found that a player that gained an early advantage, but lost it, never had an indication of that past advantage. They would be left with no hope that they could win by managing to get through “one more attack to finish them off”, or other such similar narratives.
I think this is also one of the reasons players tend to dislike healing abilities in games so much (or rather, they dislike when their opponents have them). When they lose because the opponent healed back up, there’s no “record” that they were at least close to killing their opponent.
Of course, your entire game can’t be based on “early vs late”, your game will need to be more nuanced than that, but if you’re currently struggling to creating interesting points of difference between unit, characters, etc, it’s a helpful tool.
Lesson 5: Hiding Information and Including the Means to Deduce That Information
Hide crucial information about the enemy from each player, and then give those players the means to reasonably deduce that information.
Hiding information about the other player(s) in a game can really keep a game interesting, and add a lot of variation and tension to a game. You’ll find a lot of talks and articles out there about the value of having hidden information in your game’s design.
However, having hidden information alone is only half the story. The real key to doing it well is making sure each player has the means to reasonably deduce that information.
For example, Rock Paper Scissors is a game of hidden information: you have no idea what the other player is going to pick. It’s not a well designed game though! Unless you’re playing against Bart Simpson, who believes nothing beats rock, you have no means to deduce what the other player is planning to pick.
If you were to read the mind of a master Rock Paper Scissors player, it would look something like this: “???”.
Compare that to what a Magic: the Gathering player might be thinking: “I don’t know what cards are in the opponent’s hand. However, he has several cards in his hand, yet he hasn’t been playing any creatures to block mine. So far, he has played two islands and one plains. I can reasonably deduce that he is holding another plains and Wrath of God, and act accordingly.”
A League of Legends player might be thinking: “I don’t know where the enemy jungler is. However, I saw the enemy bot laners enter lane late, and now 3 minutes later the enemy mid laner is favouring the top left corner of the lane in his movements. I can reasonably deduce that the enemy jungler is in the top left corner of the map and act accordingly.”
In both these examples, the player doesn’t know crucial information, but due to various clues, they can try to deduce that information. Of course, they may be wrong, or their opponents might be trying to intentionally mislead them, because they know what their opponent is thinking too! Mind games like this are fascinating, and really start to separate the best players from the others. Once your game is creating this sort of thinking in your players, your game is on the path to success.
I think that several PvP games I’ve played have suffered because of a lack of hidden information. In World of Warcraft’s PvP, there’s almost no hidden information, especially when players start using cooldown tracking mods, and the game start to feel very “solved” at high levels of play: to a very good player it’s quite clear what the optimal move is at any point in time. The fighting game genre as a whole suffers from a lack of hidden information as well.
Lesson 6: Volatile Gameplay and Punishing Mistakes
Don’t be afraid to punish players for the mistakes they make. Aim for a volatile game.
Something that a lot of new designers do is that they are afraid to punish players for the mistakes they make. I’m 100% guilty of this, and when I learned to move past it, it was a huge point of improvement for me.
What usually happens when designing a game is that we want to reward the other player, the one that did something well, but we get scared because often this means doing something that will make the losing player feel bad. It feels bad to die and have to wait a full minute to respawn, or to lose so many units in one fell swoop that the chances to come back are slim, but as designers we need to do it. What you want to avoid is the “wet noodle fight”, where neither player feels satisfied when they do something well. Instead, aim for a “volatile” game, where it can swing heavily in one direction or another when major mistakes are made. If play sessions are very short, the game could very well end with the first major mistake (and the better the players, the smaller the window of what is considered a “major” mistake will be). If the game has long play sessions, then you’ll want major mistakes to swing the game heavily, but also create mechanics that ensures that it’s possible for a comeback.
Of course, you can easily go too far with punishing players too severely for mistakes and turning them off the game, but you’d be surprised how far you can actually push it, and just how masochistic players really are. It can actually be really frustrating to a player to not have mistakes punished: they come away from each game feeling like they haven’t learned anything.
This is a major issue I have with Heroes of the Storm, the game seems so afraid to punish mistakes that I never really care when I die. I don’t think to myself, “wow, I should watch my positioning and make sure that doesn’t happen again”, instead I think, “oh well, whatever”. The game is so un-volatile that I don’t really feel like my deaths influences the outcome of the game anyway. (Obviously it does, but it never really feels like it to me.) The designers of HotS have this very low level of punishment because they’re afraid of the players having a negative experience, but instead I just have a very boring experience, with no highs or lows, and I think that’s even worse.
I’ve certainly made this mistake myself. In one of my first games, a MOBA called Omni, all the players had huge health pools, and always had abilities to disengage from a fight if they felt like they were in danger. It was really easy to justify those choices at the time, but in the end I was wrong.
The purpose of this lesson isn’t to get you to make super-masochistic, super-volatile games that swing all over the place, but rather to encourage you in the direction away from new designers’ natural tendencies. When making a game, I would recommend erring on the side of being too harsh and pulling it back from there, rather than the other way around. This is particularly important when playtesters become involved, as it becomes much harder to increase the levels of punishment than to reduce it from too-high levels.
Lesson 7: Understanding Your Game
If you’ve done your job well, you will never truly understand your own game.
If you’re making an in-depth competitive game, you won’t really ever completely understand it, truly knowing all the moving parts and balancing them against each other. It’s easy to get frustrated because you always feel a bit like you’re wandering in the dark. Rather than giving into the frustration, realize instead that this is a sign that your game is on the right track.
If you do think you understand your game, then one of two possibilities is true:
- You’re wrong.
- You’re right, and your game doesn’t have nearly enough depth.
If you can truly figure out and completely understand all the dynamics of your game, it doesn’t have enough depth. If you can figure it out, I guarantee you that your players will figure it out even faster, and they’ll quickly get bored of it and leave.
I think that players understand that the designers don’t completely understand their game (although some will think they should, and then say they’re not qualified to make the game. Ignore them.) I believe this imperfection of the creators is part of the excitement about a new release in a game. Whenever a new release comes out for a game, players are eager to “break” the game and discover something the designers didn’t think of. If there was no possibility of that happening, the game would be a lot more boring for everybody. A game designed by a perfect balancing machine wouldn’t actually be that fun.
So embrace your imperfect human nature, and just do your best.
Summary
Here’s all the lessons put together. I hope you were able to take away something useful!
- Make your game fun first, and balance it later.
- Prefer asymmetrical gameplay if you’re looking for long-term player retention.
- Include obvious skills for players to improve on, so they always have a guiding light in their quest to improve. These skills should be measurable, impactful, and obvious.
- The paradigm of “early game vs late game” is a strong pillar to guide design choices in an asymmetrical game.
- Hide crucial information about the enemy from each player, and then give those players the means to reasonably deduce that information.
- Don’t be afraid to punish players for the mistakes they make. Aim for a volatile game.
- If you’ve done your job well, you will never truly understand your own game.