:spades: Slovenian Tarok card game environment for the OpenSpiel framework.
OpenSpiel is a collection of environments and algorithms for research in general reinforcement learning and search/planning in games. OpenSpiel supports n-player (single- and multi- agent) zero-sum, cooperative and general-sum, one-shot and sequential, strictly turn-taking and simultaneous-move, perfect and imperfect information games, as well as traditional multiagent environments such as (partially- and fully observable) grid worlds and social dilemmas. OpenSpiel also includes tools to analyze learning dynamics and other common evaluation metrics. This document serves both as an overview of the code base and an introduction to the terminology, core concepts, and algorithms across the fields of reinforcement learning, computational game theory, and search.READ FULL TEXT VIEW PDF
The combination of deep reinforcement learning and search at both traini...
Much of recent success in multiagent reinforcement learning has been in
RLCard is an open-source toolkit for reinforcement learning research in ...
In this report, we present results reproductions for several core algori...
Cooperative games are those in which both agents share the same payoff
Rogue is a famous dungeon-crawling video-game of the 80ies, the ancestor...
Many security and other real-world situations are dynamic in nature and ...
:spades: Slovenian Tarok card game environment for the OpenSpiel framework.
Best explanations of difficult concepts online
An array of algorithms and experiments on playing Goofspiel.
This is a living document. The team intends to periodically update this document to reflect the current state of the code. At any given time, this document might be (slightly) out-of-date; please refer to the OpenSpiel github page for reference. As a result, we request that authors not cite specific sections, tables, or figures of this document as they may change over time.
OpenSpiel has been possible due to a team of contributors. For a full list of all the contributors, please see the list of authors on github.
We would also like to thank the following people, who helped and supported the development of OpenSpiel:
We provide an intentionally brief overview here. For details, please see Section 3.
OpenSpiel provides a framework for writing games and algorithms and evaluating them on a variety of benchmark games. OpenSpiel contains implementations of over 20 different games of various sorts (perfect information, simultaneous move, imperfect information, gridworld games, an auction game, and several normal-form / matrix games). Game implementations are in C++ and wrapped in Python. Algorithms are implemented in C++
and/or Python. The API is almost identical in the two languages, so code can easily be translated if needed. A subset of the library has also been ported to Swift. Most of the learning algorithms written in Python use Tensorflow
, though we are actively seeking examples and other support for PyTorch and JAX111https://github.com/google/jax.
OpenSpiel has been tested on Linux. We have not tested on MacOS nor Windows, but since the code uses freely available tools, we do not anticipate any (major) problems compiling and running under other major platforms. Patches and instructions would be appreciated.
Components of OpenSpiel are listed in Tables 1 and 2. There are three levels of status: indicates a thoroughly-tested implementation, including–in many cases– verifying against known values and/or reproducing results from papers and used for papers, indicates implemented and lightly tested.
|First-price Sealed-bid Auction||Wikipedia|
|Kuhn poker||Wikipedia, |
|Markov Soccer||[37, 24]|
|Matching Pennies (three-player)|||
|Oshi-Zumo||[17, 8, 54]|
|Catch (Python-only)|| and [51, Appendix A]|
|Cliff-Walking (Python-only)||[67, Chapter 6]|
|Minimax (and Alpha-Beta) Search||Search||Wikipedia, Wikipedia, |
|Monte Carlo tree search||Search||Wikipedia, [30, 18, 16]|
Sequence-form linear programming
|Counterfactual Regret Minimization (CFR)||Tabular||[78, 47]|
|External sampling Monte Carlo CFR||Tabular||[34, 35]|
|Outcome sampling Monte Carlo CFR||Tabular||[34, 35]|
|Advantage Actor-Critic (A2C)||RL|||
|Deep Q-networks (DQN)||RL|||
|Ephemeral Value Adjustments (EVA)||RL|||
|Exploitability Descent (ED)||MARL|||
|(Extensive-form) Fictitious Play (XFP)||MARL|||
|Neural Fictitious Self-Play (NFSP)||MARL|||
|Neural Replicator Dynamics (NeuRD)||MARL|||
|Regret Policy Gradients (RPG, RMPG)||MARL|||
|Policy-Space Response Oracles (PSRO)||MARL|||
|Q-based “all-action” Policy Gradients (QPG)||MARL||[68, 55, 66]|
|Regression CFR (RCFR)||MARL||[73, 46]|
|Rectified Nash Response ()||MARL|||
|-Rank||Eval / Viz|||
|Replicator / Evolutionary Dynamics||Eval / Viz||[27, 61]|
The following commands will clone the repository and build OpenSpiel on Debian or Ubuntu Linux. This is the fastest way to install OpenSpiel; however, there is at least one known problem222On Debian 10 and Ubuntu 19.04, the following error message is shown when running the pip3 command: tensorboard 1.14.0 has requirement setuptools>=41.0.0, but you’ll have setuptools 40.8.0 which is incompatible. The code builds and tests pass, but this may affect the usability of tensorboard.. Please see the recommended installation instructions using virtualenv for more detail.
Note that at this time, we have not tested OpenSpiel on any platform other than Linux. Also, some of the scripts and instructions currently assume Debian-based distributions (i.e. Debian, Ubuntu, etc.). All of the dependencies exist on other distributions, but may have different names, and package managers differ. Please see install.sh for necessary dependencies.
To be able to import the Python code (both the C++ binding pyspiel and the rest) from any location, you will need to add to your PYTHONPATH the root directory and the open_spiel directory. Add the following in your .bashrc or .profile:
After having built OpenSpiel following Sec 2.1, run the example from the build directory without any arguments:
This prints out a list of registered games and the usage. Now, let’s play a game of Tic-Tac-Toe with uniform random players:
Wow – how exhilarating! Now, why not try one of your favorite games?
Note that the structure in the build directory mirrors that of the source, so the example is found in open_spiel/examples/example.cc. At this stage you can run one of many binaries created, such as games/backgammon_test or algorithms/external_sampling_mccfr_test.
Once you have set your PYTHONPATH as explained in Sec 2.1.1, you can similarly run the python examples:
We describe here only the simplest and fastest way to add a new game. It is ideal to first be aware of the general API, which is described on a high level in Section 3, on github, and via comments in spiel.h.
Choose a game to copy from in games/. Suggested games: Tic-Tac-Toe and Breakthrough for perfect information without chance events, Backgammon or Pig for perfect information games with chance events, Goofspiel and Oshi-Zumo for simultaneous move games, and Leduc poker and Liar’s dice for imperfect information games. For the rest of these steps, we assume Tic-Tac-Toe.
Copy the header and source: tic_tac_toe.h, tic_tac_toe.cc, and tic_tac_toe_test.cc to new_game.h, new_game.cc, and new_game_test.cc.
Add the new game’s source files to games/CMakeLists.txt.
Add the new game’s test target to games/CMakeLists.txt
In new_game.h, rename the header guard at the the top and bottom of the file.
In the new files, rename the inner-most namespace from tic_tac_toe to new_game
In the new files, rename TicTacToeGame and TicTacToeState to NewGameGame and NewGameState
At the top of new_game.cc, change the short name to new_game and include the new game’s header.
Add the short name to the list of excluded games in integration_tests/api_test.py.
Add the short name to the list of expected games in python/tests/pyspiel_test.py.
You should now have a duplicate game of Tic-Tac-Toe under a different name. It should build and the test should run, and can be verified by rebuilding and running the example from Section 2.2.
Now, change the implementations of the functions in NewGameGame and NewGameState to reflect your new game’s logic. Most API functions should be clear from the game you copied from. If not, each API function that is overridden will be fully documented in superclasses in spiel.h. See also the description of extensive-form games in Section 3.1 which closely matches the API.
Once done, rebuild and rerun the tests from Sec 2.1 to ensure everything passes (including your new game’s test!)
Adding a new algorithm is fairly straight-forward. Like adding a game, it is easiest to copy and start from one of the existing algorithms. If adding a C++ algorithm, choose one from algorithms/. If adding a Python algorithm, choose one from python/algorithms/. For appropriate matches, see Table 2.
Unlike games, there is no specific structure or API that must be followed for an algorithm. If the algorithm is one in a class of existing algorithms, then we advise keeping the style and design similar to the ones in the same class, re-using function or modules where possible.
The algorithms themselves are not binaries, but classes or functions that can be used externally. The best way to show an example of an algorithm’s use is via a test. However, there are also binary executables in examples/ and python/examples/.
The purpose of OpenSpiel is to promote general multiagent reinforcement learning across many different game types, in a similar way as general game-playing  but with a heavy emphasis on learning and not in competition form. We hope that OpenSpiel could have a similar effect on general RL in games as the Atari Learning Environment [6, 39] has had on single-agent RL.
OpenSpiel provides a general API with a C++ foundation, which is exposed through Python bindings (via pybind11). Games are written in C++
. This allows for fast or memory-efficient implementations of basic algorithms that might need the efficiency. Some custom RL environments are also implemented in Python. Most algorithms that require machine learning are implemented in Python.
Above all, OpenSpiel is designed to be easy to install and use, easy to understand, easy to extend (“hackable”), and general/broad. OpenSpiel is built around two major important design criteria:
Keep it simple. Simple choices are preferred to more complex ones. The code should be readable, usable, extendable by non-experts in the programming language(s), and especially to researchers from potentially different fields. OpenSpiel provides reference implementations that are used to learn from and prototype with, rather than fully-optimized / high-performance code that would require additional assumptions (narrowing the scope / breadth) or advanced (or lower-level) language features.
Keep it light. Dependencies can be problematic for long-term compatibility, maintenance, and ease-of-use. Unless there is strong justification, we tend to avoid introducing dependencies to keep things portable and easy to install.
There are several formalisms and corresponding research communities for representing multiagent interactions. It is beyond the scope of this paper to survey the various formalisms, so we describe the ones most relevant to our implementations. There have been recent efforts to harmonize the terminology and make useful associations among algorithms between computational game theory and reinforcement learning [66, 38, 32], so we base our terminology on classical concepts and these recent papers.
, though in some cases can also be cyclic such as in Markov Decision Processes and Markov games . We first give the classical definitions, then describe some extensions, and explain some equivalent notions between the fields of reinforcement learning and games.
An extensive-form game is a tuple , where
is a finite set of players333Note that the player IDs range from to in the implementations.. There is also a special player , called chance.
is a finite set of actions that players can take. This is a global set of state-independent actions; generally, only a subset of legal actions are available when agents decide.
is a finite set of histories. Each history is a sequence of actions that were taken from the start of the game.
is a subset of terminal histories that represents a completely played game.
, where , is the utility function assigning each player a utility at terminal states, and are constants representing the minimum and maximum utility.
is a player identity function; identifies which player acts at .
is a set of states. In general, is a partition of such that each state contains histories that cannot be distinguished by . Decisions are made by players at these states. There are several ways to precisely define as described below.
We denote the legal actions available at state as . Importantly, a history represents the true ground/world state: when agents act, they change this history, but depending on how the partition is chosen, some actions (including chance’s) may be private and not revealed to some players.
We will extend this formalism further on to more easily describe how games are represented in OpenSpiel. However, we can already state some important categories of games:
A constant-sum (-sum) game is one where .
A zero-sum game is a constant-sum game with .
An identical interest game is one where .
A general-sum game is one without any constraint on the sum of the utilities.
In other words: -sum games are strictly competitive, identical interest games are strictly cooperative, and general-sum games are neither or somewhere in between. Also,
A perfect information game is one where there is only one history per state: .
A imperfect information game is one where there is generally more than one history per state, .
Chess, Go, and Breakthrough are examples of perfect information games without events (no chance player). Backgammon and Pig are examples of perfect information games with chance events. Leduc poker, Kuhn poker, Liar’s Dice, and Phantom Tic-Tac-Toe are examples of imperfect information games. Every one of these example games is zero-sum.
A chance node (or chance event) is a history such that .
In zero-sum perfect information games, minimax and alpha-beta search are classical search algorithms for making decisions using heuristic value functions. The analogs for perfect information games with chance events are expectiminimax  and *-minimax .
We can augment the extensive-form game with a special kind of player, the simultaneous move player: . When , each player has a set of legal actions , and all players act simultaneously choosing a joint action . Histories in these games are then sequences of joint actions, and transitions take the form . The rest of the properties from extensive-form games still hold.
A normal-form (or one-shot game) is a simultaneous-move game with a single state, . A matrix game is a normal-form game where .
A simultaneous-move game can be represented as a specific type of extensive-form game with imperfect information.
To see why this is true: consider the game of Rock, Paper, Scissors () where each player chooses a single action, revealing their choice simultaneously. An equivalent turn-based is the following: the first player writes their action on a piece of paper, and places it face down. Then, the second player does the same. Then, the choices are revealed simultaneously. The players acted at separate times, but the second player did not know the choice made by the first player (and hence could be in one of three histories: ), and the game has two states instead of one state. In a game with many states, the same idea can simply be repeated for every state.
Why, then, represent these games differently? There are several reasons:
They have historically been treated as separate in the multiagent RL literature.
They can sometimes be solved using Bellman-style dynamic programming, unlike general imperfect information games.
They are slightly more general. In fact, one can represent a turn-based game using a simultaneous-move game, simply by setting for or by adding a special pass move as the only legal action when it is not a player’s turn.
We elaborate on each of these points in the following section, when we relate simultaneous-move games to existing multiagent RL formalisms.
We now add the last necessary ingredients for designing decision-making and learning algorithms, and bring in the remaining standard RL terms.
A policy , where represents the set of probability
represents the set of probability distributions over, describes agent behavior. An agent acts by selecting actions from its policy: . A deterministic policy is one where at each state the distribution over actions has probability on one action and zero on the others. A policy that is not (necessarily) deterministic is called stochastic.
In games, the chance player is special because it always plays with a fixed (stochastic) policy .
A transition function defines a probability distribution over successor states when choosing action from state .
A transition function can be equivalently represented using intermediate chance nodes between the histories of the predecessor and successor states and . The transition function is then determined by and .
A player, or agent, has perfect recall if, the state does not lose the information about the past decisions made by the player. Formally, all histories , contain the same sequence of action of the current player: let be the history of only player ’s state-action pairs experienced along . Player has perfect recall if for all .
In Poker, a player acts from an information state, and the histories corresponding to such an information state only differ in the chance event outcomes that correspond to the opponent’s private cards. In these partially-observable games, a state is normally called an information state to emphasize the fact that the agent’s perception of the state () is different than the true underlying world state (one of ).
The property of perfect recall turns out to be a very important criterion for determining convergence guarantees for exact tabular algorithms, as we show in Section 3.2.
An observation is a partial view of the information state and contains strictly less information than the information state. To be valid, the sequence of observations and actions of all players should contain at least as much information as the information state. Formally: Let be a finite set of observations. Let be an observation function for player and denote as the observation. As contains histories , we will write if . A valid observation is such that the function defines a partition of the history space that is a sub-partition of .
In a multiplayer game, we define a per-step reward to player for a transition as , with
representing the vector of returns to all players. In most OpenSpiel games, theseuntil is terminal, ending the episode, and these values are obtained by State::Rewards and State::PlayerReward function called on . Player interaction over an episode generates a trajectory whose length is . We define a return to player as with representing a vector of rewards to all players as with per-step rewards. In OpenSpiel, the State::Returns function provides and State::PlayerReturn provides
. Note that we do not use a discount factor when defining rewards here because most games are episodic; learning agents are free to discount rewards however they like, if necessary. Note also that the standard (undiscounted) return is the random variable.
Each agent’s objective is to maximize its own return, or an expected return . However, note that the trajectory sampled depends not just on player ’s policy but on every other player’s policies! So, an agent cannot maximize its return in isolation: it must consider the other agents as part of its optimization problem. This is fundamentally different from traditional (single-agent) reinforcement learning, and the main challenge of multiagent RL.
Here, we give an overview of the algorithms implemented within OpenSpiel.
Suppose players are playing with a joint policy . The expected returns algorithm computes for all players exactly, by doing a tree traversal over the game and querying the policy at each state . Similarly, for small enough games, one can get all the states () in a game by doing a tree traversal and indexing each state by its information state string description.
The trajectories algorithms run a batch of episodes by following a joint policy , collecting various data such as the states visited, state policies, actions sampled, returns, episode lengths, etc., which could form the basis of the data collection for various RL algorithms.
There is a simple implementation of value iteration. In single-agent games, it is identical to the standard algorithm . In two-player turn-taking zero-sum games, the values for state , i.e. , is stored in view of the player to play at , i.e. . This can be solved by applying the identities and .
Suppose one wants to choose at some root state : given a heuristic value function for (representing the value of state to player ) and some depth , minimax search computes a policy that assigns 1 to an action that maximizes the following depth-limited adversarial multistep value backup:
where here we treat as a deterministic map for the successor state reached from taking action in state .
The Python implementation of minimax includes expectiminimax  as well, which also backs up expected values at chance nodes. Alpha-beta style cut-offs could also be applied using -minimax , but it is not currently implemented.
The implementations of MCTS are vanilla UCT with random playouts. Chance node are supported and represented explicitly in the tree: at chance nodes, the tree policy is always to sample according to the chance node’s probability distibution.
OpenSpiel includes some basic optimization algorithms applied to games, such as solving zero-sum matrix games ([63, Section 4], ) and sequence-form linear programming for two-player zero-sum extensive-form games ( and [63, Section 5]), and an algorithm to check whether an action is dominated by a mixture of other strategies in a normal-form [63, Sec 4.5.2].
We currently have three algorithms usable for traditional (single-agent) RL: Deep Q-Networks (DQN) , Advantage Actor-Critic (A2C) , and Ephemeral Value Adjustments (EVA) . Each algorithm will operate as the standard one in single-agent environments.
Each of these algorithms can also be run in the multiagent setting, in various ways. The default is that each player is independently running a copy of the algorithm with states and observations that include what other players did. The other way to use these algorithms is to compute an approximate best response to a fixed set of other players’ policies, described in Section 3.2.5.
The main difference between the implementations of these algorithms and other standard ones is that these are aware that only a subset of actions are legal / illegal. So, for example, in Q-learning the value update for a transition and policy updates are:
Note that the actions are in the set of legal actions and
rather than assuming that every action is legal at every state. For policy gradient methods, a masked softmax is used to set the logits of the illegal actions toto force the policy to sets probability zero to illegal actions.
There are many algorithms for reinforcement learning in partially-observable (zero-sum) games, as this is the focus of the core team’s research interests.
Best Response and NashConv
Suppose is a joint policy. A best response policy for player is a policy that maximized player ’s return against the other players’ policies (). There may be many best responses, and we denote the set of such best responses,
Let be the incentive for player to deviate to one of its best responses: where . An approximate -Nash equilibrium is a joint policy such that for all , where a Nash equilibrium is obtained at .
A common metric for determining the rates of convergence (to equilibria) of algorithms in practice is:
In two-player constant-sum (i.e. -sum) games, a similar metric has been used:
where . Nash equilibria are often considered optimal in two-player zero-sum games, because they guarantee maximal worst-case returns against any other opponent policy. This is also true for approximate equilibria, so convergence to equilibra has been a focus in this class of games.
Fictitious Play and Best Response-Based Iterative Algorithms
Each player computes a best response to the opponents’ average policy: .
Each player updates their average policy: .
OpenSpiel has an implementation of extensive-form fictitious play (XFP) , which is equivalent to the classical fictitious play. To run it on normal-form games, the game needs to be transformed into a turn-based game using TurnBasedSimultaneousGame in game_transforms/
. Fictitious Self-Play is a sampled-based RL version of XFP that uses supervised learning to learn the average policy and reinforcement learning to compute approximate best responses. Neural Fictitious Self-Play (NFSP) scales these ideas using neural networks and a reservoir-sampled buffer to maintain a uniform sample of experience to train the average policy.
The average policy in fictitious play can be described equivalently as a meta-policy that assigns uniform weight over all the previous best response policies, and each iteration computes a best response to the opponents’ meta-policies. Policy-Space Response Oracles (PSRO) generalizes fictitious play and the double-oracle algorithm [36, 40] by analyzing this meta-game using empirical game-theoretic analysis . Exploitabiliy Descent replaces the second step of fictitious play with a policy gradient ascent against the state-action values given the opponents play their best responses . This one change allows convergence of the policies themselves rather than having to maintain an average policy; in addition, it makes the optimization of the polices amenable to RL-style general function approximation.
Counterfactual Regret Minimization
Counterfactual regret (CFR) minimization is a policy iteration algorithm for computing approximate equilibra in two-player zero-sum games . It has revolutionized Poker AI research [58, 60], leading to the largest variants of poker being solved and competitive polices that have beat top human professionals [10, 45, 13, 15].
CFR does two main things: (a) define a new notion of state-action value, the counterfactual value, and (b) define a decomposed regret minimization procedure (based on these values) at every information state that, together, leads to minimization of overall average regret. This means that the average policy of two CFR players approaches an approximate equilibrium.
Define as the set of terminal histories that pass through , paired with the prefix of each terminal . Define a reach probability to be the product of all players’ probabilities of state-action pairs along (including chance’s), which can be decomposed into player ’s contribution and their opponents’ contributions: . Similarly define similarly from to and as the history appended with action . The counterfactual state-action value for is:
The state value is then .
CFR starts with a uniform random policy and proceeds by applying regret minimization at every information state independently. Define to be the instantaneous counterfactual regret. CFR proceeds by minimizing this regret, typically using regret-matching . A table of cumulative regret is maintained , and the policy at each state is updated using:
Regression CFR (RCFR) was the first variant to combine RL-style function approximation with CFR techniques [73, 46]. The main idea is to train a regressor to predict the cumulative or average counterfactual regrets, or , instead of reading them from a table. The original paper used domain-specific features and regression trees. The implementation in OpenSpiel uses neural networks with raw inputs obtained by each game’s InformationSetAsNormalizedVector bit string.
Figure 2 shows the convergence rate of RCFR compared to a tabular CFR.
Deep CFR  applies these ideas to a significantly larger game using convolutional networks, external sampling Monte Carlo CFR, and–like NFSP–a reservoir-sampled buffer.
Regret Policy Gradients
Value-based RL algorithms, such as temporal-difference learning and Q-learning, evaluate a policy
by computing or estimating state (or state-action) values that represent the expected return conditioned on having reached state,
Policies are improved by choosing the actions that lead to higher-valued states or higher-valued returns.
In episodic partially-observable games, when agents have perfect recall (Def 5), there is an important connection between traditional values in value-based RL and counterfactual values [66, Section 3.2]:
where is the Bayes normalization term to ensure that is a probability distribution. CFR is then as a (tabular) all-actions policy gradient algorithm with generalized infinitesimal gradient ascent (GIGA) at each state , inspiring new RL variants for partially observable games.
These variants: Q-based “all-actions” Policy Gradient (QPG), Regret Policy Gradients (RPG), and Regret-Matching Policy Gradients (RMGP) are included in OpenSpiel, along with classic batched A2C. RPG differs from QPG in that the policy is optimized toward a no-regret region, minimizing the loss based on , the motivation being that a policy with zero regret is, by definition, an equilibrium policy. Convergence results for these algorithms are show in Figure 3.
Neural Replicator Dynamics
Neural Replicator Dynamics (NeuRD)  takes the policy gradient connection to CFR a step further: in , the relationship between policy gradients and CFR was possible via GIGA ; however, this requires projections of policies after the gradient step. NeuRD, on the other hand, works directly with the common softmax-based policy representations. Instead of differentiating through the softmax as policy gradient does, NeuRD differentiates only with respect to the logits. This is equivalent to updating the policy of a parameterized replicator dynamics from evolutionary game theory [27, 61] using an Euler discretization. The resulting update reduces to the well-known multiplicative weights update algorithm or Hedge , which minimizes regret. Hence, NeuRD in partially-observable games can replace regret-matching in CFR and retain convergence guarantees in the tabular case since that algorithm reduces to CFR with Hedge.
One practical benefit is that the NeuRD policy updates are not weighted by the policy like policy gradient is. As a result, in non-stationary domains, NeuRD is also more adaptive to changes in the environment. Results for NeuRD are show in Figures 4 and 5.
|Kuhn poker||Goofspiel||Leduc poker|
OpenSpiel has a few tools for visualization and evaluation, though some would also be considered algorithms (such as -Rank). The best response algorithm is also a tool in some sense, but is listed in Section 2 due to its association with partially-observable games.
For now, all the tools and evaluation we mention in this section is contained under the egt/ subdirectory of the code base. We expect this to change over time as that subdirectory is currently the home of the techniques inspired by evolutionary game theory.
One common visualization tool in the multiagent learning literature (especially in games) is a phase portrait that shows a vector field and/or trajectories of particle the depict local changes to the policy under specific update dynamics [64, 72, 11, 71, 9, 74, 2, 76, 75, 7, 70].
For example, consider the well-known single-population replicator dynamic for symmetric games, where each player follows a learning dynamic described by:
where represents the expected utility of playing action against the full policy , and is the expected value over all actions .
-Rank  is an algorithm that leverages evolutionary game theory to rank AI agents interacting in multiplayer games. Specifically, -Rank defines a Markov transition matrix with states corresponding to the profile of agents being used by the players (i.e., tuples of AI agents), and transitions informed by a specific evolutionary model that ensures correspondence of the rankings to a game-theoretic solution concept known as a Markov-Conley Chain. A key benefit of -Rank is that it can rank agents in scenarios involving intransitive agent relations (e.g., the agents Rock, Paper, and Scissors in the eponymous game), unlike the Elo rating system ; an additional practical benefit is that it is also tractable to compute in general games, unlike ranking systems relying on Nash equilibria .
OpenSpiel currently supports using
-Rank for both single-population (symmetric) and multi-population games. Specifically, users may specify games via payoff tables (or tensors for the >2 players case) as well as Heuristic Payoff Tables (HPTs). Note that here we only include an overiew of the technique and visualizations; for a tour through the usage and code please see the-Rank doc on the web site.
Figure 8(a) shows a visualization of the Markov transition matrix of -Rank run on the Rock, Paper, Scissors game. The next example demonstrates computing -Rank on an asymmetric 3-player meta-game, constructed by computing utilities for Kuhn poker agents from the best response policies generated in the first few rounds of via extensive-form fictitious play (XFP) . The result is shown in Figure 8(b).
One may choose to conduct a sweep over the ranking-intensity parameter, (as opposed to choosing a fixed ). This is, in general, useful for general games where bounds on utilities may be unknown, and where the ranking computed by -Rank should use a sufficiently high value of (to ensure correspondence to the underlying Markov-Conley Chain solution concept). In such cases, the following interface can be used to both visualize the sweep and obtain the final rankings computed. The result is shown in Figure 9.
If you are looking for ideas on potential contributions or want to see a rough road map for the future of OpenSpiel, please visit the Roadmap and Call for Contributions on github.
Before making a contribution to OpenSpiel, please read the design philosophy in Section 3. We also kindly request that you contact us before writing any large piece of code, in case (a) we are already working on it and/or (b) it’s something we have already considered and may have some design advice on its implementation. Please also note that some games may have copyrights which could require legal approval(s). Otherwise, happy hacking!
If you would like to contact us regarding anything related to OpenSpiel, please create an issue on the github site so that the team is notified, and so that the responses are visible to everyone.
Proceedings of the 26th ACM Symposium on Theory of Computing (STOC ’94), pages 750–759, 1994.