Tuxemon is a monster-fighting RPG where the content is JSON and the code is Python

Data in JSON, code in Python, no compiler needed

Tuxemon is a free, open source monster-fighting role playing game, and the README says it is in constant development and improving all the time, with contributors of all skill and level welcome to join.

The feature list is short and every entry is a statement about how the game is put together. Game data is all json, easy to modify and extend. Game maps are created using the Tiled Map Editor. There is a simple game script to write the story, with dialogs, interactions on map and NPC scripting. It is localized in several languages, with seamless keyboard, mouse and gamepad input, animated maps and lots of documentation. Python code can be modified without a compiler. There is a CLI interface for live game debugging. And it runs on Windows, Linux, OS X, and has some support on Android.

That combination is the design. A game written in Python running on Pygame, with the content in data files, means the difference between a player and a contributor is the difference between installing a package and editing a JSON file. There is no engine to learn and no asset pipeline to set up before you can add a monster.

The Tiled choice is worth noting. Tiled is a widely used tile map editor, and using it rather than a proprietary or in-house format means map authors use a tool they may already know and that the project does not have to maintain.

The content counts in the README give a sense of scale. There are 393 monsters and 18 threats with sprites, 274 techniques to use in battle, 208 NPC sprites and 223 items. Those numbers are the shipped content, not the ceiling, since the whole point of the JSON data is that anyone can add more.

Dev tools and a map editor in the same package

Two features in the README are aimed squarely at the person making the game rather than the person playing it.

The first is the developer tools. You can enable dev_tools by changing dev_tools to True in the tuxemon.yaml file:

[game]
dev_tools = True

With that on, two keyboard shortcuts become available, r to reload the map tiles and n for no clip. The reload is the interesting one, because in a tile based engine reloading the map without restarting the process is what makes iterating on a level bearable, and no clip is what lets you walk through a wall to check a trigger volume you cannot otherwise reach.

The second is the map editor, which is not part of the game at all. Use the Tiled map editor, at https://www.mapeditor.org/. The game reads Tiled maps, and the authoring happens in a separate application.

The CLI interface for live game debugging is the third, and it is listed as a feature alongside a documentation page at docs/cli.md. A game that is scriptable from a console while it is running is a different proposition from one that is not, and it is what turns Tuxemon from a game into a platform for other people to build in.

The controls are deliberately conventional, which matters for a game with gamepad support. Arrow keys move, Enter selects or activates, Escape opens the menu or cancels, and Shift sprints. And the inputs can be set in the options menu or in the config file, so a rebind is a config change rather than a code change.

Installing from source and the build scripts you should not run locally

The installation documentation is at docs/installation.md, with a separate section for Fedora Linux, and the mods documentation is at docs/mods.md. The README itself does not reproduce the install steps, so those documents are where the platform packages are described.

The build side is different, and the README gives it directly. There are many scripts for various builds in the buildconfig folder, meant to be run from the project root directory, for example to build the portable pypy build:

[user@localhost Tuxemon]$ buildconfig/build_pypy_portable_linux.sh

There will be a new directory called build, which will have the package if everything was successful.

Then the warning, which is emphatic and worth repeating. The build scripts are designed to be run in a dedicated VM. They will add and remove packages and could leave your OS in a bad state. You should not use them on your personal computer, use in a VM or container.

That is a stronger warning than most projects give, and it is a consequence of the packaging approach. A portable build that bundles its own Python interpreter and its dependencies has to install and remove system packages to do it, which is fine in a throwaway VM and destructive on a workstation.

For ordinary development, the Makefile at the top of the repository is the entry point. The setup target upgrades and installs the requirements, test-setup installs the package with the test extra, dev-setup with the dev extra, run executes python ./run_tuxemon.py, and test, format, lint and type all delegate to tox, with the test target using the py3 environment. The project also has run_tuxemon.py at the top level, which is the script a contributor runs before installing anything.

A game with a plugin ecosystem for content

The mods directory and the mods documentation are the part of the project that makes it interesting to a content author rather than only to a player.

Mods are how content gets added to Tuxemon, and because the underlying data is JSON and the story is written in a simple script, a mod is a set of data files rather than a compiled extension. The documentation page for mods is listed alongside the installation and CLI pages in the README, and the repository has a mods/ directory at the top level.

The dependency list shows the technology choices, and they are all deliberate. pygame-ce at 2.5.7 is the community edition of Pygame, the main game library, and pygame-menu-ce at 4.5.2 is the matching menu library, both pinned exactly. pytmx at 3.32 is the Tiled map loader, which is the direct counterpart to the Tiled authoring workflow. pyscroll at 2.31 or newer handles smooth camera scrolling, prompt_toolkit is the terminal library behind the CLI, and PyYAML at 6.0.2 or newer backs the tuxemon.yaml configuration. pydantic at 2.10.6 or newer does the data validation, which is how a game whose content is user-editable JSON avoids silently loading a broken file.

There are also websockets for the networking parts and natsort for natural sorting, cbor for binary serialisation, babel for localisation, pillow for image handling and requests for HTTP.

The build system is setuptools with setuptools-scm. The package metadata declares the version 0.4.35, requires Python 3.10 or newer, classifies the project as Development Status 3 - Alpha, and supports Python 3.10 through 3.14. The tuxemon console script points at tuxemon.__main__:main.

The save system has its own architecture document, docs/save_system.md, which is unusual and sensible. Save compatibility is the thing that breaks when a game with user-editable data changes its format, and documenting it separately means a modder knows what they are dealing with.

Where Tuxemon is the wrong choice

The first limit is content completeness and stability. The README says the game is in constant development, and the release history shows v0.5-rc1 in April 2026 and v0.5-rc2 on 2026-09-28, so the current line is a release candidate rather than a finished release. There is also a tag called latest labelled Latest Build (Development) dated 2024-01-21, which suggests the project has had more than one attempt at a rolling build channel. A player who wants a stable, unchanging game will find the branch structure and the alpha status awkward.

The second is the platform support claim. It runs on Windows, Linux and OS X, and has some support on Android. The phrase some support is doing real work, and there is no mention of iOS, no console version and no mention of a mobile release process. The Android path in particular depends on the SDL layer the project uses, and the README does not describe how that is packaged or maintained.

The third is the packaging hazard. The build scripts are explicitly documented as destructive to a host system and intended for a dedicated VM or container. A project whose official build process cannot be run on a normal development machine has a barrier at the point where contributors would naturally start, and the practical workaround is to work from source with the requirements rather than to produce a portable build.

The fourth is the dependency pins. pygame-ce and pygame-menu-ce are pinned to exact versions while several others float, and Pygame and its ecosystem are where the churn is. A pinned Pygame is what makes the game reproducible, and it is also what means a Pygame release with a needed fix is not available until the pin moves.

The fifth is that the whole thing depends on a volunteer project with a single named author in the metadata. The copyright is held by William Edwards and Benjamin Bean from 2014 to 2026, with maintainers listed as the Tuxemon Community, so the project has community governance in name, but the concentration of the copyright is a continuity consideration for anyone thinking about a long-lived mod ecosystem.

Editorial conclusion

Tuxemon suits a player who wants an open monster-catching RPG with no paywall, and a modder who wants to write content in JSON and a scripting language rather than in a compiled engine. It is the wrong tool if you want a finished, content-complete commercial game, since the README describes it as in constant development and the release line is still at release candidate stage. Before installing, read docs/mods.md and docs/installation.md, because the mod format and the platform packages are where the practical detail lives. Verify first that the version you install matches the game data you have, since the save system and the data format are versioned together.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Tuxemon/Tuxemon on GitHub