Azgaar's Fantasy Map Generator: procedural worlds in the browser, without AI

Who Azgaar's Fantasy Map Generator is actually for

The README states the target audience in one line: fantasy writers, game masters, and cartographers who want to create and edit fantasy maps. That is narrower than the marketing around map tools usually suggests. The output is a vector world with named states, cultures, religions, rivers, biomes and settlements, not a painted illustration. If your campaign notes need a coastline that stays consistent between sessions, that is the value here. If you need a poster to hang on a wall, you will spend more time in a vector editor afterward than you saved.

The project is a web application first. The homepage is azgaar.github.io/Fantasy-Map-Generator, and the README points to the project wiki for guidance and to a dev board for development tracking. There is no server component to run for normal use, which matters for the adoption decision: nothing to host, nothing to patch, no database to back up. Your world lives in a .map file you download.

The repository topics list cartography, dungeons-and-dragons, fantasy-maps and procedural-generation. That combination explains most of the design choices. Procedural generation gives you a plausible starting continent in seconds; the editing layer is what you use for the next twenty hours.

How the generator works: settings, generators, world data, renderer

The README describes the intended architecture as four layers: world data and styles as state, generators as model, editors as controllers, and renderers as view. It gives the flow explicitly. Settings feed generators, generators produce world data, and the renderer draws it. Interactive editing follows a parallel path: UI to editors, editors mutate world data, renderer draws the result.

The constraints attached to that split are the interesting part. The data layer is supposed to contain no logic and no rendering code. The renderer is supposed to be a pure visualization step that does not modify world data. Editors are described as controlled mutations of world state, and the README calls them interactive generators. That is a clean mental model, and it also tells you where bugs will cluster: anything that mutates the world outside an editor breaks the contract.

The README is candid that this is a target rather than a finished state. It says the codebase is messy, that it is gradually transitioning from vanilla JavaScript to TypeScript, and that compatibility with the existing generation pipeline and old .map user files has to be maintained. So when you read the four-layer description, treat it as the direction of travel, not a description of every file in src today.

Rendering is SVG or WebGL according to the README, which is why very large maps get slow. The wiki has a performance tips page for that, and the README links to it directly for performance problems.

Installing the desktop app and generating a first map

The fastest path needs no install at all. Open azgaar.github.io/Fantasy-Map-Generator in a browser and the generator runs client side. The README does not document a first-run tutorial beyond pointing at the wiki, so the sequence below is the one the interface implies: generate, inspect, save.

If you prefer a local application, the README says installers for Linux, Windows and macOS are attached to each release on the GitHub releases page. Download the installer for your platform from the release that matches the version you want, and note that the repository package.json currently reports version 1.153.1.

Nix users have a second route. The README gives this exact command, which builds the same app from the flake:

nix run github:Azgaar/Fantasy-Map-Generator

Running it fetches the flake and launches the application without a separate install step.

For self-hosting, the repository ships a Dockerfile that builds the app with npm and serves the result through nginx. It installs dependencies with npm ci, sets NETLIFY=true for the build, and copies the output into /usr/share/nginx/html:

FROM node:24-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY ./src ./src
COPY ./public ./public
COPY tsconfig.json .
COPY vite.config.ts .
ENV NETLIFY=true
RUN npm run build
FROM nginx:stable-alpine
COPY --from=builder /app/dist /usr/share/nginx/html
COPY .docker/default.conf /etc/nginx/conf.d/default.conf

Because the final stage is nginx:stable-alpine, the container serves static files only. There is no application server to configure and no environment variable to set at runtime beyond what the build already baked in.

For local development from source, package.json defines the usual scripts. The dev script starts Vite, and the build script runs tsc, then vite build, then a PWA precache step:

npm install
npm run dev

After npm run dev, Vite prints a local URL; opening it gives you the same generator the hosted site runs. The repository also defines npm test for vitest and npm run test:e2e for Playwright, so a change to a generator can be checked before you file anything upstream.

The .map file is the real product, and the compatibility burden is real

Every design decision in this project circles back to the saved .map file. The README explicitly commits to maintaining compatibility with old .map user files while the codebase moves to TypeScript. That is an unusual promise for a hobby-scale web app, and it is the strongest argument for using it: a world you made years ago is supposed to still open.

It also constrains what maintainers can change. A generator that produces slightly different terrain from the same seed is easy to ship when nobody has saved output; here it risks invalidating the geography people have already written novels around. The README's bug report form asks for an affected .map file in a ZIP archive when relevant, which confirms that saved worlds are treated as first-class artifacts rather than disposable exports.

The practical consequence for you: save early, save often, and keep the version number alongside the file. The release history shows frequent point releases, and the project's own reporting guidance asks for your FMG version when you file a bug. If a map breaks, that version string is what makes the report actionable.

There is a limit to what the README promises. It says compatibility is maintained; it does not describe a rollback path if a new version opens an old file badly. If that risk matters, keep copies of the .map file rather than relying on the application to preserve earlier states.

Where Azgaar's Fantasy Map Generator is the wrong tool

The generator is procedural. The README describes terrain and world simulation driven by settings and generators, and the related searches that mention AI are asking about something the project does not claim to be. There is no text prompt field described anywhere in the README, and no image input either. If your requirement is "type a paragraph, get a painted map", this is the wrong project, and no amount of fiddling with settings will turn it into that.

Performance is the second boundary. The wiki has a page titled for poor map performance, and the README links to it as the first thing to check when the map is slow. Rendering to SVG or WebGL means large, dense worlds cost real browser time. If you want a continent with thousands of named settlements, expect the editor to feel heavy on modest hardware. The project's answer is a tips page, not a streaming renderer.

The third boundary is the codebase itself. The README says the codebase is messy and asks contributors to start with minor changes. That is honest, and it should inform your expectations if you plan to fork and maintain a custom variant. Reading the data model wiki page before touching anything is the README's own advice, and it is not optional if you intend to keep your fork mergeable.

Alternatives and how their approach differs

The clearest alternative is writing your own generator on top of the polygon map generation technique the README cites as inspiration, specifically Amit Patel's polygonal map generation write-up and Martin O'Leary's notes on generating fantasy maps. That route gives you complete control over the data model and no compatibility burden with anyone else's saved files, at the cost of building the editing interface, the renderer and the file format yourself. Azgaar's project is essentially that work already done, plus a large interactive editor layer.

A second comparison is a general vector illustration tool used by hand. That gives you exactly the coastline you draw and no generation at all. The trade-off is inverted: total control, no procedural consistency. In Azgaar's tool, the generator guarantees that rivers flow downhill and biomes follow climate rules, and you edit within those constraints instead of inventing them.

For the specific question of getting a map from an existing image, the README does not describe any import of that kind, so do not choose this project expecting one. The repository's own contribution guidance points contributors at the data model wiki page, which is the closest thing to a specification, and it is written for people extending the generator rather than for people converting artwork.

Licence, maintenance and the cost of staying current

package.json declares the licence as MIT, while the repository metadata reports NOASSERTION. Those two do not agree, and anyone embedding this in a product should read the LICENSE file in the repository root rather than trust either label. This is a factual discrepancy in the repository, not a legal opinion, and it is the kind of thing worth resolving before you ship a derivative.

Maintenance looks continuous. The last push was on 2026-09-22, and the recent releases run from v1.150.0 on 2026-09-01 through 1.153.1 on 2026-09-16, with point releases in between. The repository is not archived. That cadence has a cost for anyone who self-hosts: the Dockerfile builds from whatever is in the working tree, so pinning to a release tag rather than tracking master is the only way to keep a deployment reproducible.

Upgrade cost is mostly about the .map format and the TypeScript migration. The README states that compatibility with old .map user files is maintained during the transition, which lowers the risk of opening an old world in a new build. It does not promise that every editor operation behaves identically across versions, and it does not document a downgrade path. If you run a long campaign, keep the application version you generated a world with, and test a new release against a copy of the file before switching.

Editorial conclusion

Adopt it if you need a world you can edit cell by cell and keep as a .map file you own, and you accept that the visual style is vector cartography rather than painted art. Skip it if your workflow starts from a text prompt or a reference image, because the generator is procedural and the README never describes image input. Before committing a long campaign to it, generate a map, save the .map file, reload it, and check the performance tips in the wiki if the editor starts to lag.

Frequently asked questions

Official sources

1. Azgaar/Fantasy-Map-Generator on GitHub
2. Issues
3. Project website
4. README
5. Releases