# OpenSpiel: a framework for reinforcement learning in games

> A C++ and Python framework of game environments and algorithms from Google DeepMind, used by research groups and now by Kaggle environments. What the API covers, what version 2.0 changed, and how the build is put together

**google-deepmind/open_spiel** — OpenSpiel is a collection of environments and algorithms for research in general reinforcement learning and search/planning in games.

- Repository: https://github.com/google-deepmind/open_spiel
- Stars: 5,552 · Forks: 1,206
- Language: C++
- License: Apache-2.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/google-deepmind-open-spiel

## Games as laboratory environments

The repository description is compact: a collection of environments and algorithms for research in general reinforcement learning and search and planning in games. The README then expands the scope of that collection with a list that is worth reading slowly, because it defines what counts as a supported game. OpenSpiel covers n-player settings, single-agent and multi-agent, zero-sum, cooperative and general-sum, one-shot and sequential, strictly turn-taking and simultaneous-move, and games of both perfect and imperfect information. Alongside the classical game-theoretic cases it includes traditional multiagent environments such as partially and fully observable grid worlds and social dilemmas. Games are represented as procedural extensive-form games with some natural extensions, and the project adds tools for analysing learning dynamics and other common evaluation metrics. That last point matters more than it first appears, since a framework that only hands you environments leaves every group reinventing the same convergence plots. The repository records C++ as the primary language, an Apache-2.0 license, topics covering cpp, games, multiagent, python and reinforcement learning, 5,498 stars, 1,186 forks, 62 open issues, a default branch named master, and a last push on 2026-08-31 with the project not archived.

## A C++ core with a Python surface

The implementation split is deliberate and stated plainly: the core API and the games are implemented in C++ and exposed to Python, while algorithms and tools are written in both languages. The reasoning is straightforward for search and planning work, where you replay game trees many times and the per-node cost dominates. The project metadata reflects the same pragmatism, since the package is named open-spiel, the license identifier is Apache-2.0, and the Python floor is 3.11:

```toml
[project]
name = "open-spiel"
version = "2.0.2"
description = "A Framework for Reinforcement Learning in Games"
readme = "README.md"
requires-python = ">=3.11"
license = "Apache-2.0"
```

Building it is a compiled step rather than a pure Python install. The build system asks for setuptools, wheel, cmake 3.15 or newer, and ninja on platforms other than Windows, and setup.py defines a setuptools extension with no sources that hands the real work to CMake. That combination is why a missing compiler shows up as a build failure at install time instead of an import error later. The supported Python versions are declared as 3.11, 3.12 and 3.13 in the classifier list, which is a narrower range than many callers expect from a research library.

## Dependencies split into required and optional

The core dependency list is deliberately short, and the reasoning is documented rather than left implicit. Five packages are treated as absolutely necessary for the Python API:

```
pip >= 20.0.2
attrs >= 19.3.0
absl-py >= 0.10.0
numpy >= 1.21.5
scipy >= 1.10.1
ml-collections >= 0.1.1
```

Everything else is opt-in. The comments at the top of requirements.txt explain that packages used by only some of the Python algorithms and tools, with cvxpy, nashpy and matplotlib named as examples, are purposely excluded so the base install stays light, and that continuous integration installs a larger set separately through a script under open_spiel/scripts. The pyproject file mirrors that split with an extras group that pulls in plotting, game-theoretic equilibrium solvers, graph drawing, imaging, pygame, tensorflow and torch. If you only need to load a game and run an evaluation, you can stay inside the core five. The moment you start rendering plots or training a neural policy, the dependency surface grows quickly, and it is worth deciding early which side of that line you are on.

## What version 2.0 actually changed

The 2.0 release, published on 2026-07-14, is the first major version in a while and the release notes are unusually specific about the core API. State, observation and action became structs rather than the previous shapes, which is the change most likely to affect existing code. There is a new action struct reserved for games with large or open-ended action spaces, with the Crossword game given as the example, and the API gained standard trajectories. States can now carry optional starting states through State::StartingState and State::StartingStateStr, generally supported by serialization, which is what lets a game start from an arbitrary position rather than only from its initial one. On the modelling side, the release adds language model fine-tuning and QLoRA examples, with Gemma 3 through Kauldron and other models through huggingface, including Gemma 4, plus an MCP Server example demonstrated in the accompanying blog post. The stated motivation gives the clearest signal about where this project is heading: several OpenSpiel games are now used as Kaggle environments in the Kaggle Game Arena, and much of the work between 1.6 and 2.0 was done to support games for that arena.

## Two patch releases and a versioning promise

The releases after 2.0 tell you how the project is run day to day. v2.0.1 followed on 2026-07-17 with a narrow purpose, updating the PyPI wheels to carry recent bug fixes and game improvements in collaboration with the Kaggle Game Arena team. v2.0.2 arrived on 2026-08-12 and describes itself as a minor release for testing purposes with no substantial changes from 2.0.1. Reading those two entries together with the 2.0 notes suggests a workflow where the library is versioned for reproducibility by external users, including benchmark harnesses, while the main line of development continues quickly. The README states that the project follows Semantic Versioning, which is consistent with the 2.0 boundary: the struct-based API and the new action and trajectory types landed in the major version, and everything since has been additive. The published 2.0 notes also open a support and process section with Windows installation support, and the notes end mid-line there, so anything beyond that heading is not something the release text states.

## Where to start, and what is in the tree

The README is mostly an index, and the index is the most useful thing in it. It routes you to installation instructions for Linux and macOS with Windows handled separately, an introduction, an API overview with a first example, an API reference, overviews of implemented games and algorithms, a developer guide, a page on using OpenSpiel as a C++ library, contributing guidelines and an authors list. For background there is an arXiv paper, OpenSpiel: A Framework for Reinforcement Learning in Games, and two recorded tutorials with slides and Colab notebooks: one on the core API, replicator dynamics and imperfect information games, and one implementing CFR and REINFORCE on Kuhn poker, Leduc poker and Goofspiel. The tree itself supports a compiled Python library with a C++ core: install.sh, a Dockerfile.base, docs, MANIFEST.in, requirements.txt, setup.py, pyproject.toml, readthedocs.yml, clang-format and cmake-format configuration, a pre-commit setup and CONTRIBUTING. There is also an open_spiel/colabs directory for running the framework in Google Colaboratory, which sidesteps the local compile entirely.

## Conclusion

Start from the documentation index rather than from the source tree, since install instructions, an introduction, an API overview with a first example, and the game and algorithm listings are separate documents with distinct audiences. If your work is in Python, install the package and confirm the C++ extensions built before writing any algorithm code, because the import succeeding is the only real signal that CMake and a compiler were present. And if you are porting research from a 1.x release, read the 2.0 core API changes first, since state, observation and action became structs.

## FAQ

### Is OpenSpiel written in Python or C++?

Both, in a specific split. The core API and the games are implemented in C++ and exposed to Python, while algorithms and tools are written in either language. That is why installing the package compiles extensions through CMake and requires a C++ toolchain, even if all of your own code is Python. The repository's primary language is recorded as C++, and the build configuration asks for cmake 3.15 or newer plus ninja outside Windows.

### Which Python versions does OpenSpiel support?

Python 3.11 and newer. The package metadata declares requires-python of 3.11 or later and lists classifiers for 3.11, 3.12 and 3.13, while the README badge advertises 3.11. The core runtime dependencies are modest, with pip 20.0.2 or newer, attrs, absl-py, numpy, scipy and ml-collections, and heavier packages such as tensorflow and torch are available only through the extras group.

### How do I find the list of games and algorithms?

The README indexes a documentation set that includes an overview of implemented games and a separate overview of implemented algorithms, alongside an API reference, an API overview with a first example and an introduction. The framework covers perfect and imperfect information games, simultaneous and turn-taking moves, cooperative and competitive settings, plus grid worlds and social dilemmas. The arXiv paper and the two linked tutorial sessions add conceptual background and worked examples.

### What is the OpenSpiel MCP Server example?

It is an example server added in the 2.0 release, demonstrated in the Introducing OpenSpiel 2.0 blog post linked from the release notes. It arrived alongside other additions aimed at current model workflows, including language model fine-tuning and QLoRA examples covering Gemma 3 through Kauldron and other models through huggingface. The release notes attribute much of the work between 1.6 and 2.0 to supporting games used in the Kaggle Game Arena.

### Can I use OpenSpiel as a C++ library without Python?

The documentation index includes a page specifically on using OpenSpiel as a C++ library, alongside a developer guide. Since the games and core API are implemented in C++ and only exposed upward to Python, the C++ path is the native one rather than a wrapper. The README also notes that algorithms and tools exist in both languages, so what you write in C++ is a matter of where your existing code already lives.

## Sources

- [google-deepmind/open_spiel on GitHub](https://github.com/google-deepmind/open_spiel)
- [Issues](https://github.com/google-deepmind/open_spiel/issues)
- [License: Apache-2.0](https://github.com/google-deepmind/open_spiel/blob/master/LICENSE)
- [README](https://github.com/google-deepmind/open_spiel/blob/master/README.md)
- [Releases](https://github.com/google-deepmind/open_spiel/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-deepmind-open-spiel