I Shipped a Rust + WebAssembly Battle Map Editor to the Microsoft Store

I recently shipped RPG Map Editor to the Microsoft Store.

It is a battle map editor for D&D, Pathfinder, and other tabletop RPGs. The goal is simple:

Help a game master create a usable encounter map faster, without needing Photoshop, a heavy VTT workflow, or a complex desktop-only toolchain.

The project is available here:

Website: https://www.rpgmapeditor.com
Microsoft Store: https://apps.microsoft.com/detail/9mzc3cfjkrs2

This post is not a victory lap. It is a build log about what changed, what I learned from early feedback, and what I am trying to validate next.

What RPG Map Editor Is

RPG Map Editor is a map-making tool focused on fast tabletop preparation.

The current workflow is:

Open the editor
Paint terrain
Place props and objects
Align the tactical grid
Export a PNG map
Use it in a VTT, print it, or share it with players

The product is browser-first, but I also wanted a Windows version for users who prefer installing tools from a trusted store.

That is why I packaged and released it through the Microsoft Store.

Why Build Another RPG Map Editor?

There are already strong tools in this space:

Inkarnate
Dungeondraft
DungeonFog
Dungeon Alchemist
Dungeon Scrawl
Campaign Cartographer

So the question is obvious:

What does this offer that those tools do not?

The current answer is not “more features.”

The current bet is lower friction.

Some game masters do not want to install a large desktop app, manage asset packs, learn a complex workflow, or spend an hour preparing one simple encounter map.

The product direction is:

fast startup
simple terrain painting
direct prop placement
clear grid controls
browser and Windows availability
quick export
minimal setup

For power users who already have a strong Dungeondraft + Foundry workflow, RPG Map Editor is not trying to replace that yet.

That matters because advanced VTT workflows need more than a PNG.

The Honest Limitation: PNG Export Is Not Enough for Everyone

One of the strongest pieces of early feedback was about Foundry VTT.

A plain PNG export is useful, but it does not replace a full VTT scene export with:

walls
doors
lighting
line-of-sight data
scene metadata

That is a real limitation.

Right now, RPG Map Editor is focused on creating and exporting playable map images. Native Foundry scene export and automatic walls/doors are not shipped yet.

I would rather say that clearly than pretend the product already replaces mature workflows.

For many users, PNG export is enough.

For serious Foundry users, it probably is not.

That gives me a clear product constraint to test next.

Why Rust + WebAssembly?

The editor uses a Rust + WebAssembly core because I wanted the map engine to be structured more like a real editor engine than a typical DOM-heavy web app.

The browser is the distribution layer.

Rust/WASM is the performance and state-management layer.

The long-term direction is:

Rust owns the map state
WebAssembly handles editor operations
WebGL/WebGPU-style rendering handles the canvas
TypeScript/React handles UI and shell logic
the product remains usable from the browser

This creates more complexity upfront, but it gives better control over editor behavior later.

For a creative tool, that matters.

Why Microsoft Store?

The Microsoft Store release is mainly a distribution experiment.

A browser app is easy to try, but a Store app gives the project another trust surface:

users can find it through Windows search and Store discovery
installation feels more native
the product appears more legitimate to non-technical users
desktop users can keep it like a normal app
it creates a clearer “released product” milestone

This does not automatically mean the product is validated.

A Store listing is not traction.

A launch is not retention.

The real question is whether users install it, open it, create a map, export it, and come back.

What I Am Testing Now

The current validation question is not:

Can I build a better editor than Inkarnate?

That is too broad.

The current validation question is:

Can a GM open RPG Map Editor and create/export a usable battle map without getting stuck?

That breaks into measurable steps:

Did users find the product?
Did they understand what it does within 5 seconds?
Did they open the editor?
Did they create or edit a map?
Did they export it?
Did they use it in a real session?
Did they return?
Would they pay?

Everything else is secondary.

What I Changed After Early Feedback

Early community feedback made a few things clear.

First, the product positioning needed to be more direct.

Saying “browser-first RPG map editor” is not enough. People need to immediately understand the practical value:

Create a playable battle map quickly.

Second, I needed to be clear about the limits.

If Foundry users expect walls, doors, and lighting export, I should not hide behind vague “VTT-ready” language. PNG export is useful, but it is not the same as native VTT scene export.

Third, readability matters.

A nice-looking page is useless if contrast issues make it hard to read. This is especially important for a creative tool where users need to trust the UI before they even enter the editor.

Fourth, the fastest path to validation is not more marketing content.

It is getting users into the editor and watching where they fail.