rpg.actor is a way for players and masters of various roleplaying game systems to store, update, and validate important aspects of their characters like stats and sprites in a public way that allows for cross-compatible use.

Through it, users may self-store elements central to their roleplaying experiences using the AT Protocol data ecosystem. By signing in with a Bluesky handle (or any other personal data server), one can manage their character sheets and enable a range of interoperable features that allow seamless use across different game systems.

Core Concepts

Each record type follows a specific lexicon that assures interoperability across different games or services, all held within each user's own Personal Data Server (PDS) and publicly accessible through the AT Protocol.

You are a character (always have been), and rpg.actor lets you store, update, and share your own stats, sprites, and more in your own personal record that can work across multiple games, regardless which systems you use.

Because these character sheets are stored through the AT Protocol, they are portable and public. This means that you can login to any compatible experience with your existing @actor.handle and continue your adventures or customize to your preferences, with full knowledge of the wizard, warrior, or whatever you really are!

Think of it like a public database of adventurers you can choose to be part of, which can remember the spells, inventory, and more that matter to you, across different kinds of games both online, and offline.

Your Character Stats

Your character details are held in an actor.rpg.stats record, stored in your own Personal Data Server.

This record can contain stat blocks for any number of systems simultaneously, allowing you to have consistent representation across different games. There's native support for popular systems like Dungeons & Dragons, as well as digital formats like for RPG Maker MZ, or even your own crazy custom system all in one place.

Stats can be edited directly through the rpg.actor interface and save directly to your PDS, updating your stats across any games that use it. Likewise, (if you permit) supporting games can update your progress automatically and feed your character's growing legacy. You are always in control of these records and will always be able to reshape, remove, or rectify them however you see fit. Because your records are sovereign, you retain authority.

"Great!" she says, "I'll make myself an unstoppable LVL 999 Space Wizard!" — Go ahead. It's your character.

Part of what makes the rpg.actor ecosystem amazing is the way that Masters of various games can check and validate your records for their campaigns with their own records, to make sure you fit well in their worlds. 

Ultimately, these are your characters and you will always stay in control, but playing nice with others and building upon shared experiences in cooperative ways is what good roleplaying has always been about.

Your Character Sprite

Each actor can have a sprite associated to it through an actor.rpg.sprite record which can work alongside their character sheets to provide a visual representation in games where that's useful.

Currently, these sprites follow a general standard (based on RPG Maker MZ) for wide compatibility. The default format is a 144 × 192 pixel PNG using a 3-column, 4-row grid, but the schema can support custom dimensions. 

These sprites appear on rpg.actor profiles and are available to use in services that reads from your PDS, meaning that any compatible games can allow you to login with your @actor.handle and instantly appear as you wish!

Whatever sprite you use, be mindful of copyright and ethical use. See our terms of service for the full breakdown.

Players are capable of hosting their own character sheets through an actor.rpg.stats records. Nobody but the player themselves can edit these records, which is a core concept behind the autonomous nature of this system.

Masters however can validate the sheets using an actor.rpg.master record that references the user specifically, and declares the whether or not the stats are valid within the context of their campaign. This can be done either manually or systematically, allowing for verification of player records and decentralized agreement for stats.

This dual-record system allows for characters and worlds to be managed autonomously by those who should be in control of them, while still allowing for assured compatibility and approval within worlds that scale. Whether your campaign has two characters or two thousand, the validation records can track and manage fair play for all.

Validation Types

Different campaigns require different levels of authority, and the .master records can accommodate varying levels of trust / strictness to adhere the validation. Whether you want to build a rigid tournament system with zero editing tolerance, or an open free-form experience with no cares at all, both can be managed while keeping coherent reference to which players a Master considers worthy of connective play in their worlds.

Validation records may also hold a campaign name, to keep players organized across different groupings.

Staying in Sync

When a validations match a player's current stats, their sheet will show "Approved by: @master.handle" to link them with the approving Master. If the player edits something to break validation, the approval disappears until the records are re-validated, or the player reverts their changes to the approved state.

Players can use the Check Masters button to see every validation that references their character, and quickly adopt the stats professed by the .master record as they wish. This is handy for easy recovery, campaigns with controlled levelling, or for switching states between different session configurations dictated by the Masters.

With rpg.actor, players can log into your RPG Maker game with their Bluesky handle and bring their character along, complete with stats and sprite. The data lives in their own AT Protocol repository, so there's no server to run and no save files to manage. A player's progress can follow them between games automatically.

The system works through keyed RPG Maker MZ values within their actor.rpg.stats record that can persist outside your game files, and follow the player into other experiences. By authenticating into your game with an app password, players can permit games to download, modify, and add new values to these records.

Stats & Sprites

Each player can store values relevant to your RPG Maker MZ games through the dedicated rmmz key inside their actor.rpg.stats record. These map directly to the standard in-engine actor parameters:

Sprites are also stored as standard RMMZ character sheets (144×192 PNG, 48×48 frames, 3×4 grid) through player actor.rpg.sprite records. These can be downloaded live from their PDS and load directly into your game for either main characters, or connected NPCs that can be updated from beyond the confines of update patches.

When a player levels up or their stats change in your game, those changes can be pushed back to their personal records so long as the player authorizes the game to do so, allowing other compatible games to keep continuity.

NOTE: These connections are in early beta and are still in testing phases and should not be relied on as the sole record state (yet) as engine overwrites and various data-write process may not yet work well for your games.

Everything on rpg.actor is built upon three core lexicons. These schema definitions describe how character data is structured inside user's AT Protocol repositories. Our character compendium simply indexes and displays it.

Any ATproto enabled service can read or write the same records, and leverage the user's character if permitted.

The raw schemas for each lexicon are available here:

• actor.rpg.stats.json — character stats
• actor.rpg.sprite.json — sprite sheets
• actor.rpg.master.json — master validations

API Access

We offer a handful of public endpoints for querying the registry, rate limited to 60 requests per minute per IP.

Working with Records

Every player's data lives in their own Personal Data Server. Reading it is a straightforward getRecord call via reference through the user's DID and declaration of which collection you're after:

GET {pds}/xrpc/com.atproto.repo.getRecord
  ?repo=did:plc:...
  &collection=actor.rpg.stats
  &rkey=self

The user's DID can typically be resolved through their @actor.handle through the plc.directory, which will also provide you their PDS endpoint. With that information, their actor.rpg.* records can be easily located.

Writing follows the same idea, only requiring authentication. Any service that secures user authorization through either OAuth or an app password can then use putRecord to add or update actor.rpg.* records.

Important Notice: putRecord replaces the whole record. If a player has .stats for multiple systems and you do not fetch to merge changes within it, you will only write part of their record and other systems may disappear in the overwrite. Always fetch first, merge your changes in, then save the whole thing back.

The AT Protocol Lexicon Guide covers the rest of general work with open schema in detail.