Case study
TableTopGames
A modular digital workspace for tabletop roleplaying campaigns.
TableTopGames — game portal
Role
Product Designer, UX Designer, Frontend Developer, System Architect, Full-stack Developer, Project Owner
Year · Status
2026 · In active development
Stack
Users
Constraints
- — one shared account system across unrelated rule sets
- — master and player need different levels of access to the same session
- — legacy character-sheet code that can't be rewritten wholesale mid-project
- — session-critical data (HP, resources, scenes) must survive refreshes and reconnects
Problem
Traditional VTTs scatter a session across too many tools
Running a tabletop campaign online usually means stitching together a character sheet in one tab, a virtual tabletop in another, a rules PDF somewhere else, and notes in a third app entirely. None of it talks to each other, and none of it accounts for the fact that a Game Master and a Player need fundamentally different views of the same session.
On top of that, every game system has its own logic. A tool built around one ruleset tends to either ignore every other system, or flatten all of them into a lowest common denominator that fits none of them well.
Goals
What the platform needs to do
- Bring campaign materials — sheets, scenes, notes, rules — into one place
- Give the Game Master a real console, not just a bigger character sheet
- Keep Master and Player views separate without duplicating the codebase
- Support genuinely different game systems without forcing a shared data model onto all of them
- Stay extensible enough that adding a new game system doesn't mean rebuilding the platform
Core user flows
Running and joining a session
Game Master
Player
Information architecture
One platform, several game systems
- Platform
- Shared infrastructure
- Campaign hub
- Game systems
- Vampire: The Masquerade V5
- Pathfinder 2
- Modules
- Character sheets
- Table
- Chat
- Music
- Journal
- Rules reference
- Media library
Important design decisions
Choices that shaped the product
01
Separate the platform from the game systems
Shared account, room and module infrastructure lives independently of any single ruleset, so Vampire: The Masquerade and Pathfinder 2 can each keep their own mechanics without either one shaping the platform's core.
02
Split the Master and Player interface, not just the permissions
Rather than hiding elements behind a permission flag, the Master console and Player view are distinct surfaces built for different jobs — running a scene versus playing a character.
03
Layer the game table
Scenes, tokens, fog and background are separate layers, so the Master can prep a scene without players seeing it assembled before it's ready.
04
Keep prep material out of view until it's needed
Off-table tokens, alternate scenes and spare assets can sit outside the visible play area, ready to bring in without breaking the session.
05
Support more than one character per player
Multi-character play — companions, retinues, second characters — is a first-class case, not a workaround.
Technical architecture
Infrastructure → Hub → Game Systems → Modules
The project is migrating toward a layered model that keeps game-specific logic isolated from shared platform code.
01
Infrastructure
Low-level shared contracts underlying every room and session.
02
Hub
Game-neutral chronicle, module and system registry — the switchboard between systems and modules.
03
Game Systems
Rules engines per game — currently VTM5 and Pathfinder 2 — each owning its own mechanics.
04
Modules
Feature areas shared across systems: table, chat, music, journal, rules reference.
Iterations
How the product has changed
01
From one monolithic Vampire app to a multi-system platform
The project started as a single game's toolset and was restructured so a second, unrelated ruleset (Pathfinder 2) could be added without forking the codebase.
02
Extracting the table into its own module
Scene, token and layer logic moved out of page-level code into a dedicated table module with its own data layer, API and components.
03
Building a real Master console
Early on, the Master used the same views as players with a few extra buttons. The console is now a dedicated surface, including a detached second-screen layout for streaming or a second monitor.
04
Keeping the legacy character sheet alive during the rebuild
The original Vampire sheet still runs as-is inside the new shell rather than being rewritten in one risky pass — new features are built around it while it's gradually migrated.
Final result
The platform today
Game portal — system selection
Master console — running a scene
Character sheet — Pathfinder 2
Challenges
What's genuinely hard about this project
The biggest challenge is running a live migration: the legacy Vampire sheet has to keep working for real games while the platform underneath it changes shape. That rules out any approach that requires a clean rewrite in one pass.
Supporting two rule systems that don't resemble each other at all — Vampire's discipline mechanics and Pathfinder 2's structured character-builder — keeps testing the boundary between 'platform' and 'game system,' and that boundary has moved more than once as the project grew.
Reflection
Where this stands
What's working
The Master/Player split and the layered table hold up well under real play, and the platform has absorbed a second, very different game system without a rewrite.
What still needs work
The legacy sheet migration is incomplete, and the boundary between shared modules and game-specific logic still needs tightening as more systems get added.
What this project taught
Separating 'platform' from 'game system' has to be a decision made early and revisited constantly — it's the one architectural call that everything else depends on.
Next project
Rena Companion →
An offline iPad companion that turns a complex tabletop character into a fast, visual interface for live play.