Over four years ago I started building something that most developers
told me shouldn't work.

A browser game engine with no canvas element, no WebGL, and no
external game libraries. The entire engine runs on the DOM. Every
game lives as a standard web page at its own URL. Players click
a link and the game loads instantly on any device with no
download, no install, no app store.

Most browser game developers assume canvas or WebGL is a
requirement. I wanted to find out what happens if you remove
that assumption entirely.

Why No Canvas

The canvas approach is powerful but it creates a distribution
problem. Canvas games need to be exported, uploaded, and served
from a host that handles the files. The game and the website
are two separate things. Embedding requires an iframe. Sharing
requires a host.

Running on the DOM meant something different was possible. The
page itself becomes the game. No iframe, no embed, no separate
host. The game lives natively inside any website as a standard
page. Build it and it is immediately live at its own URL.

That URL is the thing that changes everything about distribution.
Share it anywhere and anyone can play it instantly. No friction
between a creator and their audience.

How the Engine Works

Game logic is defined through a visual interface rather than
code. Areas, characters, items, enemies, missions, cutscenes,
and dialogue are all configured without writing a single line
of JavaScript.

On the front end the engine reads that configuration and handles:

• Top down and side scrolling movement
• Collision detection
• NPC dialogue and branching conversations
• Mission and progression systems
• Inventory and item collection
• Combat with multiple enemy types
• Cutscenes and story moments
• Boss fights

Movement and collision run through DOM positioning rather than
a game loop on canvas. Every game element is a DOM node with
position, size, and behavior defined by data attributes. The
engine checks overlaps, handles interactions, and updates state
through JavaScript that reads and writes to those attributes.

The WordPress Connection

The engine is built as a WordPress plugin. Game assets are
WordPress custom post types. A character is a post. An area
is a post. An item is a post. The meta fields on those posts
define behavior, position, size, collision, interaction type,
mission triggers, dialogue content.

WordPress handles authentication, the database, the REST API,
media management, and multisite hosting. That is months of
infrastructure that came for free. The plugin adds the game
layer on top.

The hosted platform at orbem.studio runs on WordPress multisite.
Each game gets its own subdomain. Sign up and your game
environment is ready in under 60 seconds without touching
WordPress at all.

The Front End Builder

One of the more interesting engineering problems was building
a front end game editor that runs inside the game itself.

The builder lets creators add, edit, place, and delete game
assets without ever leaving the game. Click to place positioning
works by switching the cursor to a crosshair, clicking anywhere
on the map, capturing the coordinates, and submitting the asset
creation form with those coordinates pre-filled.

Asset changes update instantly without a page refresh. The game
state reflects the change immediately so creators see exactly
what players will see in real time.

Orbem Studio Paint

The engine also includes a built in pixel art tool called
Orbem Studio Paint. Creators draw sprites at any dimension,
export as SVG, PNG, or JPG, and save directly to the WordPress
media library. From there assets go straight into the game
without leaving the browser.

Export and Import

Every game can be exported to a single JSON file that includes
all posts, all meta, all game options, and all image URLs.
Importing to another Orbem Studio install downloads each image
from the source site and rewrites all URLs to point to the
new location automatically.

What I Learned Building This

The biggest surprise was how much a DOM based approach enables
that canvas cannot. CSS animations, CSS transitions, standard
HTML elements, browser accessibility features, all of these
work naturally inside a DOM based game and require significant
additional work to replicate on canvas.

The biggest limitation is performance on large maps with many
simultaneous moving elements. DOM layout recalculation is
expensive and canvas handles large numbers of moving sprites
significantly better. For the types of games Orbem Studio
targets, RPGs, narrative experiences, puzzle games, arcade
games, this has not been a practical problem. For a game
with hundreds of simultaneous moving elements it would be.

The no canvas constraint turned out to be generative rather
than limiting. Every architectural decision flowed from it and
the result is something genuinely different from other browser
game engines.

Try It

The free WordPress plugin is on WordPress.org:
wordpress.org/plugins/orbem-studio

The hosted platform where you can build without WordPress:
orbem.studio

A few games built with it:
orbem.studio/games

I would love to hear what other developers think about the
DOM based approach and whether the trade-offs make sense for
the use cases I am targeting. Happy to answer any technical
questions in the comments.