Action bars, story cards, and the engine underneath them

The previous post was about the VTT engine moving to WebGL. This post is about what that unlocks.

A live session is not just a map. It is a map plus the player surface plus the DM surface plus the realtime layer that ties them together. The map is the part the engine handles. Everything else is the part that sits on top of the engine, and the part that sits on top of the engine is what the players and the DM actually look at and touch during play.

This stretch was about that part.

The shift to PixiJS made the rest possible

The earlier live session view had been built against a different rendering substrate. It worked, but the architecture was constrained by the substrate underneath it. The shift to PixiJS for WebGL changed what was possible to build on top.

WebGL is what the VTT needs to render at session-quality framerates. Real-time tokens, lighting that updates as things move, fog that responds to position, all of it composited fast enough to feel like a live game. None of that was going to scale on the previous runtime. Once the engine moved, everything that sits above it had room to grow.

The shift is also the reason this is a "2.0" rather than a continuation. The substrate change cascaded through the rest of the live session UI, and what came out the other side is closer to the live session experience the platform had been working toward since the campaign manager landed.

The action bar is for players

The action bar is the player-facing surface during a session.

When a player joins a session, the action bar is where their character lives. Their portrait. Their hit points. Their resources. The buttons for the things they do most often during play. The dice they roll. The character sheet, condensed into the surface they need most when the session is actually running.

The thinking is straightforward. A character sheet is a document. Documents are good for prep work, for leveling up, for going through the rules carefully when nobody is waiting on you. They are bad during play. During play, what a player needs is a small set of high-frequency actions: roll an attack, roll a save, spend a slot, take damage, mark a condition. Burying those behind a document is friction. The action bar pulls them to the surface where they belong.

This is the part of the live session UI a player will spend the most time looking at. The map is what they look at to see the world. The action bar is what they touch to act in it.

Story cards stay as the DM's narrative surface

Story cards are the DM's tool for putting a moment of narrative directly in front of the players.

The card sits on the table during play. It can hold the text of a scene, an image, a choice, a question. The DM puts it down when the moment calls for it, the players see it, and the session moves through whatever the card represents. It is not a chat message. It is not a dialog box. It is a real object on the table, with the same persistence and weight as a token or a piece of terrain.

The point of having story cards as their own surface, rather than folding them into the chat or the campaign book, is that narrative moments deserve a different shape than utility moments. A chat message scrolls away. A dialog interrupts. A card stays where the DM put it, until the scene resolves and the DM moves on.

This is also the part of the session UI that benefits most from the realtime work happening underneath. When the DM places a card, every player sees it appear at the same moment. When players interact with the card, the DM sees the result in real time. The card is collaborative the way a real object on a real table is collaborative, because everyone is looking at the same thing at the same time.

The realtime layer is working

The other thing that landed in this stretch is that the realtime data flow is working better than it was.

The action bar updates in real time. The story cards update in real time. The map updates in real time. None of this is new in concept, but in practice the previous architecture had been less reliable than it should have been, and this stretch was when the realtime layer became something I trust during a session instead of something I cross my fingers about.

The technical detail is not the post. The user-facing result is: when something happens at the table, everyone sees it happen, and the lag between someone doing a thing and everyone else seeing the thing is short enough that nobody notices it.

That is what realtime is supposed to feel like.

What the stretch shipped

A live session view rebuilt on top of the new engine. An action bar that gives players the high-frequency surface their character needs during play. Story cards as the DM's way to surface narrative moments. A realtime layer that holds up under actual session conditions.

The platform now has a session experience that does what a session needs to do. The map is real. The player surface is real. The DM surface is real. The realtime layer connects all three reliably.

Fourteen months in, that is enough to play with.