vassal: the open-source engine behind online board game adaptations

An engine, and the modules that turn it into games

VASSAL is described as a game engine for building and playing online adaptations of board games and card games, with the tagline being the open-source boardgame engine. It is free, open-source software that runs on all platforms.

The framing as an engine rather than a game is the single most important fact about it. What VASSAL provides is the client, the networking and the game session machinery. What a player actually launches is a module, a piece of content that describes a particular board game, its pieces, its rules and its interface. The repository is the engine; the games live elsewhere, built by their own authors, usually as community projects.

That division has consequences for anyone evaluating it. If a game you care about has a module, VASSAL is a solved problem: you install the engine, you import the module, you play. If it does not, you are looking at a tool that needs a substantial content project before it does anything for you, and the cost of that project is measured in months of work by someone who knows the module format.

The play model is what distinguishes it from a generic virtual tabletop. The README says you can play live on the Internet or by email. Live means a shared session with real time interaction. By email means the game is played by sending turns back and forth, which is the classic way to play a board game with an opponent in another country when real time is not available, and it is a mode many modern platforms have quietly dropped.

The audience is therefore two-sided: game designers who want to publish an online version of their game, and players who want an opponent across the world.

Java 17 is the floor, and the packaged builds hide it

The Minimum Requirements section is short, and it depends on which package you took.

VASSAL 3.7.25 requires Java 17 or later. For Linux, the instruction is to use your package manager to install Java 17 or later, which is an ordinary dependency for a Linux user who already has a JDK, and a slightly bigger ask for one who does not.

For Windows and Mac, the README is more helpful. The packages have an appropriate version of Java bundled with them, so there is no need to install Java separately on those operating systems. That is a deliberate choice for an application whose users are board game players rather than developers, and it is the difference between a two-click install and a support request.

There is one exception, and the README points at it: Mac users on Catalina, macOS 10.13, or earlier are sent to a forum thread, because a Java 17 runtime cannot simply be bundled for those older systems. Any platform support statement has an asterisk somewhere, and here it is.

The release route is equally simple. You get the current release from the releases page and read the release notes to see what is new, with the notes kept on the project wiki rather than in the repository. The forum is where the project lives socially, with a Technical Support and Bugs section for reports.

For developers, the README points at the Developer's guide in the repository at developers-guide/developers-guide.adoc, written in AsciiDoc.

The Makefile shows what a release actually costs

The repository root has a Makefile, and its opening comment is the most honest summary of what packaging a release involves: it is intended for use on Linux systems, and if you are trying to use it elsewhere you are on your own.

The toolchain it names is substantial. Windows releases need Launch4j and NSIS, and possibly mingw32 for Launch4j depending on your architecture. If your Linux distribution does not package NSIS you can build it, and the Makefile gives the scons invocation for the compiler:

scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all \
      NSIS_CONFIG_CONST_DATA_PATH=no PREFIX=/path/to/extracted/zip \
      install-compiler

Then there is the icon work. The Windows ICO file needs librsvg2, ImageMagick and GIMP, and the Apple ICNS file needs librsvg2 and png2icns. Mac and Windows packages need JDKs for jlink to use during packaging, with genisoimage and dmg from libdmg-hfsplus additionally needed for Macs. And producing the release announcements from the templates needs jinja2 and jinja2-cli.

The Makefile also carries the version plumbing, with a numeric version variable set to 3.8.0 and a derived major-minor value, which is how a project keeps the package names and the announcements in step with the source.

The last instruction is the most concise summary of the whole release process: run bootstrap.sh to download the appropriate JDKs and download and compile dmg.

None of this is unusual for a project that ships installers for three desktop platforms, but it does mean the barrier to producing a release is higher than the barrier to building the code, which is a Maven build.

Maven for the code, scripts for the installers

The build system behind the code is Maven, and the repository carries the wrapper scripts mvnw and mvnw.cmd along with a .mvn/ directory, so a contributor does not need Maven installed. The root pom.xml is the project descriptor, and the Makefile sits alongside it as the packaging layer.

The source layout is modular, and the directory names describe the parts of the product. vassal-app/ is the application itself, and its resources even carry the application icon under a scalable icons folder. vassal-deprecation/ presumably holds code kept for compatibility with older content, and vassal-doc/ holds documentation. developers-guide/ holds the guide the README points at, in AsciiDoc. release-prepare/ holds the tooling that assembles a release, and the Makefile references paths inside it for the library and documentation output. dist/ is where distributions are assembled, and debian/ holds Debian packaging.

Two smaller files describe how the project is run rather than built. CHANGES is the changelog, and crowdin.yml configures Crowdin, which is how a project with contributors in many languages handles translation. A game engine with a community of module authors needs its own interface translated, and a translation platform in the repository root is the sign of that work being taken seriously.

There is a .github/ directory for the workflows and the package.yml workflow that the build status badge points at, so the release packaging is at least partly automated even though the Makefile is manual.

Getting a module, and the difference between a player and a designer

For a player the workflow is short. Install the engine, take a module, open it, and either connect to a live session or play by email. Nothing in the README requires a build, a JDK or a compiler, because the packaged Windows and Mac builds carry their own Java.

For a designer it is a different project entirely. The engine has to be extended with content that describes the game, and the Developer's guide is the entry point. The guide lives in the repository as an AsciiDoc file, and the forum carries the Technical Support and Bugs section, which is where bug reports are expected to go rather than the issue tracker.

That distinction is the honest limit of the project, and it is a limit of the design rather than a gap in the implementation. VASSAL solves the hard infrastructure problem once, so that a designer can concentrate on the game. But the engine cannot invent a game, and a game that has no module is invisible to the community that the engine serves.

It also shapes the comparison with the alternative. Writing a bespoke online version of a board game means building the client, the server, the state synchronisation, the disconnection handling, the rules enforcement and the interface, and then supporting every platform your players use. Adopting VASSAL means you write the rules and the interface and inherit all of the rest, at the price of working inside a module format and a Java application rather than shipping a web app.

For a game that is a variation on a familiar format, and for a community that wants to play by email, that trade is usually worth it. For a game that needs a modern web experience, it often is not.

A patch line and a beta running in parallel

The release history shows the two-track pattern that a long-lived application tends to settle into.

On the stable line, 3.7.28 is dated 2026-10-02 and 3.7.29 on 2026-10-03, releases a day apart. On the development line, 3.8.0-beta2 is dated 2026-09-13. The last push to the repository was on 2026-10-19.

The version numbers in the Makefile line up with that, since the numeric version variable is set to 3.8.0 while the 3.7 patch line is still being published, and the Makefile carries a commented alternative form of the Maven version for the beta case.

Two patch releases a day apart is worth a second look, because it suggests fixes landing quickly after something changes, most likely in the 3.8 work feeding back into 3.7. For a player, that means the stable download is fresh rather than stale. For a module author, it means testing against a moving 3.7 line and a moving 3.8 beta at the same time.

The documentation model is also worth noting. The release notes live on the project wiki, the Developer's guide lives in the repository, and the forum hosts support. There is no single documentation site that describes the module format, the API and the release history in one place, which means a module author is reading three different sources and keeping them mentally consistent.

LGPLv2, and what it means for the code you write on top

VASSAL is licensed under the LGPLv2, with a LICENSE file at the root of the repository, and the README states that the project is licensed under the terms of the LGPLv2 license.

That licence choice is the correct fit for this kind of project. LGPL is the weak copyleft variant designed for libraries: if you use VASSAL through its interfaces, your own module code does not have to be released under the same terms, which is what a module author needs, while modifications to the engine itself do carry obligations.

This is not legal advice, and the terms in the LICENSE file are what govern. The practical point for a designer is that the module is your work and the engine is a shared dependency, which is a much friendlier arrangement than a strong copyleft engine would be.

The acknowledgments section names YourKit as a supporter, described as supporting open source projects with tools for monitoring and profiling Java and .NET applications, and the project is listed among the open source projects it supports along with the YourKit Java Profiler, the .NET Profiler and YouMonitor. A commercial profiler vendor sponsoring a hobbyist project is a common arrangement in the Java ecosystem.

For a player, none of this matters. For a designer shipping a module, it matters a great deal, and the answer is that the module stays yours.

Editorial conclusion

VASSAL suits board game designers who want their game playable by people on different operating systems without writing a client, a server and a networking layer, and it suits players who want an offline opponent for a game that otherwise needs a table. It does not suit a designer who wants a modern web-native product, since the engine is a desktop application that Java drives, and it does not suit someone who needs to ship a closed source game without reading the LGPL obligations that come with linking to it. Check three things before you commit: that a module exists or is planned for your game, since without one the engine gives you nothing, that your target players can install Java 17 or later or use a bundled package, and that the packaging expectations are acceptable, because the Makefile shows a release needs Launch4j, NSIS, jlink and a set of image tools. The last push to the repository was on 2026-10-19 and the newest 3.7 release is 3.7.29 from 2026-10-03.

Frequently asked questions

Official sources

1. License: LGPL-2.1
2. Project website
3. README
4. Releases
5. vassalengine/vassal on GitHub