DEV Community: TheXper

Dungeon Scrawl vs RPGMapEditor.com: Which Browser Map Tool Fits Your Game?

TheXper — Tue, 02 Jun 2026 13:22:47 +0000

When you are preparing a tabletop RPG session, the real question is not which map tool is objectively better.

The better question is:

Which tool gets this specific session map finished with the least friction?

Dungeon Scrawl and RPGMapEditor.com can both fit browser-based map prep, but they are optimized for different jobs.

Dungeon Scrawl is strong when you want fast dungeon layouts, old-school map readability, and a low-friction sketching workflow.

RPGMapEditor.com is aimed at browser-based visual encounter maps: terrain painting, stamps, props, grids, saved projects, and PNG export for VTT use.

This comparison is not a takedown. It is a workflow distinction.

Quick verdict

Use Dungeon Scrawl if your main job is:

fast room-and-corridor dungeon layouts
old-school or black-and-white dungeon maps
quick sketching before a session
minimal setup
clean floor plans

Use RPGMapEditor.com if your main job is:

visual fantasy encounter maps
terrain painting
prop and stamp placement
tactical grid setup
saving maps to an account
exporting a PNG for Roll20, Foundry, Owlbear Rodeo, or another VTT

Neither tool has to win every use case.

The practical test is whether you can make a playable map faster.

The map-prep difference

Dungeon Scrawl feels like a fast dungeon sketching tool.

That is useful when the output you need is a readable dungeon structure: rooms, corridors, doors, shapes, and a clean tabletop layout.

RPGMapEditor.com is trying to solve a different workflow.

It is more focused on building a visual battle map directly in the browser. The goal is to paint readable terrain, place objects, tune the grid, save the project, and export a usable table image.

That makes it more relevant when the map is not just a floor plan, but a scene: a forest ambush, a ruined shrine, a cave entrance, a tavern basement, or a tactical encounter location.

Comparison table

Job	Dungeon Scrawl	RPGMapEditor.com
Fast dungeon sketching	Strong fit	Possible, but not the main focus
Old-school dungeon style	Strong fit	Partial fit
Visual encounter prep	Less direct	Main focus
Terrain painting	Not the primary workflow	Core workflow
Stamps / props	Useful depending on workflow	Core workflow
Browser access	Yes	Yes
Account-backed saved maps	Check current product state	Yes
PNG export	Check current export options	Yes
Roll20 / Foundry workflow	Check current integrations	Export PNG, upload to VTT, align grid
Walls / doors / lighting export	Verify current support	Not currently shipped

Critical note: export features change over time. Before switching your campaign workflow, verify the current export, pricing, and licensing details on each product page.

VTT workflow

For RPGMapEditor.com, the reliable workflow is image-based:

Create the map in the browser.
Export it as a PNG.
Upload the image to your VTT.
Align the grid.
Add walls, doors, fog, and lighting inside the VTT if needed.

That means RPGMapEditor.com is usable for Roll20 or Foundry through PNG export, but it should not be treated as a direct Foundry scene exporter or Roll20 automation tool unless those features are explicitly shipped.

That distinction matters.

A PNG export is enough for many tables. But if your campaign depends on automated walls, doors, lighting, or scene JSON, you should verify that before committing.

The 10-minute test

The fastest way to choose between these tools is to test the same real map in both.

Use this brief:

Create a small dungeon entrance map:
- one entrance area
- three connected rooms
- one hazard
- one hidden or reveal area
- tactical grid
- export for VTT use

Then measure:

Time from blank canvas to playable map
How many UI decisions slowed you down
How readable the exported map is
How easy the VTT import is
Whether you would reuse the project later

This test is better than comparing feature lists.

A feature list tells you what a tool can theoretically do. A session-prep test tells you whether it helps you run the game.

Choose Dungeon Scrawl if...

Choose Dungeon Scrawl if you mainly need a fast dungeon floor plan.

It is the more natural choice when your output is a clean old-school dungeon sketch and you do not need a more visual terrain-and-prop editing workflow.

This is especially true if your prep style is:

draw the layout quickly
export it
run the session
move on

For many GMs, that is exactly enough.

Choose RPGMapEditor.com if...

Choose RPGMapEditor.com if you want a browser-based RPG map editor for visual encounter prep.

It is a better fit when you care about:

terrain readability
fantasy battle map scenes
tactical grids
props and stamps
saved map projects
PNG export
building maps directly in the browser without installing a native app

It is not a one-to-one Dungeon Scrawl clone.

The better framing is: RPGMapEditor.com is for GMs who want a visual browser-based battle map workflow, not just a fast dungeon sketch.

Does RPGMapEditor.com replace Dungeon Scrawl?

Not one-to-one.

Dungeon Scrawl is strong for quick dungeon scrawls and old-school layouts.

RPGMapEditor.com is more useful when you want browser-based visual map editing for fantasy encounters, saved projects, and PNG handoff to a VTT.

A GM could reasonably use both:

Dungeon Scrawl for fast dungeon structure
RPGMapEditor.com for visual encounter scenes

The right tool depends on the map job.

FAQ

Is RPGMapEditor.com a Dungeon Scrawl alternative?

Yes, for some workflows. It is an alternative if you want browser-based RPG map editing with terrain, stamps, tactical grids, saved maps, and PNG export. It is not a perfect replacement for Dungeon Scrawl's fast dungeon-sketching feel.

Can I use RPGMapEditor.com with Roll20 or Foundry?

Yes, through PNG export. Export the image, upload it to your VTT, align the grid, then configure platform-specific walls, doors, fog, or lighting inside the VTT.

Is RPGMapEditor.com an old-school map maker?

Only partly. It can be used for dungeon and fantasy encounter layouts, but it is not positioned as a pure black-and-white old-school dungeon sketching tool.

Which one should I try first?

Try the tool that matches your next session map.

If you need a clean dungeon floor plan quickly, start with Dungeon Scrawl.

If you need a visual battle map with terrain, props, a grid, saves, and PNG export, try RPGMapEditor.com.

Final recommendation

Do not choose based on the longest feature list.

Choose based on the shortest path from:

blank canvas → playable map → exported file → table-ready VTT scene

That is the workflow that matters on game night.

Try the same small dungeon brief in both tools and compare the result.

RPGMapEditor.com is independent and is not affiliated with, endorsed by, or sponsored by Dungeon Scrawl, Roll20, or Foundry.

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

TheXper — Fri, 29 May 2026 09:17:01 +0000

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.

The Current Product Scope

The current version focuses on:

terrain painting
prop and object placement
tactical grid alignment
demo projects
PNG export
browser access
Windows app availability through Microsoft Store

Not yet shipped:

native Foundry scene export
automatic walls and doors
dynamic lighting metadata
advanced campaign management
full marketplace ecosystem

Those may come later.

Right now, the product needs stronger proof that the core loop works.

Links

Website:

https://www.rpgmapeditor.com
Microsoft Store:

https://apps.microsoft.com/detail/9mzc3cfjkrs2

RPGMapEditor Roadmap: Bringing a Rust-Powered DnD Map Maker to Windows

TheXper — Mon, 25 May 2026 20:30:18 +0000

RPGMapEditor is being built as a browser-based RPG map editor, DnD map maker, and battle map maker powered by Rust, WebAssembly, and WebGL.

The main product will stay web-first.

That matters because tabletop creators should be able to open a browser, create a map, save it, export it, and continue working without installing a heavy desktop tool.

But there is now a clear roadmap direction worth exploring:

Bring RPGMapEditor to Windows as a desktop app without rewriting the editor from scratch.

This is not a pivot away from the web app.

This is a distribution and workflow expansion.

The roadmap direction

The plan is simple:

Web-first RPG map editor
+
Windows desktop app
+
Local file workflows
+
Optional cloud sync
+
Microsoft Store distribution

The desktop version would not replace rpgmapeditor.com.

Instead, it would become another way to use the same editor.

Users who want instant access can use the browser version.

Users who prefer a desktop creative workflow can install the Windows app.

Why a desktop app makes sense

RPG map editors sit between two product categories:

browser tools that are fast to access
desktop creative apps that feel permanent and file-based

A browser-based RPG map editor is great for speed.

A desktop RPG map editor is better for users who expect:

local files
recent projects
direct image export
offline-friendly workflows
a dedicated app window
operating system integration

That is the opportunity.

The goal is not to build a second editor.

The goal is to make the existing editor available through a Windows desktop workflow.

Why not rewrite everything natively?

A full native rewrite would be the wrong move.

RPGMapEditor already has a Rust-powered architecture:

Rust backend
Rust/WebAssembly editor engine
WebGL rendering
browser-based UI
map persistence
export workflows

Rebuilding the same editor as a native Windows app would create duplicate work.

Every feature would need to be maintained twice.

That would slow down the product.

The better approach is to reuse the existing editor and package it properly for desktop.

Planned architecture

The intended architecture is:

RPGMapEditor Web App
├── Rust backend
├── authentication
├── cloud saves
├── account system
├── pricing
└── map persistence

RPGMapEditor Editor
├── Rust → WebAssembly engine
├── WebGL renderer
├── editor UI
├── asset workflow
└── export system

RPGMapEditor for Windows
├── desktop shell
├── bundled editor frontend
├── local .rpgmap files
├── image export
├── recent maps
└── optional cloud sync

The key rule:

The desktop app should reuse the existing editor instead of forking the product.

That keeps development focused.

The first Windows version

The first version of RPGMapEditor for Windows should be intentionally small.

The minimum useful feature set:

1. Launch the editor from a desktop app
2. Load the Rust/WASM map engine
3. Render maps correctly
4. Create a new map
5. Open a local .rpgmap file
6. Save a local .rpgmap file
7. Export PNG or WebP images
8. Sign in for optional cloud saves

That is enough for a real first version.

Not perfect.

Not overloaded.

Just useful.

What the desktop app should not become

The Windows version should not become:

a separate editor
a full native rewrite
a disconnected product
a new pricing experiment
a month-long packaging distraction
a reason to delay the web editor

The browser editor remains the core product.

The desktop version is a focused distribution layer.

Why Microsoft Store is interesting

Publishing RPGMapEditor for Windows through the Microsoft Store could create a new discovery surface for users searching for:

RPG map editor for Windows
DnD map maker for Windows
battle map maker desktop app
tabletop map editor
fantasy map creator
VTT map maker

The Microsoft Store will not magically create growth.

But it can help with:

trust
installs
reviews
Windows discovery
product credibility
desktop user acquisition

For an early creative tool, that is worth testing.

Roadmap phase 1: Desktop proof of concept

The first roadmap phase is technical validation.

The desktop app must prove that the existing editor works correctly inside a desktop shell.

Checklist:

- app opens successfully
- WASM loads
- WebGL rendering works
- editor UI works
- maps can be created
- exports work
- login flow does not break
- cloud save flow remains usable

If this fails, the desktop roadmap pauses.

There is no reason to force a desktop release if the core editor experience is unstable.

Roadmap phase 2: Local file workflow

A desktop creative tool needs file handling.

The second phase would add:

- New Map
- Open .rpgmap
- Save .rpgmap
- Save As
- Export PNG
- Export WebP
- Recent Maps

This is the real reason for a desktop app.

Without local files, the app is just a website in a window.

With local files, RPGMapEditor becomes closer to a real creative tool for tabletop creators.

Roadmap phase 3: Microsoft Store packaging

Once the desktop version works, the next step is packaging.

The Store-ready version needs:

- app icon
- app screenshots
- store description
- privacy policy
- support page
- version number
- stable installer
- clean first-run experience

The Microsoft Store listing should be clear, not keyword-stuffed.

A simple positioning line:

RPGMapEditor is a Rust-powered DnD map maker and battle map editor for Windows and the web.

Roadmap phase 4: Product-led conversion

The desktop app should be measured like a product channel.

Important events:

desktop_install
desktop_editor_open
desktop_map_created
desktop_local_save
desktop_export_clicked
desktop_cloud_sync_used
desktop_signup_started
desktop_pricing_clicked

A desktop release only matters if users actually create maps.

The goal is not installs.

The goal is map creation, saving, exporting, returning, and eventually upgrading.

Roadmap phase 5: Desktop plus cloud

The long-term product direction could become:

Browser app for instant access
+
Windows app for local workflows
+
Cloud saves for persistence
+
Premium asset packs for monetization
+
Export workflows for VTT use

That creates a stronger product system.

The web app gives speed.

The desktop app gives permanence.

Cloud sync connects both.

Who this is for

The Windows version would be useful for:

Dungeon Masters creating DnD maps
tabletop RPG players preparing encounters
worldbuilders designing fantasy maps
VTT users exporting battle maps
creators who prefer desktop tools
users who want local map files

The browser version remains the fastest way to start.

The desktop version becomes the better option for longer creative sessions.

Why this roadmap matters

Most mapmaking tools fall into one of two categories:

heavy desktop software
lightweight browser tools

RPGMapEditor can sit between both.

The product direction is:

fast like a browser tool, but structured enough to feel like a real creative app.

That is why a Windows roadmap is worth exploring.

Not because every web app needs a desktop version.

Not because desktop automatically means serious.

But because map creation is a workflow where local files, exports, and repeat sessions matter.

Current priority

The immediate priority is still the web editor.

The desktop app should not slow down:

editor stability
map creation
export quality
save/load reliability
SEO landing pages
user onboarding
pricing validation

The desktop roadmap only makes sense if it supports the main product.

Final roadmap summary

The plan is not to rebuild RPGMapEditor.

The plan is to extend it.

Step 1: Keep the browser editor as the core product
Step 2: Validate a Windows desktop shell
Step 3: Add local .rpgmap save/load
Step 4: Add export workflows
Step 5: Package for Microsoft Store
Step 6: Measure installs, map creation, exports, and retention
Step 7: Decide whether desktop deserves more investment

The test is simple:

Can a Rust-powered browser RPG map editor become a useful Windows desktop mapmaking app without becoming a separate product?

That is the roadmap.

If the desktop version helps more users create, save, export, and return to their maps, it is worth continuing.

If it only creates engineering complexity, it should be paused.

The product goal stays the same:

Build a fast, useful, Rust-powered RPG map editor for people who want to create DnD maps, battle maps, and tabletop worlds.

How I Rebuilt an RPG Map Editor with Rust, React, and WASM

TheXper — Mon, 25 May 2026 18:55:25 +0000

Replacing a map editor sounds like a frontend task.

It is not.

A browser-based RPG map editor lives inside a product loop:

Create a map.
Open it in the editor.
Paint, place assets, rename it, and change layers.
Save automatically.
Reopen it later and trust that nothing disappeared.

If that loop is fragile, the editor can have great brushes, nice UI, and a fast canvas, but the product still feels broken.

This post walks through how I replaced a legacy map editor with a Rust/WebAssembly editor, rebuilt the maps dashboard around the new flow, and made cloud autosave safer.

The stack:

Rust + Rocket for authenticated routes and map persistence
SQLite for map records and saved project snapshots
Tera templates for the product shell
React + Vite + WebAssembly for the editor UI
Rust/WASM + WebGL2 for the map editing engine

The boring parts mattered most: routing, boot state, create flow, revisions, and autosave correctness.

The actual problem

The original request was simple:

Replace the current map editor with a WASM editor.
screenshot here;

But replacing the editor route was only the first layer.

A real D&D map maker or RPG map editor needs more than a canvas. It needs a stable workflow around the canvas. Users do not care that the editor is written in Rust or that the renderer uses WebGL2 if the New map button fails or their work does not save reliably.

So the real goal became:

Make map creation, editor boot, cloud saving, and reopening feel boring and trustworthy.

That meant fixing three areas at the same time:

the editor route
the maps dashboard
the save model

1. Replacing the editor route with the WASM editor

The first step was changing the authenticated editor route so that opening a map loaded the new WebAssembly editor instead of the old editor experience.

The important part was not just serving a new index.html file.

The editor needed account-aware boot data from the server:

{
  "map_id": "map_uuid",
  "title": "Dungeon Entrance",
  "revision": 12,
  "updated_at": "2026-05-25T12:00:00Z",
  "read_only": false,
  "csrf_token": "...",
  "api": {
    "load": "/api/maps/map_uuid",
    "save": "/api/maps/map_uuid"
  }
}

That boot payload became the bridge between the product shell and the editor.

The React/Vite/WASM editor should not guess who the user is, which map is open, whether the map is editable, or where it should save. The server already knows that. The editor should receive it explicitly.

That keeps the editor focused on editing, while the product shell owns authentication, permissions, persistence, and routing.

2. The dashboard had to become part of the editor experience

Once the WASM editor route worked, the maps dashboard became the next bottleneck.

The old dashboard still behaved like a marketing page connected to an older creation wizard. But the user expectation was much simpler:

Click New map.
Create a map record.
Redirect into the editor.

That is the core loop of a browser-based battle map maker. If this flow is not reliable, the product feels unfinished before the editor even loads.

So the dashboard was rebuilt around the editing workflow:

map summary cards
search
sorting
recent map cards
empty state
one primary create action

The dashboard stopped being a passive page and became the starting surface for map work.

3. Why the first `New map` fix was not enough

The first implementation used JavaScript:

await fetch('/api/maps', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-CSRF-Token': csrfToken
  },
  body: JSON.stringify({ title: 'Untitled Map' })
});

window.location.href = `/editor/${createdMap.id}`;

That worked in a smoke test.

Then the user reported that clicking New map did nothing.

That exposed the design flaw: a core product action depended entirely on a client-side event listener.

For something as important as creating a map, that is too fragile. JavaScript can fail because of stale assets, a bad bundle, a browser extension, a hydration issue, or a simple selector mismatch.

The fix was progressive enhancement.

The create action became a real HTML form:

<form method="post" action="/maps/new">
  <input type="hidden" name="csrf_token" value="{{ csrf_token }}" />
  <button type="submit">New map</button>
</form>

The server route does the critical work:

POST /maps/new
→ create map record
→ redirect to /editor/<id>

JavaScript can still intercept the submit and use the faster API path when everything is healthy. But the fallback path is now server-owned.

That is the right tradeoff:

HTML handles the critical action.
JavaScript improves the experience.
The server remains the source of truth.

This is the kind of boring engineering that makes a SaaS product feel reliable.

4. Keeping the API contract small

The editor did not need a huge API surface.

The useful contract was small:

GET /api/maps/<id>
PUT /api/maps/<id>

GET /api/maps/<id> loads the current map snapshot.

PUT /api/maps/<id> saves the new title, project JSON, and concurrency metadata.

The client sends something like:

{
  "title": "Dungeon Entrance",
  "snapshot": {
    "version": 1,
    "layers": [],
    "camera": {},
    "objects": []
  },
  "expected_revision": 12,
  "expected_updated_at": "2026-05-25T12:00:00Z"
}

The server can then reject stale writes instead of silently overwriting newer data.

For a single-user editor, optimistic concurrency may look unnecessary. It is not. Multiple tabs, reloads, slow requests, and old local drafts can all create write conflicts.

The editor should not pretend those cases do not exist.

5. Cloud autosave has to handle real editing

The editor already had local autosave and a cloud save function.

The naive loop looked reasonable:

Mark the editor dirty after a change.
Wait a few seconds.
Export project JSON.
Send it to the server.
Mark the editor saved.

The problem is that users keep editing while saves are in flight.

If an old save finishes after newer edits were made, the UI must not say everything is saved.

That is how users lose trust.

The safer model is a dirty generation counter.

Every edit increments a number:

let dirtyGeneration = 0;
let savedGeneration = 0;
let saveInFlight = false;

function markDirty() {
  dirtyGeneration += 1;
  scheduleAutosave();
}

When a save starts, the editor captures the current generation:

async function saveToCloud() {
  if (saveInFlight) return;
  if (dirtyGeneration === savedGeneration) return;

  saveInFlight = true;
  const generationAtStart = dirtyGeneration;
  const snapshot = exportProjectJson();

  try {
    const result = await putMapSnapshot(snapshot);

    if (dirtyGeneration === generationAtStart) {
      savedGeneration = generationAtStart;
      updateRevision(result.revision, result.updated_at);
      markCloudSaved();
    } else {
      scheduleAutosaveSoon();
    }
  } catch (error) {
    keepLocalDraft();
    scheduleRetry();
  } finally {
    saveInFlight = false;
  }
}

This protects against a common editor bug:

Save request A starts. The user makes edit B. Save request A finishes. The UI incorrectly says B is saved.

With generation tracking, the editor only clears the dirty state if no newer edits happened during the request.

6. Local drafts are a safety net, not the source of truth

Local autosave still matters.

But local storage should not become the final persistence model for an authenticated cloud editor.

The better model is:

local draft protects the user from crashes, reloads, and network failures
cloud save becomes the source of truth after a successful server write
server revision prevents stale overwrites
conflict handling decides what happens when the client is behind

That gives the user two layers of protection:

Immediate local safety while editing.
Durable cloud persistence once the network catches up.

For a creative tool, this matters more than it sounds. Losing a map is not a small bug. It is a trust-breaking event.

7. What changed in the product loop

Before this pass, the product had editor functionality, but the loop around it was fragile.

After the pass, the workflow became much tighter:

The dashboard opens as the user's map workspace.
New map always has a server-backed path.
The server creates a real map record.
The user lands in the Rust/WASM editor.
The editor boots with map ID, API URLs, title, revision, permissions, and CSRF token.
Changes save locally first.
Cloud autosave persists the project snapshot with optimistic concurrency.
Newer edits made during an in-flight save are not accidentally marked as saved.

That is the product loop a browser RPG map editor needs before deeper features matter.

What I would not overbuild yet

It is tempting to jump into advanced editor features immediately:

multiplayer editing
complex asset marketplaces
AI-generated maps
procedural dungeons
advanced sharing permissions
plugin systems

But those are not the first bottleneck.

The first bottleneck is trust.

For an RPG map editor, users need to believe that:

creating a map works
opening a map works
saving works
reopening works
their work will not disappear

Until that is true, advanced features are just decoration on top of a weak product loop.

Practical lessons

The useful lessons from this rebuild were simple:

Make critical actions work without JavaScript.
Pass explicit boot state into the editor.
Keep the editor API small.
Save title and project snapshot together.
Use server revisions for optimistic concurrency.
Track dirty generations on the client.
Treat local drafts as a fallback, not the final persistence layer.
Make saves boring.

The best editor infrastructure disappears when it works.

A user should not think about revisions, snapshots, CSRF tokens, local drafts, or save generations. They should create a dungeon map, close the tab, reopen it later, and see their work still there.

That is the real feature.

FAQ

Why use Rust and WebAssembly for a browser map editor?

Rust and WebAssembly make sense when the editor has engine-like requirements: canvas rendering, map state management, undo/redo, geometry, asset placement, and performance-sensitive operations. React can own the UI shell, while Rust/WASM owns the editing core.

Why not make the whole editor a React app?

React is good for panels, buttons, modals, inspectors, and dashboard UI. It is not the best place to put the entire editing engine. For a map editor, the canvas state, rendering model, command history, and project serialization benefit from a stricter engine layer.

Why use progressive enhancement for the New Map button?

Because creating a map is a critical action. If JavaScript fails, users should still be able to create a map and enter the editor. The enhanced JavaScript path can improve speed, but the server form path should remain reliable.

Why does autosave need a dirty generation counter?

Because users can continue editing while a save request is still running. A generation counter prevents an older save response from incorrectly marking newer edits as saved.

What is the most important part of cloud autosave?

The most important part is not the timer. It is correctness. The editor must know which edits were included in a save, which edits happened later, and whether the server accepted the write.

Final thought

Replacing the editor was the visible task.

Fixing the product loop was the real task.

For a browser-based D&D map maker, the canvas is only one part of the experience. The user also needs reliable creation, clear routing, safe autosave, and boring persistence.

That is what makes the editor feel like a product instead of a demo.

And the Result is here:

Why I Rebuilt My RPG Map Editor Landing Page with CSS Instead of WebGL

TheXper — Fri, 22 May 2026 17:58:31 +0000

Why I Rebuilt My RPG Map Editor Landing Page with CSS Instead of WebGL

Short answer: I removed the Three.js/WebGL hero animation from my RPG map editor landing page because it was slower, less reliable, and less useful than a simple CSS-based pixel-art hero.

The product is RPG Map Editor — a browser-based battle map maker for D&D, TTRPGs, dungeon maps, and fantasy map design.

The landing page originally tried to look technically impressive: particles, magical dust, animated cave lighting, shader effects, and a real-time WebGL background.

It worked.

Then I deleted it.

And the page became better.

The mistake: I built the landing page like a tech demo

When I first built the landing page for RPG Map Editor, I wanted the hero section to feel alive.

The idea was simple:

a fantasy cave background
Three.js particle effects
magical lighting
real-time atmosphere
a premium “serious software” feeling

In my head, this made sense. RPG Map Editor is not just a static website. It is a real browser-based editor for creating DnD battle maps, fantasy maps, dungeon maps, and tabletop RPG layouts.

So I thought the landing page should prove the engineering quality immediately.

That was the wrong priority.

A landing page is not supposed to prove that you can write shaders.

A landing page is supposed to help the right user understand:

“Can this tool help me make a battle map faster?”

That user might be a Dungeon Master preparing a session tonight. They might be looking for an Inkarnate alternative, a fast DnD map maker, or a simple RPG map editor that runs in the browser.

They do not care how clever the hero animation is.

They care if the page loads, looks trustworthy, and gets them to the editor quickly.

The WebGL problem: decoration was competing with the product

The actual RPG Map Editor uses WebGL2 for the editor canvas.

That makes sense.

The editor needs GPU rendering because users are painting terrain, placing tiles, moving around maps, and exporting battle maps.

But the landing page also had a WebGL hero animation.

That was the mistake.

The decorative WebGL scene was competing with the product’s real WebGL context. On some machines, especially mid-range laptops and browsers with many tabs open, the landing page could create reliability issues before the user even opened the map editor.

At one point, users could land on the site and see a WebGL-related failure message.

That is a terrible first impression for a browser-based map editor.

The irony was obvious:

The landing page was breaking trust in the exact technology the product depends on.

If your actual product needs WebGL, do not waste WebGL on decoration unless the payoff is massive.

For this page, it was not.

Performance also mattered more than visual flexing

The old version looked good on my machine.

That is not enough.

A lot of people who need a DnD map maker are not using a high-end development setup. They may be on older Windows laptops, integrated graphics, school machines, cheap tablets, or browsers already under load.

The WebGL hero added unnecessary weight and GPU usage before the user had done anything valuable.

That is bad product strategy.

The landing page’s job is not to impress other developers.

The landing page’s job is to convert people who searched for things like:

RPG map editor
DnD map maker
battle map maker
fantasy map editor
browser-based map maker
Inkarnate alternative
tabletop RPG map tool

Those users need clarity, speed, and a reason to click.

They do not need a particle system.

The pivot: CSS, pixel art, and brutal simplicity

I removed the Three.js hero scene.

All of it.

The particle system, shaders, animated background logic, and extra JavaScript were gone.

I replaced the hero with a simple image:

<img class="hero-bg" src="/static/photos/heroBg.webp" alt="Pixel-art fantasy cave background for RPG Map Editor">

And CSS:

.hero-bg {
  position: absolute;
  inset: 0;
  width: 100%;
  height: 100%;
  object-fit: cover;
  object-position: center top;
  image-rendering: pixelated;
  pointer-events: none;
  user-select: none;
}

Then I added atmosphere with CSS gradients:

.hero-overlay {
  background:
    radial-gradient(
      ellipse 75% 55% at 50% 42%,
      rgba(5, 4, 10, 0.0) 0%,
      rgba(5, 4, 10, 0.35) 100%
    ),
    linear-gradient(
      90deg,
      rgba(5, 4, 10, 0.45) 0%,
      rgba(5, 4, 10, 0.08) 40%,
      rgba(5, 4, 10, 0.45) 100%
    ),
    linear-gradient(
      180deg,
      rgba(5, 4, 10, 0.2) 0%,
      rgba(5, 4, 10, 0.0) 45%,
      rgba(5, 4, 10, 0.55) 100%
    );
}

No canvas.

No Three.js.

No extra rendering context.

No shader debugging.

Just HTML, CSS, and a fantasy pixel-art image.

The surprising part: the simpler version looked more like an RPG tool

This was the part I did not expect.

The CSS version did not just perform better.

It communicated the product better.

RPG Map Editor is for tabletop RPG maps, dungeon maps, battle maps, D&D sessions, and fantasy worldbuilding. A pixel-art cave background instantly feels closer to that world than a generic tech-startup WebGL animation.

The old hero said:

“I know how to build WebGL effects.”

The new hero says:

“This is a map-making tool for people who love tabletop RPGs.”

That is a better message.

Especially for users comparing tools like Inkarnate, Dungeon Scrawl, DungeonFog, or other battle map makers. They are not choosing based on which landing page has the most complex animation. They are choosing based on whether the tool looks useful, fast, and relevant to their campaign.

Before vs after

Area	WebGL Hero	CSS Hero
First impression	Impressive but generic	Fantasy/RPG-specific
Performance	Heavier	Lighter
Reliability	Could conflict with WebGL usage	No WebGL context needed
Maintenance	Shaders, browser quirks, Three.js logic	HTML and CSS
Product fit	Tech demo feeling	DnD map maker feeling
SEO clarity	Focused on frontend tech	Focused on RPG map editor users

The biggest win was not technical.

The biggest win was positioning.

The page stopped feeling like a developer portfolio and started feeling like a product page for a battle map maker.

What I kept: WebGL where it actually matters

I am not anti-WebGL.

The editor itself still needs WebGL2.

That is where GPU rendering belongs:

painting terrain
rendering map layers
moving around the canvas
placing assets
handling large battle maps
exporting maps
keeping the editor responsive

That is real product value.

But using WebGL for a non-interactive hero background was unnecessary complexity.

A good rule:

Use advanced technology where it improves the user’s outcome, not where it only improves your ego.

For an RPG map editor, WebGL belongs inside the editor.

The landing page can be simple.

What I built instead

1. A pixel-art fantasy hero

The hero now uses a static pixel-art background that matches the product category: fantasy, D&D, tabletop RPGs, dungeon maps, and battle maps.

This helps users understand the product faster.

It also gives search engines and AI systems clearer context when the page talks about RPG map editing, battle map creation, and browser-based DnD map tools.

2. CSS-based atmosphere

Instead of real-time lights and particles, I use layered CSS gradients for darkness, depth, and contrast.

It feels atmospheric without becoming fragile.

3. CSS button effects

The main call-to-action button uses a small shimmer effect with a pseudo-element:

.glass-button::before {
  content: "";
  position: absolute;
  inset: 0;
  background: linear-gradient(
    105deg,
    transparent 40%,
    rgba(255, 255, 255, 0.18) 45%,
    rgba(255, 255, 255, 0.25) 50%,
    rgba(255, 255, 255, 0.18) 55%,
    transparent 60%
  );
  transform: translateX(-120%);
  transition: transform 0.65s ease;
}

.glass-button:hover::before {
  transform: translateX(120%);
}

It gives the interface a premium feeling without adding a JavaScript animation library.

4. Clearer copy

The copy now focuses less on the technology and more on the user:

make a battle map
try a browser-based editor
create DnD maps without installing software
use a map-making tool built for tabletop RPGs

That matters more than saying “powered by WebGL” in the first three seconds.

Lesson 1: Your landing page is not your portfolio

This was the harshest lesson.

I was building the old landing page to impress other developers.

But the buyer is not another frontend engineer.

The buyer is a DM, GM, solo worldbuilder, indie RPG creator, or tabletop player who needs a map.

They are asking practical questions:

Can I make a battle map quickly?
Does it work in my browser?
Is it free to try?
Do I need an account?
Is it easier than learning a complex editor?
Is this a usable Inkarnate alternative for my workflow?

Those questions should shape the landing page.

Not my desire to show off shaders.

Lesson 2: “Premium” does not require heavy tech

A page can feel premium with:

strong typography
clear contrast
good spacing
fast loading
intentional visuals
consistent art direction
focused copy
clean CSS animation

You do not need WebGL for every premium visual.

You need taste.

The CSS version feels better because it has stronger product-market alignment. It looks like a fantasy mapping tool instead of a generic SaaS landing page with a cave background.

Lesson 3: SEO works better when the product story is clear

The original article was mostly about removing WebGL.

That is interesting to developers, but it does not fully capture what the product is.

The better framing is:

I simplified the landing page of a browser-based RPG map editor so DnD map maker users could understand the product faster.

That sentence contains the actual search intent.

Good SEO is not just keyword insertion.

It is matching the article to the real problem:

people need RPG maps
people search for map-making tools
they compare browser-based options
they know names like Inkarnate
they want fast battle map creation
they do not care about decorative engineering

Once I understood that, the article became stronger.

FAQ

What is RPG Map Editor?

RPG Map Editor is a browser-based map editor for tabletop RPGs. It is designed for creating fantasy maps, DnD battle maps, dungeon maps, and grid-based maps directly in the browser.

Is RPG Map Editor a DnD map maker?

Yes. RPG Map Editor can be used as a DnD map maker for creating battle maps, dungeon layouts, terrain maps, and tabletop RPG scenes.

Is RPG Map Editor a battle map maker?

Yes. The goal is to make it easy to create browser-based battle maps for tabletop RPG sessions without needing to install desktop software.

Is RPG Map Editor an Inkarnate alternative?

RPG Map Editor is not an Inkarnate clone. Inkarnate is a well-known fantasy map-making tool, while RPG Map Editor is being built as a browser-based RPG and battle map editor with its own workflow, technical stack, and product direction.

Why use CSS instead of WebGL on the landing page?

Because the landing page does not need real-time rendering. CSS is faster to maintain, more reliable, and good enough for atmospheric visuals. WebGL should be reserved for the actual editor canvas where users create maps.

Should every RPG map editor avoid WebGL on the landing page?

Not always. If the WebGL experience directly demonstrates the product and performs reliably, it can be worth using. But if it is only decorative, it may create more risk than value.

Final thought

The best technology is not the most impressive one.

The best technology is the one that helps the user succeed without creating new problems.

For RPG Map Editor, WebGL belongs in the editor.

The landing page just needs to be fast, clear, thematic, and convincing.

That meant deleting the clever part.

And that was the right decision.

Try it here: RPG Map Editor — browser-based battle map maker for D&D and TTRPGs

Building a Browser-Based Inkarnate Alternative for D&D Battle Maps

TheXper — Thu, 21 May 2026 18:50:36 +0000

Building a Browser-Based Inkarnate Alternative for D&D Battle Maps

When people search for an Inkarnate alternative, they are usually not asking for one single thing.

Some want a beautiful fantasy world map.

Some want a regional map for a novel.

Some want a city map.

But a lot of Dungeon Masters want something much more practical:

“I need a playable D&D battle map for this week’s session, and I do not want to spend the whole evening fighting a heavy tool.”

That is the problem I am building around with RPGMapEditor.com.

It is a browser-based RPG map editor focused on encounter-scale battle maps for D&D, TTRPGs, Roll20, Foundry VTT, and printable tabletop sessions.

Not a full fantasy illustration suite.

Not a worldbuilding atlas.

Not a replacement for every cartography tool.

A faster way to create readable, playable battle maps in the browser.

Quick answer: is RPGMapEditor.com an Inkarnate alternative?

Yes, but only for a specific workflow.

RPGMapEditor.com is an Inkarnate alternative if your main goal is to create grid-based battle maps for D&D or other tabletop RPG sessions.

It is not trying to replace Inkarnate for polished world maps, regional fantasy maps, or large illustrated map galleries.

The difference is simple:

Use case	Better fit
Fantasy world map	Inkarnate or a broader fantasy map tool
Regional campaign map	Inkarnate-style tools
Fast D&D battle map	RPGMapEditor.com
Browser-based encounter prep	RPGMapEditor.com
PNG export for Roll20 / Foundry background use	RPGMapEditor.com
Highly polished fantasy illustration	Broader art-first map tools

If your weekly pain is encounter production, not fantasy illustration, a narrower tool can be better.

Why another RPG map editor?

Most DMs do not need a perfect map.

They need a map that is:

readable
fast to make
aligned to a grid
easy to revise
exportable to a VTT
good enough for actual play

That sounds obvious, but many map tools slowly become asset browsers, art suites, marketplace platforms, or full VTT automation systems.

Those can be powerful.

They can also be slow when the party unexpectedly goes into a cave, tavern, forest road, sewer, bridge, or ruined chapel you did not prepare.

The bet behind RPGMapEditor.com is that a focused editor can win by reducing decisions.

Open the browser.

Start from a blank canvas or demo map.

Paint terrain.

Place props.

Check the grid.

Export PNG.

Use it in Roll20, Foundry VTT, or at the table.

That workflow matters more than having every possible feature on day one.

What RPGMapEditor.com supports today

The current shipped workflow focuses on practical battle map creation:

browser-based map editing
terrain painting
props and stamps
grid-based battle maps
demo projects
PNG export
free accounts with limited saved maps
optional Studio plan for more saved maps and sharing features

That means the tool is already useful for a common tabletop workflow:

Create a tactical map.
Export it as a PNG.
Upload it into Roll20 or Foundry VTT.
Align the grid inside your VTT.
Run the encounter.

This is intentionally simple.

PNG export is not glamorous, but it is one of the most universal handoff formats for virtual tabletops.

What RPGMapEditor.com does not claim yet

This matters because fake comparison articles are useless.

RPGMapEditor.com does not currently claim to export:

native Foundry VTT scenes
Roll20 dynamic lighting
automatic walls
automatic doors
full VTT automation data

For now, the product focuses on the visual battle map.

Your VTT still handles tokens, walls, lighting, fog, automation, initiative, sheets, and live gameplay.

That is not a weakness if the user understands the scope.

It becomes a weakness only if the marketing lies.

Why browser-based map editing matters

Desktop map tools can be powerful, but they create friction:

installation
updates
local files
asset folders
OS compatibility
device switching
heavier onboarding

A browser-based RPG map editor removes some of that friction.

For many DMs, the best tool is not the one with the longest feature list.

The best tool is the one they actually open on a weeknight when the session is tomorrow.

That is where browser-based editing has a real advantage.

You can open a demo project, test the editor, and understand the workflow before committing to an account or paid plan.

The real comparison: art suite vs encounter tool

Inkarnate is known for fantasy map creation across multiple styles.

That is a strength.

But broad tools often serve broad use cases:

world maps
regional maps
city maps
fantasy art scenes
map galleries
cloneable maps
large asset libraries

RPGMapEditor.com is narrower.

It is aimed at:

D&D battle maps
grid-based tactical scenes
encounter prep
Roll20 PNG workflows
Foundry VTT background map workflows
browser-first editing
quick iteration

That narrower positioning is the product strategy.

Not “more features than Inkarnate.”

Not “better at everything.”

Just faster battle map prep for the use case where speed matters.

A simple example workflow

Imagine you need a forest ambush map for tomorrow’s session.

You do not need a masterpiece.

You need:

a road
trees
cover
difficult terrain
readable grid spacing
maybe a ruined cart
maybe rocks or elevation hints
a clean export

In RPGMapEditor.com, the intended workflow is:

Start from a blank map or demo.
Paint the main playable terrain.
Add props that affect tactics.
Keep the grid readable.
Export a PNG.
Import it into Roll20 or Foundry VTT.
Add tokens, walls, lighting, and gameplay details inside the VTT.

That is the practical DM workflow.

The map does not need to win an art contest.

It needs to make combat understandable.

Who should try RPGMapEditor.com?

RPGMapEditor.com is worth testing if you are:

a Dungeon Master making regular battle maps
a GM running grid-based TTRPG encounters
preparing maps for Roll20
preparing scene backgrounds for Foundry VTT
tired of installing desktop tools for simple maps
looking for a lightweight browser-based RPG map editor
comparing Inkarnate alternatives specifically for battle maps

It is probably not the right first choice if you mainly want:

a giant world map
a polished regional fantasy map
advanced illustration tools
a huge established asset marketplace
automatic VTT walls and doors today

That distinction is important.

A focused tool should be judged by the job it is designed to do.

Why I am building it this way

The product philosophy is simple:

A battle map editor should help DMs reach a playable map faster.

That means the important questions are not only technical.

They are product questions:

Can a new user understand the editor quickly?
Can they make a usable map in one sitting?
Can they export without confusion?
Can they reopen and revise maps later?
Can the grid stay readable?
Can the map survive real VTT usage?
Does the workflow reduce prep stress?

Those questions matter more than adding another shiny feature.

RPGMapEditor.com vs Inkarnate: the honest version

Here is the honest comparison.

Use Inkarnate or a broader fantasy map tool when you want a polished fantasy illustration workflow, world maps, regional maps, city maps, or access to a mature asset ecosystem.

Use RPGMapEditor.com when you want a focused browser-based battle map editor for encounter prep, terrain painting, props, grid maps, saved projects, and PNG export for VTT use.

That is the lane.

And for many DMs, that lane is enough.

Try it

You can try the browser-based editor here:

RPGMapEditor.com

Useful pages:

If you are a DM, the best test is simple:

**Create one encounter map.

Export it.

Use it in your actual VTT.

If it saves prep time, the product is doing its job.**

I Added Real Playable Demo Maps to RPGMapEditor.com

TheXper — Tue, 19 May 2026 21:44:24 +0000

I’m building RPG Map Editor, a browser-based map editor for tabletop RPGs, D&D sessions, Roll20 maps, and Foundry VTT workflows.

One of the biggest problems with creative SaaS landing pages is that they usually show fake proof.

You get a shiny hero section, some screenshots, a few feature cards, and a call-to-action.

But if you are building a tool for Dungeon Masters, game masters, or worldbuilders, screenshots are not enough.

People want to know:

Can I open a real map?
Can I edit it?
Can I export something useful?
Is this actually a product, or just a pretty landing page?
Does it work before I sign up?

So I added real playable demo maps directly to the RPGMapEditor.com homepage.

But there was a catch.

I wanted users and crawlers to see real product proof, but I did not want Google indexing a bunch of thin /demo/* editor shell pages.

So the final architecture became:

Make the homepage indexable. Make the demos playable. Keep the editor utility routes noindex.

This is how I built it.

The product problem

RPGMapEditor.com is meant to be a lightweight browser-based alternative for creating RPG and D&D battle maps without installing a desktop app.

The target user is someone who wants to quickly create a usable session map, export it, and use it in a tabletop workflow.

That means the landing page cannot only say:

“Create beautiful RPG maps.”

It has to prove it.

So instead of only showing static marketing screenshots, I wanted the homepage to show real demo projects:

A top-down encounter map
A multi-room map
An entity playground
Real .rpgmap.json files
Real editor links
Real preview images
Real export workflow copy

The homepage needed to become product proof, not just product description.

The SEO problem

The naive version would be simple:

/demo/typical-topdown
/demo/multi-room-world
/demo/entity-playground

Each page would load the editor and let users try a map.

That works for users.

But it is bad for search.

Those pages are mostly utility routes. They are not strong landing pages. They are not meant to rank for searches like:

D&D battle map maker
browser RPG map editor
Roll20 battle map export
Foundry VTT map tool
online tabletop map maker

The homepage and dedicated landing pages should target those searches.

The demo routes should support conversion, not compete in search results.

So the rule became:

/                -> indexable product page
/battle-map-maker -> indexable intent page
/roll20-battle-map-export -> indexable workflow page
/foundry-vtt-battle-map-export -> indexable workflow page
/demo/*          -> playable, but noindex

That keeps the site focused.

The architecture

The whole demo system is driven by one manifest file:

`map-editor/public/demo-projects/manifest.json

That manifest is the source of truth for:

Homepage demo cards
Editor boot config
Demo route resolution
Preview images
JSON-LD structured data
Internal validation
Product copy for each demo

The key principle is simple:

If the marketing page says a demo exists, the editor must actually be able to load it.

No fake screenshots.

No stale copy.

No card that says “open in editor” and then breaks.

Example manifest entry

A demo project entry looks roughly like this:

{ "slug": "typical-topdown", "title": "Top-Down Encounter Sample", "description": "A small editable battle map designed for a quick tabletop encounter.", "intent": "Use this to test terrain, props, grid alignment, and PNG export.", "projectUrl": "/demo-projects/typical-topdown.rpgmap.json", "previewUrl": "/demo-projects/typical-topdown.webp", "demoUrl": "/demo/typical-topdown", "width": 32, "height": 24, "grid": "square" }

This gives the homepage everything it needs:

A readable title
A useful description
A preview image
A real project file
A playable editor URL
Grid metadata
Search-friendly text
Structured data fields

The demo card and the editor both come from the same data.

That matters because marketing drift is real.

It is very easy for a landing page to say one thing while the actual product does another.

Server-side validation

The Rust server validates the demo manifest before rendering the homepage.

The validation checks that:

The manifest version is valid
Slugs are unique
Demo URLs are same-origin
Preview images exist
Project files exist
Project JSON parses correctly
Demo projects do not depend on remote http(s) asset URLs

That last point is important.

A demo map should not silently depend on a remote image or tileset that can disappear later.

For RPGMapEditor.com, demo projects need to be self-contained so they load quickly and reliably.

If validation fails, the homepage does not advertise broken demo cards.

That is better than showing “Open in editor” and sending users into a dead route.

Server-rendered proof cards

The homepage renders demo projects as real HTML.

Not a JavaScript-only carousel.

Not a hidden JSON blob.

Not an empty

that only appears after hydration.

Real server-rendered cards.

Example:
`

Start from a real encounter

src="/demo-projects/typical-topdown.webp"
alt="Top-Down Encounter Sample editable demo battle map preview"
width="1200"
height="800"
loading="lazy"
decoding="async"
>

<h3>Top-Down Encounter Sample</h3>
<p>A small editable battle map designed for a quick tabletop encounter.</p>
<p>32 × 24 square grid</p>

<a href="/demo/typical-topdown">Open in editor</a>

This gives both users and search engines actual proof:

RPGMapEditor.com has real demo maps
The maps are editable
The links are visible
The previews have descriptive alt text
The product is not just a mockup

That matters for a new SaaS.

A new product has no trust by default.

The fastest way to earn trust is to let people try something real.

The demo routes are playable, but noindex

Each demo link opens the real editor.

For example:

https://www.rpgmapeditor.com/demo/typical-topdown

The server resolves the slug against the manifest and injects a boot config:
window.RPGME_EDITOR_BOOT = { mode: "demo", projectUrl: "/demo-projects/typical-topdown.rpgmap.json", copyApiUrl: "/api/demo-projects/typical-topdown/copy", signupNextUrl: "/signup?next=/demo/typical-topdown" };

But the demo route also includes:

<meta name="robots" content="noindex, nofollow">
That is intentional.

The demo route exists for product experience.

The homepage exists for search.

The journey is:

Google / Dev.to / social post
↓
RPGMapEditor.com homepage
↓
Demo card
↓
Open real editor
↓
Try map
↓
Export / sign up / copy project

The demo page helps conversion.

It does not need to rank.

Structured data mirrors the visible page

The homepage also outputs JSON-LD structured data.

The important part is that the structured data is generated from the same manifest as the visible demo cards.

Example:

{
"@context": "https://schema.org",
"@type": "ItemList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Top-Down Encounter Sample",
"url": "https://www.rpgmapeditor.com/demo/typical-topdown"
}
]
}

There is also FAQ schema generated from visible FAQ content on the page.

The rule is:

Structured data should describe what users can actually see.

If the manifest fails and demo cards are not rendered, the ItemList schema is not rendered either.

No fake schema.

No invisible SEO content.

No pretending the page contains things it does not.

Performance choices

The homepage also has a visual hero section, but I did not want it to destroy performance.

The hero uses:

A static WebP poster
fetchpriority="high"
Preload for important visual assets
Optional Three.js overlay
Motion preference checks
Desktop viewport checks
IntersectionObserver before loading heavy JavaScript

The demo preview images are lazy-loaded below the fold.

Heavy animation is deferred.

The homepage should still make sense before JavaScript loads.

This matters because technical SEO is not only meta tags.

If the page is slow, unstable, or blank until JavaScript runs, the implementation is weak.

Why this matters for RPGMapEditor.com

For a new map editor, the hard part is not only building tools.

The hard part is proving that the product deserves attention in a crowded space.

There are already established tools for tabletop maps.

So RPGMapEditor.com needs to show its positioning clearly:

Browser-based
No desktop install required
Real editable demo maps
Fast try-before-signup flow
Useful for D&D and tabletop sessions
PNG workflow for Roll20 and Foundry VTT
Honest about what is shipped and what is not

The demo maps are not just a nice visual section.

They are part of the product strategy.

They reduce the gap between:

“This looks interesting.”

And:

“I opened a real map and tested it.”

That gap is where most SaaS landing pages lose users.

The reusable pattern

This architecture is not only useful for website.

You can use the same pattern for any creative SaaS product:

Browser editors
Diagram tools
Design tools
Code playgrounds
Game tools
Image tools
Website builders
Workflow builders

The pattern is:

Create real example projects
Store metadata in one manifest
Validate the manifest server-side
Render example cards as HTML
Link examples to real playable routes
Mark utility routes noindex
Generate structured data from the same manifest
Track opens, exports, signups, and conversion

The principle:

Index the proof. Noindex the playground.

What I am watching next

This is still an experiment.

The implementation is technically cleaner, but the business question is whether it converts.

The metrics that matter are:

Homepage click-through rate to demos
Demo open rate
Demo-to-signup conversion
Export attempts
Returning users
Search impressions for map editor queries
Queries mentioning Roll20, Foundry, D&D, and battle maps
Whether users understand what is shipped today

If people open the demo but do not sign up, the problem may be onboarding.

If people never open the demo, the homepage copy or card placement is weak.

If people sign up but do not export, the editor workflow needs work.

That is the point of building it this way.

The demos are not only SEO content.

They are a product validation loop.

Final thought

I do not think a new creative SaaS product should hide behind polished screenshots.

If the product is real, the landing page should prove it.

For RPGMapEditor.com, that meant putting real demo maps on the homepage, rendering them as crawlable HTML, validating them through a manifest, linking them into the real editor, and keeping the utility editor pages out of the search index.

It is a simple split:

The homepage ranks.
The demo routes convert.
The manifest keeps everything honest.

That is the architecture I would use again.

If you are building a browser-based creative tool, do not just say what it can do.

Let people open something real.

Building a Browser-Based RPG Map Editor with Rust, WebAssembly, WebGL2, and React

TheXper — Mon, 18 May 2026 13:08:33 +0000

I've been building RPGMapEditor.com — a browser-based fantasy map editor for dungeon masters, worldbuilders, and tabletop RPG players.

The stack is: Rust + WebAssembly for the editor core, WebGL2 for rendering, React + TypeScript for UI, Rocket for the backend, and SQLite for storage.

This post is not a product pitch. It's about the architecture decisions I made, what broke, what I'd change, and why a map editor is a surprisingly brutal problem domain.

Quick answers

What is RPGMapEditor.com?
A browser-based fantasy map editor for tabletop RPG creators, dungeon masters, worldbuilders, and virtual tabletop users. No install required.

Why Rust and WebAssembly in a browser app?
Rust/WASM keeps editor state, geometry, layer data, and commands outside of React. React owns the UI. Rust owns the map. They don't fight over the source of truth.

Is it an Inkarnate alternative?
It is in the same category as Inkarnate and Dungeondraft — fantasy maps, battle maps, dungeon maps — but built with a Rust/WASM/WebGL2 browser-native architecture instead of Unity or a pure JS canvas.

Who is it for?
Dungeon masters, tabletop RPG players, worldbuilders, indie game developers, and creators who need fantasy maps and VTT-ready exports.

The hard part

A map editor is not a normal web app.

The login page and dashboard were easy. The hard parts were:

Keeping editor state deterministic across undo/redo
Rendering hundreds of stamps without one draw call per object
Preventing React state from becoming the source of truth for the map
Keeping saves structured rather than flattening everything into a PNG
Supporting layers, procedural brushes, terrain, fog, and export without turning the codebase into spaghetti

Every time I tried to prototype a map editor in pure React with a canvas, it collapsed. State was in three places. Undo was wrong. Re-renders were killing rendering performance. The map and the UI were constantly fighting over who owned what.

That's why I moved the editor core to Rust/WASM.

Architecture

User input (mouse, keyboard, touch)
        ↓
React UI — toolbar, panels, modals
        ↓
TypeScript ↔ WASM bindings (wasm-bindgen)
        ↓
Rust editor engine
        ↓
Command system + immutable map state
        ↓
Renderer pipeline
        ↓
WebGL2 — batched draw calls, atlas, framebuffers
        ↓
<canvas>

React handles what the user sees and clicks. Rust handles what the map actually is. They communicate through typed WASM bindings. The Rust side is the single source of truth. React is display.

Why Rust instead of TypeScript for the core

I want to be honest: Rust has a steep learning curve, and I'm not a graphics programming expert. I picked it anyway because:

Ownership model forces you to think about state clearly. You can't have two mutable references to the same map state. That prevents a whole class of bugs that destroyed my earlier Canvas/JS prototypes.
WASM performance is real. Geometry operations, tessellation with lyon_tessellation, and texture atlas packing with guillotiere are fast and deterministic. No GC pauses, no hidden re-allocation surprises.
The command system is cleaner in Rust. Every editor action — stamp placement, eraser stroke, layer reorder, terrain paint — is a typed Command enum. Undo/redo is just a stack of commands. This is theoretically possible in TypeScript but Rust's type system makes it much harder to cheat.

The rendering pipeline

WebGL2 was the right call for this kind of editor. The key constraint: minimizing draw calls.

A naive implementation draws one quad per stamp. Drop 200 stamps on a map and you have 200 draw calls. That doesn't scale.

Instead:

All stamp textures are packed into a texture atlas at load time using guillotiere on the Rust side.
The renderer batches sprites that share the same atlas texture into a single draw call.
Each layer has its own framebuffer. Compositing layers means blending a small number of textures rather than re-drawing every object.
The atlas UV coordinates are pre-calculated in Rust and passed to WebGL2 as typed arrays.

The result: a map with a few hundred stamps and four layers renders comfortably at 60fps on mid-range hardware.

What broke (and what I'd redesign)

Biggest mistake: underestimating wasm-bindgen boilerplate.

The boundary between Rust and TypeScript takes serious maintenance. Every time I changed a Rust type that crossed the boundary, I had to update bindings, types, and sometimes the React component that consumed them. I should have designed a stable, narrow API surface between the two sides much earlier. Instead, the boundary grew organically and became a source of bugs.

Second mistake: starting the atlas too simple.

My first texture atlas was a fixed 2048×2048 texture. That ran out quickly once I added procedural terrain brushes. Moving to a dynamic atlas system (guillotiere) mid-project was painful. I should have planned for this from the start.

Third mistake: saving too late.

I spent months on the rendering pipeline before I built the save format. When I finally sat down to serialize a map, I realized my state structure wasn't as clean as I thought. Parts of the render state had leaked into the map state. Redesigning the save format forced a partial refactor of the state model.

If I started over: design the save format on day one. It forces you to define what the map actually is, separate from how it renders.

A real code snippet: the command system

Here's a simplified version of how editor commands work in Rust. Every user action that modifies the map becomes a Command:

pub enum Command {
    PlaceStamp {
        stamp_id: StampId,
        position: Vec2,
        layer: LayerId,
        scale: f32,
        rotation: f32,
    },
    EraseArea {
        region: Rect,
        layer: LayerId,
    },
    MoveStamp {
        stamp_id: StampId,
        from: Vec2,
        to: Vec2,
    },
    ReorderLayer {
        layer_id: LayerId,
        new_index: usize,
    },
}

pub struct EditorState {
    map: MapState,
    undo_stack: Vec<Command>,
    redo_stack: Vec<Command>,
}

impl EditorState {
    pub fn apply(&mut self, cmd: Command) {
        self.map.execute(&cmd);
        self.undo_stack.push(cmd);
        self.redo_stack.clear();
    }

    pub fn undo(&mut self) {
        if let Some(cmd) = self.undo_stack.pop() {
            self.map.revert(&cmd);
            self.redo_stack.push(cmd);
        }
    }
}

The key: revert is the inverse of execute. Every command knows how to undo itself. No magic. No diff-based snapshots. No full state cloning on every action.

Current status

The editor is in active development. Working right now:

Stamp placement, eraser, selection tools
Layer system with blend modes
Procedural terrain brushes (noise-based)
Texture atlas and batched rendering
Fog of War
JSON-based save format
PNG export

In progress:

VTT export format (Foundry, Roll20 compatibility)
Lighting effects with framebuffer compositing
Collaborative editing (long-term goal)

Is this approach overkill for a side project?

Probably, yes.

A simpler implementation with Fabric.js or Konva would have gotten me a working editor faster. If the goal was just shipping a demo, I over-engineered this. hah

But I've used those approaches before. They hit walls. When you want reliable undo/redo, proper layer compositing, atlas batching, and a structured save format, the simple canvas library starts fighting you. You end up bolting architecture onto a foundation that wasn't designed for it.

Building it as an architecture problem from the start has made it easier to add features correctly, even if it made the first six months slower.

If you're building something similar

A few things I'd tell myself earlier:

Design your save format first. It forces clarity on what your data model actually is.
Pick one source of truth and protect it. If Rust owns the map, don't let React sneak in and mutate it directly.
Design a narrow, stable WASM API surface. Fewer crossing points = fewer headaches.
Don't optimize the renderer until you have a correct renderer. Get batching right logically before profiling.
Log your draw call count during development. It's the fastest feedback loop for renderer health.

If you're working on browser-based creative tools, game-adjacent editors, or WebAssembly/WebGL projects, I'd genuinely enjoy discussing the architecture. Drop a comment or find me at RPGMapEditor.com.

DEV Community: TheXper

Dungeon Scrawl vs RPGMapEditor.com: Which Browser Map Tool Fits Your Game?

Quick verdict

The map-prep difference

Comparison table

VTT workflow

The 10-minute test

Choose Dungeon Scrawl if...

Choose RPGMapEditor.com if...

Does RPGMapEditor.com replace Dungeon Scrawl?

FAQ

Is RPGMapEditor.com a Dungeon Scrawl alternative?

Can I use RPGMapEditor.com with Roll20 or Foundry?

Is RPGMapEditor.com an old-school map maker?

Which one should I try first?

Final recommendation

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

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

What RPG Map Editor Is

Why Build Another RPG Map Editor?

The Honest Limitation: PNG Export Is Not Enough for Everyone

Why Rust + WebAssembly?

Why Microsoft Store?

What I Am Testing Now

What I Changed After Early Feedback

The Current Product Scope

RPGMapEditor Roadmap: Bringing a Rust-Powered DnD Map Maker to Windows

The roadmap direction

Why a desktop app makes sense

Why not rewrite everything natively?

Planned architecture

The first Windows version

What the desktop app should not become

Why Microsoft Store is interesting

Roadmap phase 1: Desktop proof of concept

Roadmap phase 2: Local file workflow

Roadmap phase 3: Microsoft Store packaging

Roadmap phase 4: Product-led conversion

Roadmap phase 5: Desktop plus cloud

Who this is for

Why this roadmap matters

Current priority

Final roadmap summary

How I Rebuilt an RPG Map Editor with Rust, React, and WASM

The actual problem

1. Replacing the editor route with the WASM editor

2. The dashboard had to become part of the editor experience

3. Why the first New map fix was not enough

4. Keeping the API contract small

5. Cloud autosave has to handle real editing

6. Local drafts are a safety net, not the source of truth

7. What changed in the product loop

What I would not overbuild yet

Practical lessons

FAQ

Why use Rust and WebAssembly for a browser map editor?

Why not make the whole editor a React app?

Why use progressive enhancement for the New Map button?

Why does autosave need a dirty generation counter?

What is the most important part of cloud autosave?

Final thought

Why I Rebuilt My RPG Map Editor Landing Page with CSS Instead of WebGL

Why I Rebuilt My RPG Map Editor Landing Page with CSS Instead of WebGL

The mistake: I built the landing page like a tech demo

The WebGL problem: decoration was competing with the product

Performance also mattered more than visual flexing

The pivot: CSS, pixel art, and brutal simplicity

The surprising part: the simpler version looked more like an RPG tool

Before vs after

What I kept: WebGL where it actually matters

What I built instead

1. A pixel-art fantasy hero

2. CSS-based atmosphere

3. CSS button effects

4. Clearer copy

Lesson 1: Your landing page is not your portfolio

Lesson 2: “Premium” does not require heavy tech

Lesson 3: SEO works better when the product story is clear

FAQ

What is RPG Map Editor?

3. Why the first `New map` fix was not enough