Game tools · R&D PoC
DMos: a new use for work already done.
A Dungeon Master's console brought a spatial map, campaign state, a live game, and optional AI atmosphere into one experience. Most of the ingredients were already on the workbench.
Someone else could drive it.
My friend tried the first working PoC from their own computer less than 24 hours after the idea. Getting it into another person's hands was the first milestone.
The longer story starts before DMos. I already had a spatial viewer, a way to execute bounded actions in Valheim, and local AI infrastructure. The new work was deciding how those pieces should behave together, then building a Dungeon Master's interface around them.
That distinction matters to me. The accumulated work made a new idea cheap enough to try with another person.
One small campaign, connected end to end.
- Open the building. The DM sees a three-dimensional structure and can move between its elevations, inspect a territory, and keep the surrounding levels in view.
- Reveal a place. Campaign state records the decision. The player receives the authorized part of the map; unrevealed geometry stays on the server.
- Act in the game. A bounded command can move a Valheim actor or apply the demonstration's environmental event. The bridge reports what it applied.
- Add atmosphere. Player attention can request a generated atmosphere card. An unavailable image service is reported, and the campaign can continue.
The materialization experiment extends that loop to physical places: reviewed plans become a machinery hall and a tunnel network in Valheim, with an inspect and remove/reset lifecycle.
What came from the earlier work.
| Existing piece | Its job in DMos |
|---|---|
| Spatial work | Steward's building geometry, coordinates, and camera model supplied the scene. I adapted the browser rendering to WebGL2 and the display to campaign territories. |
| Game bridge | The existing Creator Session and blueprint mechanisms supplied bounded game actions and physical materialization. |
| Local AI | HEARTH and the image workflow supplied optional atmosphere generation through an existing service boundary. |
| New integration | The campaign gateway, authorized DM/player projections, and interaction design gave those pieces one coherent use. |
My contribution was the system design, integration, and the decisions about what the person at the controls needed to see. I built with AI assistance and kept the acceptance work close to the running system.
The screen is a view of the campaign.
The gateway owns campaign truth and persists accepted changes. The browser, spatial query view, game, and image service each have a narrower responsibility.
That makes the player boundary concrete: hidden territory data never needs to arrive in the player's browser. It also gives each action an inspectable path from request to accepted state to the effect the game actually applied.
As the PoC grew, the same separation carried into campaign outlines, actors, encounters, clocks, and secrets. The UI can change without becoming a second source of authority.
What is demonstrated today.
DMos remains an R&D PoC built around a canonical demonstration building and campaign. Retained browser rehearsals cover the spatial and role-filtered views; the materialization acceptance work records the bounded game construction and reset sequence.
The friend's trial demonstrates that another person could use the PoC remotely. It does not establish general installation support, arbitrary world import, or a production service. The private operating interface is not exposed by this page.
The useful next conversation is about a specific campaign or community need. Those constraints decide which parts should grow.