MineMonopoly: a Monopoly game where the map is code you write

The map is the product, not the board

MineMonopoly is a multiplayer online Monopoly game that supports custom maps, with a fully featured map editor built in. The description is that the drag-and-drop visual interface lets you draw the board freely, configure tiles and write event logic, using TypeScript or JavaScript for custom gameplay, so every map is unique. The interesting part is the scope of what the editor covers, which is wider than a tile painter. Characters with their own skills and attributes, chance cards with programmable effects, map events with trigger conditions and rewards or penalties, and game phases that define the turn structure are all configurable. The chance card system in particular is the part that distinguishes this from a Monopoly clone, since a card whose effect is code rather than a fixed rule is a different object model from the standard deck. The editor also has a declarative UI schema system, which is what lets a map author change how an in-game screen looks without touching the client. The result is that the content of the game is written by whoever makes the map, not by the people who wrote the engine, which is the same division of labour a modding-friendly game has.

An MCP service puts AI inside the editor

The editor ships with an MCP service that supports AI-assisted editing, and the described workflow is that you describe the game content you want in natural language and the AI generates the corresponding character, card, event or modifier code, which passes TypeScript type checking and is then written directly into the map. The stated effect is a large reduction in the barrier to custom gameplay, and the mechanism that makes it safe rather than sloppy is the type check, since the generated code has to satisfy the same types as hand written code before it lands. The AI agent can also generate content in bulk through structured tools rather than one file at a time. This is a different use of an agent from the usual one, and it is worth being clear about the direction of the work: the agent is not playing the game, it is authoring the content the game will later run, and the human is reviewing the output in a visual editor before it is committed. The MCP service lives in the map-editor application rather than in the client, which keeps the generation tooling with the tool that has the map format loaded.

Hybrid P2P, with a worker for the game loop

The runtime uses a hybrid peer-to-peer design. The central server handles authentication and room routing, the game logic runs independently in a Web Worker on the host client, and players connect directly to each other over WebRTC through PeerJS, which the README says keeps latency lower. A coturn TURN and STUN relay is included to guarantee connectivity in complicated network environments, which is the part that makes the design workable rather than theoretical, since a browser-to-browser connection often has to be relayed. The architecture diagram shows the same split in the client, with a Vue 3 interface on one side and the GameProcessWorker on the other, communicating with each other, while the client talks to the server over Socket.io and to the TURN server over ICE. The server itself is Express with TypeORM against MySQL 8.0, and it stores the authentication, the rooms and the maps, while the game state between players travels over the peer channel. Running the simulation in a worker is the detail that makes the client usable, since a turn-based game with many entities would otherwise block the interface thread on every tick.

A pnpm workspace with four applications

The repository is a pnpm workspace with Changesets for versioning, and the directory layout is the clearest description of the project. The apps/ directory holds the game client as Vue 3 plus Electron, the game server as Express plus TypeORM plus MySQL, an admin back office, and the map editor as Electron with the MCP service. The packages/ directory holds the shared code, with a types package for shared type definitions, an env package for environment variable management, a utils package for shared utilities and protobuf, a components package for shared Vue components, and a style package for shared SCSS. Then there is a docker/ directory for deployment, a docs/ directory, and a conf/ directory holding the MySQL configuration. The tooling table is also specific: Vue 3, TypeScript, Vite and Pinia on the front end, Three.js with GSAP for 3D and 2D rendering and animation, Electron for the desktop shell, PeerJS with coturn for peer communication, Protocol Buffers for map data encoding, and pnpm workspaces with Changesets for dependency and version management. The client is also available as a native Electron application for Windows with automatic updates, and mobile is listed as in development.

Setting up a development environment

The requirements are Node.js 20 or newer, pnpm 10.10.0 or newer and MySQL 8.0 or newer, and the install is a clone, a dependency install and an environment file.

git clone https://github.com/FatPaper-1874/mine-monopoly.git
cd mine-monopoly
pnpm install
cp .env.example .env

The four development commands start the client, which listens on port 5173, the server, the editor and the admin back office. The build scripts build the client, the editor and the server, and the outputs land in the dist directory of each application. Type checking is also split, with a full check covering the client and the editor and separate checks for each, which is a reasonable division given the editor is the larger surface. The root package.json also carries the Docker commands, with an up target that runs the compose file in the docker directory, a build target and an export target that saves the server image and compresses it, which is a convenience for deploying the server without a registry. The versioning is per application rather than for the whole repository, with the release tags named for the component and the version, so a client release and a map-editor release are tracked separately and the two can move at different rates.

The environment file is where the operational reality lives

The configuration is extensive enough to be worth reading as a description of the deployment. There are general variables, with the runtime environment, the server domain and the protocol, and a set of path prefixes for nginx reverse proxying, where the API prefix is used on its own and the ICE and admin prefixes follow it when left empty, so a deployment behind a single host path needs one variable and a port-based deployment needs none. The service ports default to 81 for the main server, 82 for ICE signalling and 83 for the admin back office. The database is MySQL with a host, port, name, user and password, plus optional connection pool settings. The WebRTC section carries the TURN secret and TTL, the TURN URL and port, the STUN port, and a URL for coturn Prometheus metrics. Optional cloud storage covers Tencent Cloud COS with a secret id, a secret key, a bucket and a region, and without it files are stored in the local public directory of the server. There are separate paths for avatar uploads and for game maps, and a sixteen character ASCII key for encrypting map artefact files, which is the piece with a real security consequence, since it is what protects the map content at rest and it is checked into an example file with a placeholder value.

Where MineMonopoly is the wrong choice

The first limit is that a game whose selling point is a programmable map is a project for people who want to run their own private game, not a consumer product. Setting it up needs a Node and MySQL deployment, a coturn relay for peers behind restrictive networks, and the map editor to author content, and the peer-to-peer design means the quality of the session depends on the network path between players rather than on your server. The second is the licence and the documentation language. The project is GPL-3.0, which is fine for a self-hosted community game and a problem for a company that wanted to embed it, and the README and the environment documentation are in Chinese, so an English-only team is working from a translated reference and the code itself. The third is that the map file format is a coupling point. The map is written in TypeScript and encoded with Protocol Buffers, and the client, the editor and the server all have to agree on it, so a version mismatch between the editor and the client is a class of bug the project structure makes possible. The fourth is that the interesting content, the characters, the cards and the events, is authored by users, so a fresh install is an empty board and the game's quality is a community problem rather than a code problem. And the fifth is the security setting. The map encryption key is a fixed sixteen character ASCII string in the configuration, which is a scheme for keeping map files from being trivially readable rather than a defence against a determined attacker.

Editorial conclusion

Adopt MineMonopoly if you want to run a private Monopoly-style game with rules you control down to the event logic, and you are comfortable running a Node and MySQL stack plus a TURN relay. Skip it if you want a finished commercial board game, since this is a self-hosted project with a GPL-3.0 licence and a Chinese-language documentation set. Verify first that the editor can express the mechanics you need, that you can host coturn for peers behind restrictive networks, and that the map file format stays stable across client and editor upgrades.

Frequently asked questions

Official sources

1. FatPaper-1874/mine-monopoly on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases