Skip to content
Descent Docs

Descent VTT - Future Frontend Architecture Roadmap (Phase 6+)

Descent VTT - Future Frontend Architecture Roadmap (Phase 6+)

This document serves as a repository for ultra-hardcore frontend optimization strategies and edge-case architectures that fall outside the immediate enterprise scope of the primary whitepaper, but are critical for long-term platform evolution.

1. WebAssembly SIMD128 (WASM-Threads: withdrawn)

Rewritten 2026-08-01 (R2-F-47). The previous version’s premise — that client-side Fog of War would outgrow one worker’s frame budget, to be solved with rayon + +atomics, +bulk-memory WASM threads — no longer holds. ADR-034 makes client LOS/FOW presentation-only (the client smooths the server’s authoritative mask and never computes it), and ADR-052 consequently retires the shared linear-memory arena, the +atomics build, and the worker pool in favour of one geometry worker with private memory. The problem and the proposed solution both went away.

  • SIMD128 — still potentially useful, for different work and on different lanes. The remaining client-side geometry is own-move A* / collision preview over the caller’s disclosed region (ADR-034) plus preparation of mask data for GPU upsampling. Note that ADR-017 mandates fixed-point i32.16 arithmetic, never f32/f64, so the previous description (“4 floating-point numbers simultaneously”) was doubly wrong: any SIMD work here uses integer lanes (4×i32). The speed-up figure previously quoted here was unsourced and is withdrawn per ADR-045’s registry rule — if SIMD128 is adopted, the gain must be a measured entry in the quantity registry.
  • Whether it is worth it at all is now questionable. With FOW removed from the client, the remaining per-frame geometry cost is small (see the capacity recalculation in Open_Items_S1_and_BENCH04.md). SIMD128 should be gated on a measurement showing the geometry worker is actually near a frame-budget limit, not adopted on principle.
  • Backend parallelism needs none of this. The server hosts the same crate natively via a C ABI (§5.3), where rayon is available directly. The previous text said WASM threads would “allow the backend to slice a giant FOW grid into quadrants”, which conflated the two hosts — the backend never runs the WASM build.

2. Accessibility (a11y) & Semantic Shadow DOM Overlay

WebGL and WebGPU <canvas> elements are completely opaque (“black boxes”) to standard screen readers and assistive technologies. An enterprise-grade platform must consider WCAG compliance.

  • Semantic DOM Overlay: The SolidJS UI must maintain an invisible, strictly semantic HTML mirror of the 3D scene (using standard tags like <button>, <ul>, and <section>).
  • ARIA Live Regions (aria-live="polite" or "assertive"): When spatial events occur (e.g., “An enemy moves into your line of sight”, “You rolled a Critical Success”), the Engine dispatches a formatted string to an off-screen ARIA announcer. This ensures visually impaired players can participate fully via keyboard navigation and screen readers, preserving the core conversational spirit of TRPGs.

The semantic mirror is a surface of the visibility model, and this constraint cannot be deferred with the implementation (R2-F-41). The implementation may stay in Phase 6+; the following constraint must be recorded now, because it determines where the mirror gets its data — and that is not a decision Phase 6+ can revisit cheaply.

  1. Build it from the disclosed set, never from the scene graph. §9.2’s authority rule states that entities the server has not disclosed are absent from the client’s data set entirely — never present-but-culled — precisely because a culling step is one patched line from being disabled. A semantic DOM mirror derived by walking the Babylon scene graph would reproduce that failure in a strictly worse medium: screen-reader-accessible DOM is plain text, structured, and requires no client modification to read. Anything retained in the scene graph for rendering convenience but visually culled would become enumerable.
  2. ARIA announcements are visibility decisions. “An enemy moves into your line of sight” is the output of a per-viewer visibility computation; both its timing and its content carry information. Announcements must pass through the same per-viewer filter as the visual path (§8.2), not a parallel one.
  3. Channel ownership. Per ADR-053 the mirror is DOM-facing authoritative state and must be published by the Network Worker, not reconstructed by the Render Worker from its ECS — the ECS legitimately holds world-state content that belongs to the other channel.
  4. Guardrail 7 needs an a11y row (screen-reader / keyboard-only navigation), with defined behaviour rather than a blank cell.

Separately: deferring a11y to “Phase 6+” in a platform positioned as enterprise-grade is a compliance exposure independent of the technical argument above.

3. UGC Developer Experience (DX) & Local Dev Sandbox (HMR)

Rewritten 2026-08-01 (R2-F-40). The previous version of this section stated that “Lit Web Components and strict Zod Schemas guarantee zero-trust security for community mods” and described a sandbox that lets “modders inject their Lit components”. Both are explicitly repudiated by §6.4 / ADR-010: a creator never publishes a custom element definition or any artifact that executes in the main thread’s realm, and Lit / Shadow DOM is a styling boundary, not a security boundary (a shadow root does not restrict document, fetch, localStorage, window.top, or cookies). That text was the surviving fossil of the discarded UGC isolation model that §11’s preamble describes; it is recorded here so it is not re-proposed.

Creator logic executes only inside the QuickJS/WASM PluginWorker (§9.5 Guardrail 5, ADR-040), and creator UI is delivered only as JSON AST descriptors rendered by first-party components (§6.4, tier P3). The DX problem is therefore not “how do modders preview their components” — they have none — but “how do modders see what the first-party renderer will make of their descriptor”.

  • Vite-Based Local Dev Sandbox: The SDK distributes a CLI tool (descent-vtt-cli). npm run dev spins up a local Vite server hosting the first-party JSON AST renderer plus a mocked backend, so the creator sees the real renderer’s output rather than a stand-in.
  • HMR over descriptors, not components: HMR watches the creator’s TS/JS source, re-runs it inside a local QuickJS runtime, and hot-swaps the resulting descriptor. What reloads is data; no creator code is ever loaded into the host page’s realm, in dev or in production. Keeping dev and production delivery identical is the point — a dev path that accepts component injection trains creators to build things the platform will reject.
  • Registration-time validation runs locally too: the CLI applies the same checks the platform applies (§12.2.2 target validation — e.g. rejecting ui.TextField on a Token target; ADR-040 interest-set caps), so a creator hits these errors at authoring time rather than at publish time.
  • Simulated low-end budget: the dev server can impose the Profile C per-frame plugin budget (ADR-040), because a plugin that is fine on the author’s desktop and plugin:deferred on a tablet is otherwise only discovered from user complaints.
  • No SharedArrayBuffer to spoof: the plugin worker receives a per-frame copy into the QuickJS heap (Guardrail 5), and the shared geometry arena was retired entirely (ADR-052). There is no memory bridge on the plugin path to emulate.

4. WebXR Spatial Computing & Dynamic Foveated Rendering

As VR/AR headsets (e.g., Meta Quest 3, Apple Vision Pro) become mainstream, the VTT must adapt from traditional 2D screens to full Spatial Computing environments. Rendering a VTT at 90Hz per eye in 4K resolution requires extreme optimization.

  • Dynamic Foveated Rendering (DFR): By integrating WebXR eye-tracking APIs, the WebGPU render worker dynamically lowers the resolution multiplier for the peripheral vision while keeping the direct focal point at 100% native resolution. This drastically reduces the GPU fragment shader workload, enabling standalone VR headsets to run the VTT without tethering to a PC.
  • Pass-through AR Anchoring: Utilizing WebXR Hit Test and Plane Detection APIs, players can project the 3D VTT map onto their real-world physical table. The engine maps virtual coordinate spaces to physical room anchors, blending the TRPG experience seamlessly with physical reality.

Two interactions to settle before this is scoped (2026-08-01). (1) Mask staleness at 90Hz. ADR-034 makes fog and lighting update at the authoritative cadence — 20Hz, plus the one-tick mask lag from ADR-033. At 90Hz per eye that is 3–4 frames of staleness on the fog boundary, which is far more noticeable in a head-tracked display than on a monitor. Either the presentation-layer smoothing must interpolate the mask boundary over time, or XR needs its own stated tolerance. (2) XR composition is already flagged as non-parity. §2.2’s Renderer Backend Parity Caveat explicitly names “some XR composition paths” as differing between Babylon’s WebGPU and WebGL2 backends, and §2.2’s rule is that unverified features are disabled, not silently degraded. XR × fog presentation therefore needs its own cell in the Guardrail 7 matrix rather than an assumption of availability.

5. MediaDevices Hot-Swapping & Audio Resilience

During long (4-8 hour) TRPG sessions, players frequently experience hardware changes (e.g., Bluetooth headset battery dies, USB microphone gets unplugged). Traditional WebRTC connections crash when the hardware track disappears.

  • Device Observer Pattern: The frontend implements an active listener on navigator.mediaDevices.ondevicechange. When a primary audio input drops, the engine automatically catches the event and triggers WebRTC replaceTrack() to instantly fallback to the system default microphone. This guarantees session audio resilience without requiring the user to refresh the entire VTT page.

Recommended for pull-forward out of Phase 6+ (2026-08-01). This section is the only one in this document that conflicts with nothing, solves a problem that occurs in every long session, and is cheap. It belongs with the Guardrail 7 WebRTC row (voice availability), not in a future-work file.

6. Physical Hardware Integration (WebHID & Gamepad API)

To elevate the Virtual Tabletop experience into a professional studio-grade environment (especially for streamers and hardcore Game Masters), the frontend must integrate with physical peripherals beyond the standard mouse and keyboard.

  • Gamepad API: Support for Bluetooth/USB controllers (Xbox, DualSense) allowing the GM to smoothly pan the 3D camera or execute cinematic fly-throughs, which provides a significantly better viewing experience for audiences compared to erratic mouse dragging.
  • WebHID API: Direct browser integration with macro pads (e.g., Elgato Stream Deck). This allows GMs to bind physical buttons to specific VTT actions (e.g., changing map lighting, triggering monster roars, rolling specific macros) without needing third-party companion software.