RPG Tactical Fantasy Game: a turn-based squad game built in pygame

What the game is

RPG Tactical Fantasy Game is a tactical fantasy RPG, turn-based and in 2D, written in Python with pygame and published under the GPL 3.0 licence. The repository describes itself as open to collaborative development, and the screenshots give the shape of it: a main screen showing possible moves and attacks for the selected unit, an inventory menu, and a status window. The design is the familiar squad tactics one, with a grid of tiles, a selected player, and a menu opened by clicking an empty tile. The release history shows the shape of the project too. There is a v1.1.0 tagged as a big release after five years without one, dated 2025-12-13, preceded by v1.0.4 in November 2020 and v1.0.3 in July 2020, the first series of levels being ready. The readme still shows version 1.0.4 in its own text while the manifest says 1.1.0, which is the usual sign of a project where the documentation lags the code.

Running it, and the Python version mismatch

On 64-bit Windows the releases page has a prebuilt executable, which is the fastest way to see whether the game is for you. To run from source, or to work on the game, you need Python 3.13 or above installed and uv, the Python package and environment manager, and then one command starts it.

uv run main.py

There is a version wrinkle worth knowing about before you hit it. The readme asks for Python 3.13 or above, and the project manifest says requires-python of 3.14 or newer, so a machine with 3.13 will not satisfy the manifest. The dependencies are short and tell you what the game is built on: pygame-ce at 2.5.8 or newer for the window and input, pygame-popup for the menu widgets, pytmx for the tile maps, lxml for the XML data files, and pytest 9 or newer for the tests. The uv configuration marks the project as not a package, with package set to false, which is the right setting for an application rather than a library, since you run it rather than install it.

The controls, which are the whole interface

The key bindings are listed in five lines and they explain how the game feels in play. Left click is the main button and it selects a player, chooses a tile to move to, or selects an action to do. Left click on any empty tile opens or closes the main menu, so the menu is not a separate mode but an overlay on the board. Left click on any entity that is not a player who has finished his turn opens a window giving information about that entity, which is how you inspect an enemy before committing. Right click deselects the current player or cancels the last action if that is possible. Right click on any entity shows the possible movements of that entity, which is the tactical planning tool: you can look at where a unit could go before deciding. And the Esc key closes a menu on the top layer. The three screenshots referenced in the readme correspond to the first, second and fourth of those behaviours.

The XML data files, and balancing as a contribution

The most appealing thing about the project for a contributor is where the balance lives. All values could be found in the XML files wrapped in the data folder, and the readme asks for help with balancing, saying that all values could be found in the XML files in the data folder. The author also notes that he is not good in this kind of games even if he loves them, which is an honest framing of why outside input is wanted. The top level of the repository shows the content structure this implies, with a data/ directory, a maps/ directory, an imgs/ directory, a fonts/ directory and a sound_fx/ directory, plus a src/ directory for the code and tests/ for the test suite. There is also an entities_uml.png at the root, a class diagram for the entity model, which tells you the entities are the main structural idea and that they are documented rather than implicit.

Large assets and Git LFS

Images, sounds and fonts live in Git LFS, and the readme asks contributors to enable it before committing, with three commands.

git lfs install
git lfs track "*.png" "*.wav" "*.ttf"
git add .gitattributes

And there is a second step for anyone running the game on a system for the first time, which the readme flags as something you may need to do explicitly.

git lfs pull

That second command is the one people forget, because a fresh clone gives you pointer files rather than the actual images, and the game then fails to draw. The .gitattributes file at the repository root is what the tracking command registers, and it is committed alongside the change. The asset directories are the ones the tracking patterns cover, with the imgs/ directory for images, the sound_fx/ directory for sound effects and the fonts/ directory for fonts, and the packaging definition is a fivecats.spec file, which is a PyInstaller specification, so the Windows executable is built from the same sources.

How to contribute, and what is being asked for

There are four routes in, and the readme is unusually open about them. You can submit any request or report any bug by emailing the address given or by opening an issue. You can join the community Discord. You can feel free to come up with ideas about coding practices or game mechanics, since the project is far from being perfect. And then there are the specific suggestions. Check the opened issues, where there are bugs that could be fixed and enhancements waiting for implementation. Fix the TODOs, which are spread everywhere across the project, with some being easy enough for a beginner and others more challenging. Help with balancing. And contribute sound effects or new soundtracks, which the author says would be really appreciated.

The readme is also available in several languages, with the English original alongside Simplified Chinese, Traditional Chinese, Spanish and French versions, which is a signal about who the project is trying to reach.

Where this project is the wrong choice

Two boundaries are clear from the readme. The first is expectations of polish. The project states plainly that it is far from being perfect, and the author is candid about his own unfamiliarity with the genre, which means this is a game in progress with a working core and a small amount of content rather than a finished product with a large amount of content. If you want a tactical RPG with a hundred levels and a campaign, this is not it, and the level set reflects that. The second is tooling. The project runs on uv with a pinned dependency set and no packaging for distribution beyond a single PyInstaller spec for 64-bit Windows, so a contributor on an unusual platform is on their own. It is also worth setting expectations about the pace. A gap of five years between the v1.0.4 release in 2020 and the v1.1.0 release in late 2025 tells you how often the project ships, so if you are picking up an issue to work on, the Discord and the issue tracker are where the current priorities actually live.

Editorial conclusion

RPG Tactical Fantasy Game fits a player who wants a small, open tactical RPG they can read, fork and extend, and it fits a contributor who wants a project where adding a level or rebalancing a unit is a data edit rather than a code change. It does not fit a player looking for a polished commercial game, since the project says outright that it is far from being perfect and that the author is not good at this kind of game. It also does not fit a contributor who wants a modern managed build, because the project pins Python 3.13 in the readme while the manifest asks for 3.14 or newer, which is a mismatch you will meet on the first install. Before you contribute assets, enable Git LFS as the readme instructs, and remember that the first run on a fresh system needs an explicit git lfs pull.

Frequently asked questions

Official sources

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