CarmaClouds: Multi-Platform VTT Character Sync Suite

Role: Solo Full-Stack Developer & UX Designer

Timeline: 2024 – Present (ongoing development, currently on hold)

Year: 2024-2026

Client: Personal project / Open source (MIT License)

Status: Active development demonstrating multi-platform integration architecture. RollCloud 85-90% complete, OwlCloud 95% complete, FoundCloud 70% complete. All integrations functional in development but require extensive user testing before public release. Pip2 Discord bot operational as standalone, integration with unified extension in progress. Currently deprioritized to focus on Bluumo (paying client work).

Website: carmaclouds.vercel.app

THE HOOK

Built a 175,000-line multi-platform character synchronization system as a solo developer—browser extensions for Chrome and Firefox, a Foundry VTT module, an Owlbear Rodeo extension, and a Discord bot—solving a gap that no tool in the tabletop gaming ecosystem had addressed: seamless one-click character sync from DiceCloud to every major virtual tabletop.

THE CHALLENGE

CarmaClouds connects DiceCloud V2—a popular D&D 5e character builder—with virtual tabletop platforms like Roll20, Foundry VTT, and Owlbear Rodeo. Think "universal translator for your D&D character"—build once, play anywhere.

The problem:

DiceCloud V2 is a powerful character management tool, but it exists in isolation. Players spend hours building detailed characters with stats, spells, features, and equipment, then have to manually re-enter everything when they sit down at a virtual table. The tabletop ecosystem had:

• Zero interoperability between DiceCloud and any VTT platform

• Manual re-entry of 100+ data points per character (ability scores, skills, spells, equipment, features)

• Platform lock-in — switching from Roll20 to Foundry meant rebuilding characters from scratch

• No cloud persistence — character data lived only in the browser or in DiceCloud, with no bridge between them

• Fragmented workflows — players juggling multiple tabs, copying numbers by hand, making transcription errors that affected gameplay

The community needed:

• One-click character sync from DiceCloud to any VTT

• Cloud storage enabling cross-device access

• Platform-specific data mapping (each VTT structures character data differently)

• Real-time updates when characters change in DiceCloud

• Automated roll modification and D&D rule enforcement

• A solution that worked across Chrome, Firefox, and multiple VTT platforms simultaneously

THE APPROACH

Phase 1: Core Extension Architecture (2024)

Foundation Building:

• Analyzed the DiceCloud V2 API (GraphQL + Meteor DDP protocol) to understand available character data

• Mapped data structures across Roll20, Foundry VTT, and Owlbear Rodeo to identify transformation requirements

• Designed the adapter pattern architecture: one core extraction pipeline feeding platform-specific adapters (RollCloud, FoundCloud, OwlCloud)

• Built Chrome Manifest V3 and Firefox Manifest V2 extensions simultaneously with shared core logic

• Implemented Supabase cloud backend with PostgreSQL, Row Level Security, and real-time subscriptions

Initial Platform: RollCloud (Roll20)

• Content script injection for character sheet overlays

• Roll tracking and action announcements

• Draggable in-page UI

• Status: 85-90% complete, functional but requires user testing

Phase 2: Platform Expansion (2024-2025)

Built integrations for multiple platforms as a solo developer:

OwlCloud (Owlbear Rodeo):

• Native Owlbear extension with character popovers

• Scene token creation

• HTTP API communication

• Status: 95% complete, needs extensive user testing at scale

Pip2 (Discord Bot):

• 20+ slash commands for dice rolling

• Character management and spell casting

• Initiative tracking and health management

• Status: Operational as standalone bot, not yet integrated into unified extension

Cloud Infrastructure:

• Supabase storage with real-time sync

• Edge functions for API operations

• Character portrait storage buckets

Tech Stack:

JavaScript | TypeScript | Node.js | ESBuild | Supabase | PostgreSQL | Next.js | React | Discord.js | Meteor DDP | Chrome/Firefox Extension APIs | Foundry VTT API | Owlbear Rodeo API

Phase 3: D&D Rule Engine & Intelligence (2025)

Beyond simple data transfer, built intelligent game rule processing:

• Automatic roll modification — detects missing ability modifiers and proficiency bonuses, applies them intelligently

• Critical hit detection — supports expanded crit ranges (Champion Fighter 19-20, Superior Critical 18-20)

• DiceCloud trigger parsing — reads trigger properties and applies effects like Arcane Firearm

• Class feature edge cases — handles Hexblade's Curse, Kensei Weapons, Divine Strike, and other features that add proficiency to damage

• Finesse weapon detection — automatically uses higher of STR or DEX

• Spell attack inference — detects attack rolls from spell descriptions when not explicitly marked

Phase 4: Foundry Module Deep Integration (2025-2026)

FoundCloud (Foundry VTT) - 70% Complete:

Building comprehensive D&D 5e importer with Foundry-specific architecture:

• Character import handling ability scores, skills, spells, equipment, features, traits, and currency

• Class Item creation (Foundry derives level/proficiency/hit dice from embedded class Items, not flat properties)

• Custom character sheet with dark mode support, color theming, and circular portrait cropping

• Supabase storage upload for character portraits

• Skill name translation layer (DiceCloud uses animalHandling, Foundry uses ani)

• Save proficiency mapping across all six ability saves

• Spell data with full details (level, school, components, description)

Status: Core architecture complete, significant integration work remaining before user testing.

Current Status: On Hold for Bluumo

Why the pause: This is MIT-licensed open source software. While the technical challenges have been incredibly valuable learning experiences, prioritizing revenue-generating work (Bluumo marketplace) is necessary. CarmaClouds demonstrates multi-platform integration architecture and D&D rule engine complexity, but requires extensive real-world user testing to reach production quality—testing that's difficult to conduct solo and time-intensive to coordinate.

What's needed before release:

• Extended user testing across all three VTT platforms with real gameplay scenarios

• Edge case discovery from actual player usage

• Performance optimization based on real-world data volumes

• Pip2 integration into the unified extension

• Final polish on all three adapters (RollCloud, OwlCloud, FoundCloud)

• Documentation and onboarding materials

PLATFORM SCALE

Metric Count Lines of code 175,000+ Platform integrations 4 (in development) Browser builds 2 (Chrome + Firefox) Discord bot commands 20+ D&D edge cases handled 50+ VTT platforms targeted 3 Reusable components 40+ Custom parsers 3 (Roll20, Foundry, Owlbear) Active development time 2 years+

KEY FEATURES BUILT

Browser Extension (Chrome & Firefox) - 🚧 85-90% Complete

• One-click DiceCloud character sync via injected UI button

• Cloud storage with Supabase for cross-device character access

• Multi-platform push — send characters to Roll20, Owlbear Rodeo, or Foundry VTT

• Auto-login supporting Google Sign-In, username/password, and all DiceCloud auth methods

• Real-time character updates via Supabase subscriptions

• Settings panel with account management and UI position reset

• Character selection and switching between multiple synced characters

Roll20 (RollCloud) - 🚧 85-90% Complete

• Complete character import (stats, skills, spells, equipment, features)

• Draggable character sheet overlay rendered in-page

• Automatic roll modifier application (ability mods, proficiency, class features)

• Critical hit detection with expanded crit range support

• Action announcements and roll tracking

• Discord webhook integration for roll notifications

• Two-way sync (experimental) — HP, spell slots, and ability uses back to DiceCloud

Foundry VTT (FoundCloud) - 🚧 70% Complete

• D&D 5e system integration with class Items, save proficiencies, and skill mappings

• Custom character sheet templates with dark mode and color theming

• Character import dialog in the Actors sidebar

• Portrait circular cropping and Supabase storage upload

• Spells with full details (level, school, components, description)

• Equipment and inventory with proper categorization

• Automatic module updates via manifest URL

Owlbear Rodeo (OwlCloud) - 🚧 95% Complete

• Native Owlbear extension installed via manifest URL

• Character sheet popover display

• Scene token creation from character data

• Character trait popups and switching

Discord Bot (Pip2) - ⚠️ Standalone, Not Yet Integrated

• 20+ slash commands: /roll, /character, /cast, /actions, /heal, /damage, /rest, /spells, and more

• Initiative tracking and turn management

• Spell slot management and recovery

• Status: Operational as standalone Discord bot, integration with unified extension in progress

Marketing Website - ✅ Complete

• Next.js 14 + React 18 + Tailwind CSS

• Platform-specific landing pages (RollCloud, OwlCloud, FoundCloud, Pip2)

• Download distribution for extension packages

• Foundry module manifest hosting

• Deployed on Vercel

TECHNICAL CHALLENGES SOLVED

Challenge 1: DiceCloud's Non-Standard API

Problem: DiceCloud V2 uses a real-time Meteor DDP protocol, not a standard REST API. Character data arrives as raw variables and properties that need complex interpretation.

Solution: Built a custom Meteor DDP client with request queueing to prevent API spam, and a multi-stage parsing pipeline:

// Three-stage parsing architecture
parseForRollCloud()    // Extracts generic D&D data
parseForFoundCloud()   // Maps to Foundry-specific structures
parseForOwlCloud()     // Adapts for Owlbear data model

// Platform-specific adapters handle final formatting

Result: Single DiceCloud character parsed once, transformed for each platform's unique requirements.

Challenge 2: Platform-Specific Data Structures

Problem: Each VTT platform structures character data completely differently. Roll20 uses character attributes, Foundry uses embedded Items and system-specific schemas, Owlbear has its own data model.

Solution: Designed an adapter pattern with a shared core extraction layer feeding platform-specific transformers:

// Adapter pattern architecture
DiceCloudCharacter 
  → CoreParser (generic D&D data)
    → RollCloudAdapter (Roll20 attributes)
    → FoundCloudAdapter (Foundry Items)
    → OwlCloudAdapter (Owlbear format)

Each adapter (RollCloud, FoundCloud, OwlCloud) consumes the same parsed data but maps it to the target platform's expected structure.

Result: Adding new platforms requires building only the adapter, not touching core parsing logic. This architecture proved its value when implementing the third platform significantly faster than the first.

Challenge 3: Chrome vs. Firefox Extension APIs

Problem: Building a single extension for both Chrome (Manifest V3 with service workers) and Firefox (Manifest V2 with background scripts) with divergent API surfaces.

Solution: Custom ESBuild pipeline that compiles shared source code into platform-specific builds:

// Build configuration
builds = [
  {
    platform: 'chrome',
    manifest: 'v3',
    output: 'dist-chrome/',
    features: ['service-worker', 'offscreen-documents']
  },
  {
    platform: 'firefox', 
    manifest: 'v2',
    output: 'dist/',
    features: ['background-scripts', 'browser-api']
  }
]

Result: Single codebase compiles to dist/ for Firefox and dist-chrome/ for Chrome, handling API differences at build time.

Challenge 4: Foundry's Class Item Requirement

Problem: Foundry VTT derives class name, level, proficiency bonus, and hit dice from embedded Items of type "class" — simply setting system.details.level does nothing. The character sheet won't render correctly without proper class Items.

Solution: Built explicit class Item creation in the importer:

// Create Foundry class Item with proper structure
const classItem = {
  name: characterClass.name,
  type: "class",
  system: {
    identifier: characterClass.name.toLowerCase(),
    levels: characterClass.level,
    hitDice: "d10", // Class-specific hit die
    proficiencyBonus: Math.floor((characterClass.level - 1) / 4) + 2
  }
};

await actor.createEmbeddedDocuments("Item", [classItem]);

Result: Characters import with full class progression, hit dice, and proficiency calculations working correctly.

Challenge 5: D&D 5e Edge Case Complexity

Problem: D&D 5e has hundreds of edge cases in roll modification — finesse weapons, class features that add proficiency to damage, expanded crit ranges, conditional triggers.

Solution: Built a modular edge case system (class-feature-edge-cases.js) with pattern matching:

// Edge case patterns
const edgeCases = {
  "Hexblade's Curse": {
    pattern: /hexblade.*curse/i,
    effect: (roll) => roll.addBonus(proficiencyBonus, "Hexblade's Curse")
  },
  "Divine Strike": {
    pattern: /divine strike/i,
    effect: (roll) => roll.addDamage("1d8", "radiant")
  },
  "Improved Critical": {
    pattern: /improved critical|champion/i,
    effect: (character) => character.critRange = 19
  }
};

Features include:

• Generic trigger parsing from DiceCloud property descriptions

• Intelligent modifier application that detects what's missing from roll formulas

• Finesse weapon detection (automatically uses higher of STR or DEX)

• Spell attack inference from descriptions

Result: Automatic roll calculations without manual math during gameplay—when fully tested and deployed.

Challenge 6: String Matching False Positives

Problem: Race detection via substring matching caused false positives — "tiefling".includes("elf") returns true, incorrectly applying elf racial features.

Solution: Replaced substring matching with word boundary regex patterns:

// Before: False positives
if (race.toLowerCase().includes("elf")) { ... }

// After: Exact word matching
if (/\belf\b/i.test(race)) { ... }

Result: Prevented substring collision across all racial feature lookups throughout the codebase.

Challenge 7: Build Automation and Deployment

Problem: A stale ZIP file once caused confusion about which version was being distributed.

Solution: Automated ZIP generation in the build script:

// Build process
1. Compile TypeScript → JavaScript (ESBuild)
2. Generate platform-specific manifests
3. Copy assets and icons
4. Automatically create dist.zip and dist-chrome.zip
5. GitHub Actions uploads to releases on tag push

Result: Eliminated deployment errors. Every release guarantees fresh builds.

THE RESULTS

Technical Achievements

• 175,000+ Lines of Code: Complete multi-platform system architecture built and maintained as a solo developer

• Four Platform Integrations: Adapters built for Roll20, Owlbear Rodeo, Discord, and Foundry VTT (70-95% complete)

• Two Browser Builds: Chrome MV3 and Firefox MV2 from a single codebase with automated build pipeline

• Zero-to-One Architecture: Created adapter pattern system for a tool category that didn't exist — no other solution bridges DiceCloud to VTT platforms

• Intelligent Rule Processing: Built D&D 5e rule engine with automatic roll modification, crit detection, and 50+ class feature edge cases

• Cloud-Native Backend: Supabase architecture with RLS security enabling cross-device character access and real-time sync

• Full Product Suite: Extension framework, VTT modules, Discord bot, marketing website, and automated build/deployment pipeline

Learning Value

• Adapter Pattern Mastery: Demonstrated platform-agnostic core logic with platform-specific adapters, proving scalability when adding third and fourth integrations

• Multi-Platform Browser Extensions: Solved Chrome MV3 vs Firefox MV2 divergence through build-time abstraction

• Complex Data Transformation: Built three-stage parsing pipeline handling Meteor DDP → generic D&D → platform-specific formats

• D&D Rule Engine Complexity: Implemented 50+ edge cases showing that production tools require handling real-world gameplay interactions, not just generic data sync

Why It's On Hold

Business Reality: This is MIT-licensed open source software competing with paid work. While the technical challenges have been valuable learning experiences and demonstrate multi-platform integration architecture, the project requires extensive real-world user testing that's difficult to conduct solo and time-intensive to coordinate. Prioritizing Bluumo (paying client work) is necessary to pay bills.

What's Been Proven: The adapter pattern architecture works, the D&D rule engine handles complex edge cases, and the technical foundation is solid. What's needed is time for user testing, iteration, and polish—resources that are currently allocated to revenue-generating work.

KEY LEARNINGS

Adapter Patterns Scale: Designing platform-agnostic core logic with platform-specific adapters made adding Foundry VTT support dramatically faster than building Roll20 integration from scratch. The pattern proved its value when adding the third and fourth platforms. This architecture decision was the right call.

Edge Cases Are the Product: The difference between a demo and a real tool is handling Hexblade's Curse, finesse weapons, expanded crit ranges, and the hundreds of D&D 5e interactions players actually encounter. Generic "character sync" is easy; accurate "character sync that gets the math right" is the actual product—and requires extensive real-world testing.

Browser Extension APIs Diverge: Chrome MV3 and Firefox MV2 have fundamentally different architectures (service workers vs. background scripts). Planning for both from day one prevented painful rewrites. The ESBuild abstraction layer was essential and saved months of potential rework.

Build Automation Prevents Deployment Bugs: A stale ZIP file once caused confusion about which version was being distributed. Automating ZIP generation in the build script eliminated an entire class of deployment errors.

Real-time Sync Changes Expectations: Once users experienced instant character updates via Supabase subscriptions, any delay felt like a bug. Real-time features set a new baseline for what users expect from modern tools.

Data Transformation is Underestimated: The parsing pipeline from DiceCloud's raw variables/properties to each VTT's expected format is the most complex and error-prone part of the system — more so than any UI work. Getting Roll20 attributes vs. Foundry Items vs. Owlbear format all correct required deep understanding of each platform's data models.

Solo Development Has Limits: Complete architectural control and instant decision-making, but every edge case, every platform quirk, and every user-reported bug falls on one person. More critically: extensive user testing across three VTT platforms with real gameplay scenarios is extremely difficult to conduct solo and time-intensive to coordinate.

Open Source vs. Paying Work: While passion projects demonstrate technical capability and problem-solving, they don't pay bills. Prioritizing revenue-generating client work (Bluumo) over MIT-licensed open source is a necessary business decision, even when the technical work is interesting and valuable.

Testing at Scale Requires Users: You can build 175,000 lines of code solo. You cannot easily test a multi-platform character sync tool solo—it requires real players, real campaigns, and real edge cases that only emerge during actual gameplay.

WHAT'S NEXT

When Development Resumes

• Complete user testing across all three VTT platforms (Roll20, Owlbear Rodeo, Foundry VTT)

• Pip2 integration into unified extension

• Final polish on all adapters (15%, 5%, and 30% remaining respectively)

• Performance optimization based on real-world usage data

• Chrome Web Store & Firefox Add-ons official publication

• Documentation and onboarding materials

Potential Future Features

• Enhanced Two-Way Sync: VTT changes (HP, spell slots, conditions) back to DiceCloud in real-time

• Additional VTT Platforms: Fantasy Grounds, Shard Tabletop, Astral (community requests)

• Automated Character Updates: Detect DiceCloud changes and push to VTT automatically

• Public API: Third-party integration endpoints

• Plugin Architecture: Community-contributed platform adapters

Current Priority

Bluumo Launch: Focusing on production marketplace platform (paying work) before returning to open source passion project.

Website: carmaclouds.vercel.app

GitHub: github.com/CarmaNayeli/carmaclouds

Tech Stack: JavaScript, TypeScript, Node.js, ESBuild, Supabase, PostgreSQL, Next.js, React, Tailwind CSS, Discord.js, Chrome Extension APIs, Firefox WebExtension APIs, Foundry VTT API, Owlbear Rodeo API, Meteor DDP, Vercel

Key Achievement: Built a 175,000-line multi-platform character synchronization system as a solo developer demonstrating adapter pattern architecture, D&D 5e rule engine complexity, and cross-platform browser extension development—creating an entirely new product category in the tabletop gaming ecosystem. Currently at 70-95% completion across four platform integrations, on hold to prioritize revenue-generating work (Bluumo marketplace).