Roll & Play — Modular RPG Engine for Discord

Tabletop tools are often disconnected from the place where the game happens

Many online tabletop RPG groups already use Discord for voice communication, text channels, session planning, and community interaction. However, the mechanical parts of the game are frequently distributed across external character-sheet platforms, generic dice bots, documents, spreadsheets, private notes, and system-specific applications.

This fragmentation forces players and Game Masters to constantly move between different tools. Character information becomes duplicated, rolls lose their connection to the relevant sheet, private notes require manual permission management, and Game Masters must maintain NPCs, attacks, inventories, and campaign information through separate interfaces.

Existing Discord bots often solve only one part of this problem. Some provide dice notation but no structured character data. Others are designed for a single RPG system, offer limited customization, or mix interface logic, game rules, and persistence in ways that make extension difficult.

The challenge addressed by Roll & Play is therefore both functional and architectural: provide useful tabletop RPG interactions directly inside Discord while maintaining a modular foundation that can support different systems, rules, interfaces, languages, and future campaign contexts.

Turn Discord into an interactive RPG workspace

Roll & Play was created to reduce the distance between conversation and gameplay. Instead of treating Discord merely as the communication layer around a campaign, the project explores how the platform itself can become an interactive environment for managing characters, NPCs, rolls, attacks, inventories, skills, pets, and personal notes.

The project is guided by a separation between engine and content. The engine provides reusable technical capabilities, interaction flows, rule processing, and modular components. Individual communities, Game Masters, and contributors can then adapt those capabilities to different worlds and tabletop systems.

A second motivation is architectural. RPG engines tend to grow quickly: every new system introduces attributes, skills, roll conventions, sheet structures, permissions, and exceptions. Without explicit boundaries, this variety can create a large and fragile collection of commands.

Roll & Play approaches this problem through domain-oriented Cogs, reusable interface components, dedicated rule-processing utilities, localized content, and separated persistence helpers. The objective is to create a foundation that can expand without turning every new game system into a complete rewrite.

Modular, event-driven, and interaction-oriented

Roll & Play is implemented as an asynchronous Discord application using Python and discord.py. Its architecture separates command routing, interactive presentation, game rules, localization, and persistence into dedicated modules.

Application entry point

The application is initialized in main.py, where Discord intents, logging, environment configuration, extension loading, presence information, and global slash-command synchronization are configured.

The bot loads its functional domains as independent extensions, allowing modules to be added, removed, or maintained without concentrating every command in the application entry point.

Domain Cogs

The cogs directory acts as the command and event layer. Responsibilities are separated into modules for core dice interactions, players, NPCs, personal notes, and administration.

Each Cog handles Discord commands and events for a specific domain. This prevents player-sheet logic, Game Master operations, notes, and generic dice events from becoming a single command controller.

Interactive presentation layer

The view and models directories contain Discord Views, buttons, selectors, and modal forms used to construct interactive workflows.

Player and NPC sheets are divided into smaller components for basic information, attributes, skills, attacks, status values, inventories, advanced configuration, system selection, and dice interactions. These components allow users to navigate and update information without depending exclusively on long text commands.

Rules and service utilities

The utils layer contains reusable logic for dice evaluation, RPG-system rules, player and NPC persistence, Game Master registration, permission checks, embed construction, and locale resolution.

The rules module centralizes supported systems, attribute definitions, skills, and modifier strategies. The dice module processes normal and compound expressions, repeated rolls, advantage and disadvantage, critical results, damage, temporary modifiers, and system-aware attribute checks.

Keeping these operations outside the Discord command layer reduces direct coupling between game calculations and interaction handlers.

Persistence

The current version uses structured JSON files stored in local directories. Player sheets are identified by the Discord user, while NPC data is scoped by server and Game Master. Separate JSON documents maintain Game Master registrations and other state.

This approach keeps the development version lightweight and transparent, but it is not intended as the final persistence architecture for large or distributed deployments. Database migrations, transactional updates, campaign-aware state, backups, and concurrent access remain future architectural requirements.

Internationalization

Translation resources are organized as JSON files under locale-specific directories. Locale resolution uses the Discord interaction or server configuration, while localized command names and descriptions expose Portuguese and English variants.

Architectural direction

The roadmap extends the current modular structure toward isolated campaign contexts, role-based access control, campaign-scoped character state, economy functions, session summaries, audit logs, automated testing, and database migrations.

These capabilities are planned and should not yet be considered part of the current release.

A multi-system character and dice engine inside Discord

The current implementation serves as a practical case study in building an interaction-heavy RPG engine on top of Discord.

Players can create and access interactive character sheets through slash commands and component-based menus. Character information includes system-specific attributes, learned skills, status values, attacks, items, and registered pets. Game Masters receive extended access to character information and a separate set of tools for creating and managing NPC sheets.

The engine currently models rules and attribute structures for six tabletop families: Dungeons & Dragons and Tormenta 20, Ordem Paranormal, Cyberpunk, Skyfall RPG, Vampire: The Masquerade, and Call of Cthulhu. Each system can define its own attributes, skills, and modifier behavior while sharing the same interaction infrastructure.

The dice engine accepts conventional expressions such as 1d20+5, repeated rolls, compound expressions, advantage and disadvantage, critical ranges, attack rolls, damage rolls, temporary modifiers, and multiple attacks. Results are presented through Discord embeds with totals and calculation breakdowns.

Roll & Play also creates private note channels for individual players. Discord permission overwrites restrict these channels to the player, the bot, and authorized Game Masters, allowing session notes and character information to remain inside the server without being exposed to the entire community.

Persistence is currently file-based. Player sheets, NPCs, Game Master registrations, and related information are stored as structured JSON documents. This makes the prototype easy to inspect and run without external infrastructure, while also defining a clear future requirement: a database-backed persistence layer with migrations, campaign scoping, and stronger concurrency guarantees.

The case study demonstrates that Discord interactions can support more than isolated commands. Buttons, selectors, modals, embeds, roles, localized responses, and structured state can be combined into a cohesive tabletop workflow. At the same time, the implementation exposes the architectural challenges that the next versions must address, particularly campaign isolation, persistent data evolution, automated tests, and deployment at scale.