Card-Forge/forge: An Open Source MTG Rules Engine in Java

What Card-Forge/forge actually is, and who it is for

Forge is an unofficial rules engine for Magic: The Gathering, written in Java and released under GPL-3.0. The README is explicit that it "operates independently and is not affiliated with Wizards of the Coast." That sentence sets the boundary for everything else: this is a fan-built implementation of a card game's rules, not a licensed product.

The problem it solves is narrow but real. If you want to play Magic against an AI, run a draft or sealed pool without other people, or work through a single-player progression with an overworld map, Forge provides that without a subscription and without a server. The README lists Adventure Mode, Quest Mode, and AI formats covering Sealed, Draft, Commander and Cube. Desktop builds target Windows, Mac and Linux; there is an Android APK and an early-stage iOS path that requires building the IPA yourself.

The audience is therefore two groups that overlap less than they appear to. The first is players who want offline, single-player Magic. The second is Java developers who want a rules engine they can read and modify. The repository layout supports the second reading: forge-core, forge-game, forge-ai, forge-gui, forge-gui-desktop, forge-gui-android, forge-gui-mobile and forge-lda are separate Maven modules under one pom.xml. A rules engine that ships as a multi-module Maven build is aimed at people who might open the source, not only at people who want an installer.

How the engine is split across forge-core, forge-game and forge-ai

The module names are the architecture. forge-game holds the card and game model, forge-ai holds the computer opponent, forge-core holds shared infrastructure, and the forge-gui family holds the front ends. forge-lda is a separate module whose name suggests language or deck analysis rather than gameplay. The desktop and Android clients are not forks of each other; they are sibling modules consuming the same core, which is why the README can promise the same gameplay on both.

The data flow follows that split. A front end collects player input, the game module resolves it against card definitions and the rules, and the AI module supplies decisions for the non-human seats. Because everything is Java and the modules are Maven artifacts, the rules layer is inspectable in a way a closed client is not. If a card resolves incorrectly, the fix belongs in the game module, and the README points contributors at CONTRIBUTING.md for that workflow.

One consequence worth stating plainly: the README does not document a public API for driving the engine from outside the GUI. There is no described headless mode, no REST surface, no documented embedding interface. If you were hoping to use Forge as a rules service behind your own application, the material gives you no path for that. You would be reading the source to find one, which is a different project than the one the README describes.

Installing Forge on desktop and running a first game

The README gives two desktop sources. Stable builds come from the latest release page; development builds come from the daily-snapshots tag as a forge-gui-desktop tarball. The README advises extracting to a new folder to prevent version conflicts, and notes that previous players' data is preserved during upgrades. Java 17 or later is required.

The README does not give shell commands. It states the Java requirement and points at the releases page, so the install is a download and extract rather than a package-manager invocation. There is nothing to install from a registry and no configuration file to edit before the first launch.

On desktop, download the latest version from the GitHub releases page, or grab the forge-gui-desktop tarball from the daily-snapshots release tag if you want the development build. Extract the archive into a new folder, as the README advises. Then launch the client from inside that folder. On first start the client initializes its card database; the README does not describe how long that takes or where the data is written.

For Android the README is more specific about prerequisites than about steps. Android 11 is the minimum, with at least 6GB RAM "to run smoothly." You must enable "Install unknown apps" for Forge to initialize and update itself. The APK comes from the same daily-snapshots release tag, and on first launch Forge downloads all necessary assets itself.

The 6GB RAM floor is the detail most people will skip and then regret. It is a stated requirement, not a suggestion, and it rules out a large share of budget Android hardware.

Where Forge is the wrong tool

The clearest limitation is the one the README states first: Forge is unofficial and unaffiliated with Wizards of the Coast. Anything that depends on official sanction, official card data feeds, or a commercial relationship is out of scope by design, and no amount of engineering changes that.

The second limitation is the AI. Forge's headline single-player modes exist because the AI module can play the game. The README describes formats the AI can play but says nothing about how strong it is, how it is tuned, or how it handles unusual card interactions. A rules engine is only as correct as its card definitions, and the README does not document coverage, errata handling, or what happens when a card is not implemented. If your interest is competitive play against strong opponents, a scripted AI is not that.

The third is the missing integration surface. There is no documented API, no headless mode, and no server component in the README. Teams that want to run rules validation in CI, or build their own client on top of the engine, will find that the documented product is a GUI application. The modules are there, but the documentation for using them as a library is not.

Finally, the iOS path is early stage by the README's own label. It requires building the IPA according to the Wiki, developer mode, iOS 16 to 26, and self-signing through a tool such as Sideloadly with the device connected to a PC. That is a developer workflow, not an installation.

Forge compared with XMage and Cockatrice

The obvious comparison is XMage, another open source Java implementation of Magic. Both are Java, both are community projects, and both implement the rules rather than only the table. The practical difference is what the README emphasizes: Forge leads with single-player modes, an overworld map, and AI opponents across Sealed, Draft, Commander and Cube. XMage's documented focus is online play against other people, with a server component that players connect to.

That difference matters more than the shared language. If you want to play against humans over a network, Forge's README does mention challenging opponents online, but the modes it describes in detail are all single-player. If you want a server you can host and point clients at, that is the shape XMage takes and Forge does not.

Cockatrice is the other common reference point, and it sits at a different layer entirely: it is a tabletop client where players enforce the rules themselves. Forge's premise is the opposite, that the engine enforces them. Choosing between the two is really choosing whether you want a referee or a table.

Maintenance cadence, licence and the cost of staying current

The repository is not archived, and the last push was on 2026-09-15, the day before this was written. That is a live project by any measure. The release history shows a stable line moving roughly every two months, with forge-2.0.13 on 2026-06-22 and forge-2.0.14 on 2026-08-08, plus a daily-snapshots tag for development builds.

That cadence defines the upgrade cost. Daily snapshots exist precisely because the stable releases lag the card pool, and the README warns that snapshots should be extracted to a new folder to prevent version conflicts. Players who want current cards are on the snapshot track and therefore on a rolling upgrade, without the README documenting a rollback procedure. That is a real gap: the README says data is preserved during upgrades but does not say what happens if a snapshot breaks your install.

The licence is GPL-3.0, and the README links to the LICENSE file. The practical implication is the usual copyleft one: if you distribute a modified Forge, the source of your modifications has to travel with it under the same terms. Running it locally, or contributing patches back through CONTRIBUTING.md, raises no such question. This is a description of what the licence identifier means, not legal advice; the LICENSE file is the authority.

Contributors are pointed at CONTRIBUTING.md, and the README lists a test-build GitHub Actions workflow, so there is a CI gate on pull requests. Nothing in the README describes a release schedule commitment, a support window, or a deprecation policy for older versions.

Editorial conclusion

Adopt Forge if you want a Java rules engine you can read, extend and run offline across desktop and Android, and if you accept that the AI opponent is the point rather than online matchmaking. Do not adopt it if you need a hosted rules service, a documented API surface, or a tournament-grade judge. Before committing, verify three things: that Java 17 or later is available on the target machine, that the Android device meets the stated Android 11 and 6GB RAM floor, and that the card set you care about is covered by the card definitions in the forge-game module.

Frequently asked questions

Official sources

1. Card-Forge/forge on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases