Rock, Paper, Scissors

To start things off, I thought I'd write about one of the oldest traditions in game design: Rock, Paper, Scissors (I'll be referring to it as "RPS" for the rest of the post). RPS is, in many cases, the underlining philosophy behind the entirety of game balance for many games. The most general description of the RPS design is that an individual game move has one or more game moves that that game move defeats and one or more game moves in turn defeats that game move. In the case of RTS and MMO games, a game move may also be an individual game unit or player.

Before we get too far into discussing RPS, let me iterate a few examples of its application. The original game, of course, features two players who simultaneously chooses either rock, paper, or scissors as his or her move. Rock beats scissors, scissors beats paper, and paper beats rock. In RTS games, the RPS paradigm takes the form of unit types. One such example being ground units, air units, and anti-air units. In fighting games, the RPS paradigm is employed in different classes of attacks. For example, a low hit may be beaten by a jumping attack, which in turn is defeated by a standing attack or specific anti-jumping attack, which would then be defeated by the low hit.

The benefits of using a RPS design when designing a game are fairly obvious. The paradigm in its most basic form is both easy to implement and easy to balance. All that's necessary is three types of moves or units that each counter a different type to a roughly equivalent degree. It's simple and intuitive to the end user, so there's no problem in strategies being too abstract for new players to figure out and understand. When playing games, the player often constructs strategies of the form: "If the other player does that, then I can counter it by doing this." The RPS paradigm naturally fits this kind of construct, as game balance is derived by straight counters.

The downsides of employing a RPS design tend to revolve around the desire to create a more varied game-play. To illustrate this, consider this fact: RPS is simple to implement provided there are three types of units or moves. But what if you, as the designer, want more than three types of moves? In a purely theoretical sense, implementing a fair system derived from the RPS paradigm with more than three types of moves/units is demonstrably possible. Unfortunately, in any system with an even number of moves, there must be pairs of moves that, when pitted against each other, produce no winner. Conversely, in a system with an odd number of moves, it is possible to create a perfectly fair system where each move has the same number of winning and losing pairings without any tie moves aside from pairing moves with the same move.

This is not only provable mathematically, its possible to derive an equation that tells us, given a number of moves, the number of winning and losing pairings for any given move (since the system is perfectly fair, the number of winning and losing pairings are necessarily equal). Let's assume that we have a RPS system with n-number of moves. Then we can picture our RPS system as an n-sided regular polygon, where each vertex represents a single move. If we draw this picture, then every possible edge connecting any two points is representative of every possible move pairing. The equation n(n-1)/2 tells us how many edges, and therefor pairings, our system has.

Now that we have all of our pairings, we need to decide which move wins for every possible pairing. The simplest way to represent this in our picture is to give each edge a direction. That is, given the edge AB, declare that the edge goes from A to B, and therefor move/unit A defeats move/unit B. Therefor, we can say each move has some number of winning pairings (or losing). In a fair system, this number is the same for every move. Thus, to find how many winning/losing pairings every move has, we divide the number of pairings our system has by the number of moves:

(n * (n-1) / 2) / n
(n-1) / 2

At this point, it should become clear why only odd values of n can create a fair system without ties that aren't mirror-matches (pairing a move with itself).

Now, another problem with RPS systems that I've conveniently ignored up until now is the question of how ties are resolved. Even using the above information to create a system where it's impossible to have two different moves result in a tie when paired, there's still the possibility of mirror-matches. In the actual RPS game, ties are simply replayed until one of the players wins. This is fine for a game like RPS or a turn-based game, but a real-time game can't allow replaying ties for practicality reasons. There needs to be a definitive resolution.

A solution to this problem is to simply make the outcome random in case of a tie. Through whatever game-play mechanics the developer chooses to implement, he or she could simply design the game in such a way where, in the case of a tie, either player will win about half the time. The problem here is when your system has multiple moves or units that fit into a given vertex, or role, in the RPS system. What happens when two different units fulfilling the same role are paired and for whatever reason one unit has an advantage over the other? The more moves of the same class of moves the developer adds, the greater the complexity in balancing those units. The more classes of moves the developer adds, the greater the complexity in balancing those units, but to a much greater degree.

As a final point of discussion, I'd like to talk about the RPS paradigm in MMO games. In these games, players can be thought of as individual units in an RTS game. Each player has his or her avatar, which generally is of a certain class and fills a certain role in a group of players. Looking at the game design in this way, an RPS system seems like a fair and easy-to-implement way to achieve game balance.

Unfortunately, this ignores a very important fact about RPS-based games: the player, at any time, should be able to choose any move (or at least attempt to choose a move). In most MMO games that take the view that each class fills a role that defeats a certain role and is likewise defeated by a different role, the player is stuck with the role he or she chose on the onset of a conflict. Basically, if your class is paper, you cannot change to rock because you think your opposition is scissors. Likewise, you cannot change to rock because your team doesn't have anyone playing the rock class.

Interesting, fulfilling game-play comes from giving the players options to vary their strategy. If a player playing the paper class can only improve his ability to defeat the rock class or lessen (but never remove) the ability of the scissors class to defeat him, the player isn't going to find the game-play fulfilling.