Where It Started

I've been playing Dungeons & Dragons and other TTRPGs for years. Like a lot of people in that world, I've cycled through the usual virtual tabletop options — each one a compromise between ease of use and visual fidelity. The 2D ones are quick to set up but feel flat. The 3D ones look amazing but are heavy to run and painful to build maps for. I always wanted something in between, and I never found it.

As a Technical Artist, I spend most of my professional life in Unreal Engine — building render systems, managing GPU budgets, writing shaders, designing pipelines. When I started thinking about building a VTT, it stopped being a "wouldn't it be nice" and became a genuinely interesting technical problem. One engine. Two rendering modes. Both camera rigs live at the same time. Every asset ships with both a 3D mesh and a 2D flat version. The runtime swap is a subsystem call. I knew I could build that.

I've been planning this since early 2026 — researching engine architecture, P2P networking without a dedicated server, how to represent map data in a file format that's version-control friendly and Obsidian-compatible. The kind of planning that only makes sense when you're also the artist, the programmer, the architect, and the player at the same table.

Llama VTT is built the way I'd build a production system at a studio — with a proper subsystem architecture, typed C++ classes, a defined source folder structure, and a roadmap. Except this one is mine.

Tech Stack

Engine
Unreal Engine 5.7
Language
C++ + Blueprints
Networking
Epic Online Services (P2P)
Rendering
Dual-mode (Perspective / Ortho)
Environment
HISM + Dynamic Mesh
Map Format
.lvtt (custom JSON)
Integration
Obsidian Vault (.lvtt export)
Status
Pre-alpha — Sprint 1

Core Features

Play Your Way

  • 3D or 2D, your choice — Switch the whole table between cinematic 3D and clean top-down 2D in one button press. No reload, no interruption.
  • Everyone picks their view — You play in 3D. A friend plays in 2D. The GM does both. Same session, same map, any combination.
  • Runs on anything — Full Unreal Engine 5 quality in 3D. Lightweight and fast in 2D — low-spec machines handle it without breaking a sweat.

Zero Setup

  • No server, no fees — Host a session and share a code. Friends join instantly — no accounts, no subscriptions, no port forwarding.
  • Always in sync — What the GM does, every player sees instantly. The map, the tokens, the fog of war — all live.
  • Any device — PC, laptop, eventually mobile. Anyone can join from whatever they have.

Your World

  • Your maps are yours — Maps save to an open format you own. Shareable, editable outside the app, version-controllable. Not locked to a cloud service.
  • Precise grid movement — Tokens snap exactly to the grid. Consistent on every player's screen, every time.
  • Scale without limits — From a single dungeon room to an entire continent. Maps stream seamlessly as you explore.

Your Campaign

  • Obsidian integration — Import NPCs, locations, and encounters from your campaign vault directly into sessions. Your notes become live objects at the table.
  • Full D&D 5e rules — Ability scores, saving throws, spell slots, action economy, and all standard conditions. The rulebook is built in.
  • Built in the open — Public roadmap and devlog. Every feature, every decision, documented. Follow the build.

Why Llama VTT?

Most virtual tabletops make you choose: either you get a flat 2D token-on-map experience (fast to set up, easy for players) or a full 3D scene (immersive, but heavy). Llama VTT doesn't force that choice — the GM builds the map once with dual-mesh assets, and anyone at the table can switch modes on the fly.

It's also built with the assumption that GMs are already living in tools like Obsidian. Rather than duplicating campaign data, .lvtt files are designed to be generated from vault exports — so encounter notes, NPC stats, and location descriptions flow into the VTT without double-entry.

This is a personal project I build alongside professional work — documented publicly because the architecture decisions (HISM baking, render mode subsystems, EOS P2P from scratch) are worth writing about.