Forem: TheXper

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.