# MapTool: a virtual tabletop that handles map lighting and token tracking

> MapTool is a Java virtual tabletop for pen and paper roleplaying games, with map creation, token properties, chat, an initiative tracker, and a vision system that lets a GM hide what players have not yet seen. It runs on Windows, Mac OS X and Linux, with an integrated server for remote play.

**RPTools/maptool** — Virtual Tabletop for playing roleplaying games with remote players or face to face.

- Repository: https://github.com/RPTools/maptool
- Website: http://rptools.net
- Stars: 931 · Forks: 285
- Language: Java
- License: AGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/rptools-maptool

## A battlemat, a dry-erase layer and a dice roller in one window

MapTool is the official repository for the MapTool Virtual Tabletop, a Java application for playing table-top role playing games such as D&D, PathFinder, GURPS, Call of Cthulhu, Star Wars and Shadowrun. The homepage is rptools.net.

The stated goal is to let users create, manage and play a pen and paper game either in person or remotely. The documentation describes the design intent plainly: the computer screen functions as a virtual table-top, fulfilling the role of battlemats and dry-erase markers, with infinitely scrollable maps and support for a large-screen TV or video projector.

Beyond the map layer there is a chat function, token management that tracks properties of the units placed on the map and displays health and status information, and an initiative tracker. The documentation notes that functions not being used can be hidden out of sight, which matters for a program with this many panels when the GM is sharing a screen.

One design decision shapes everything else. MapTool is game system agnostic. There is special support for particular systems, such as hexes for GURPS or square templates for D&D 4E, but there is no requirement to use those features. A GURPS group can ignore hexes, and a system with its own line of sight rules can use the built-in behaviour or ignore it, which keeps the tool from locking a table into one ruleset.

It is written in Java, and the source tree is a Gradle project with a clientserver module, a common module, a dicelib module, a messages module, a package directory and a tools directory.

## Vision and blocking decide what a player is allowed to see

The part of MapTool that goes beyond emulating a tabletop is the vision system. The documentation describes it as a set of topology and vision features that let the GM limit the view of players, revealing the map as they explore it.

Walls and other objects prevent players from seeing what lies behind them. Darkness can be made to fall, blinding players who lack a light. Lights can be set on objects or on tokens, and they illuminate as much or as little of the map as the GM wants.

There is one more level, which the documentation calls limiting the view of players to what their specific token sees. That is the fog-of-war behaviour at token granularity rather than at party granularity, so a character who cannot see around the corner of a wall is genuinely blind to what is behind it even while the rest of the party can see it.

This is where the topology work pays off. A square grid with a light source is a shading calculation; a grid with walls, blocking objects, per-token visibility and dynamic lights is a visibility graph that has to be recomputed as tokens move. That is a much heavier feature than the map rendering itself, and it is the reason MapTool is a program with a server mode rather than a static map viewer.

The practical consequence for a game master is that a session can look completely different from a physical table. On a physical table everyone sees the whole map and the GM hides things by covering them with their hand. With vision enabled, the map is progressively revealed, which changes the pacing of exploration and the tactics of a fight, not just the presentation.

## An integrated server puts remote players at the same table

The other half of MapTool's purpose is remote play. The documentation stresses that none of this is limited to a single PC, and that you can use the integrated server function to connect to players wherever there is an Internet connection.

The structure implied by the source tree is worth noting: a clientserver module and a common module alongside the core application, plus a dicelib module that is separated from the rest. Dice rolling is pulled out into its own library, which is the kind of boundary that lets a table swap or extend the roller without touching the map code.

The project also ships a maptool.tpproj file at the root, which is MapTool's own project format, and a messages module that carries the user interface strings.

Those strings are translated through Crowdin. The repository carries a crowdin.yml file and a Crowdin badge pointing at the MapTool project on crowdin.com, so localisation is handled as a community contribution flow rather than by a core team writing every locale by hand. This is the pattern to expect for a long-lived open source desktop application with an international user base, and it also means new strings land in the English source first and get translated afterwards.

The documentation frames the feature with a joke about a friend in Singapore, but the underlying point is that a remote player needs nothing but an Internet connection and a copy of the client, which is a much lower barrier than setting up a shared virtual machine or screen share.

## Getting the application: stable releases, pre-releases and nightly builds

MapTool is available for Windows, Mac OS X and Linux, and the documentation states that the installers for each platform are self contained and include everything needed to run MapTool. There is no separate runtime to install first, which matters for a Java application that historically asked users to track down a matching JRE.

The download locations are listed in the documentation: the MapTool website at rptools.net, the latest stable release on GitHub, a filtered list of all non pre-releases, and a separate list of pre-releases. The releases page is split deliberately, and the badges at the top of the repository show the latest stable release and the latest release candidate filtered by the -rc pattern.

The version scheme follows Semantic Versioning. Development builds contain the latest features and improvements, while stable releases focus on reliability and bug fixes. Critically, the documentation says critical bug fixes and security updates are backported to both the stable and the development branches, so the stable line does not simply freeze.

The release list confirms the pattern in practice. There is a nightly build tagged nightly-20261019 dated 2026-10-19, a stable 1.18.7 dated 2026-10-09, and a 1.19.0-alpha.1 from 2026-10-05, meaning the next major line is in alpha while the current stable line is still receiving releases. The last push was on 2026-10-19, so the tree is being worked on daily.

A table that wants reliability should take a stable release; a group that wants the newest map or token features and can tolerate churn can run a nightly.

## What MapTool is not, and where another tool fits better

Two boundaries are worth stating before anyone downloads it.

The first is that MapTool is a desktop application with a server mode, not a browser game. The documentation describes installers per platform and an integrated server function, and the repository is a Gradle Java project with an IntelliJ IDEA recommendation. That architecture suits a game master running the session from a laptop with the map on a projector, and players connecting to it. It does not suit a group that wants everyone to open a URL and play, with nothing installed on their machine. For that, a browser-based virtual tabletop is the different approach: no install at all, but the map and token editing happens in the browser and the session lives on someone else's server.

The second boundary is about content portability. MapTool maps, tokens and campaign files are MapTool's own format, and the built-in game system support, hexes for GURPS or square templates for D&D 4E, is tied to this application. A group that has already standardised on a different virtual tabletop keeps its maps and workflows there, and moving means exporting and rebuilding assets.

The honest advantage MapTool holds is the combination in one program: map drawing, token state tracking, chat, initiative, dice, vision with walls and lighting, and a server for remote players. Tools that cover remote play well tend to be thinner on drawing and lighting, and tools that draw well tend to be weaker as a hosted session platform.

## Licence, branches and the contributor pipeline

The licence field on the repository says AGPL-3.0. That is a strong copyleft licence, and for a network capable application it carries obligations for anyone who modifies the program and offers it over a network. This is not legal advice, but it sits differently from the permissive licences most desktop tools use, so a group considering modification and hosting should read the LICENSE file before doing so. The repository also carries a CODE_OF_CONDUCT.md.

The default branch is develop rather than master, which matches the stated split between development builds and stable releases, and the stable lines are maintained as separate release branches so that backported fixes can land on both.

Contributing does not require being a developer. The documentation explicitly welcomes contributions from anyone interested in helping out and points to CONTRIBUTING.md for the detail, with setup instructions for a development environment in the same file.

The recommended editor is IntelliJ IDEA, and the documentation notes that opening the project folder is enough for it to detect the project as a Gradle project and get you running with minimal effort, while Eclipse and other IDEs should work. The build uses Gradle, with a gradlew and gradlew.bat wrapper at the root, a buildSrc directory and a build.gradle file, plus spotless.license.java, which indicates formatting and licence header checks are enforced in the build.

Support channels are unusually broad for a project of this size: the website, forums at forums.rptools.net, a wiki at wiki.rptools.info, a Discord server, a Reddit community, and the Crowdin translation project.

## Conclusion

MapTool suits a game master who wants one desktop program for map building, token state and a server that remote players can reach over the internet, especially for systems with heavy exploration and lighting rules. It does not suit someone who wants a hosted browser tab with no install, nor a group already standardised on a different virtual tabletop, since the map and token formats are specific to MapTool and the workflow around the GM screen assumes a dedicated machine. Before adopting it, download the stable release rather than a nightly build, check the release list for pre-releases separately, and read what the vision and blocking rules mean for your system before you invite players, because those features change how a table is run rather than just how it looks.

## FAQ

### What platforms does MapTool run on?

MapTool is available for Windows, Mac OS X and Linux. The installers for each platform are self contained and include everything needed to run the application.

### Can MapTool handle players in different countries?

Yes. The documentation describes an integrated server function that connects players wherever there is an Internet connection, and calls out the case of a friend in Singapore explicitly. Players need a copy of the client and a network connection.

### How does the MapTool vision system work for a game master?

Walls and other objects block what players can see, darkness can blind players without a light, and lights can be set on objects or tokens to illuminate as much of the map as you want. A GM can also limit a player's view to what their specific token sees.

### Should I use a MapTool stable release or a nightly build?

MapTool follows Semantic Versioning, and development builds carry the latest features while stable releases focus on reliability and bug fixes, with critical fixes and security updates backported to both branches. The releases page separates stable releases, pre-releases and nightly builds.

## Sources

- [License: AGPL-3.0](https://github.com/RPTools/maptool/blob/develop/LICENSE)
- [Project website](http://rptools.net)
- [README](https://github.com/RPTools/maptool/blob/develop/README.md)
- [Releases](https://github.com/RPTools/maptool/releases)
- [RPTools/maptool on GitHub](https://github.com/RPTools/maptool)

---

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