Raids, Skills and Campaigns: The RPG Design DNA of DCENT_Pool

Release status: DCENT_Pool is being prepared for public release. Follow or inspect the DCENT_Pool GitHub destination for release status. Do not assume the complete pool, game, dashboard, or self-hosting documentation is public until it appears there.

Independence notice: DCENT_Pool is an original D-Central project. It is not affiliated with, endorsed by, sponsored by, or derived from Blizzard Entertainment, Jagex, Wizards of the Coast, or their games. The references below identify broad design lessons from games the project creator played; no protected characters, worlds, artwork, music, logos, or story material are used.

Every new genre begins with a familiar comparison that eventually stops being sufficient.

DCENT_Pool began with experiences many role-playing players already know: coordinating roles for a large MMO encounter, watching repeated actions become mastery in RuneScape, and sitting around a tabletop while players declare what they want to do and a shared rules system resolves what happens next.

Those influences explain the shape of the project. They do not explain its boundary.

DCENT_Pool is designed as an MMORPP—Massively Multiplayer Online Role-Playing Pool. Players choose objectives in a persistent fictional world. Real Bitcoin mining hardware supplies the work behind eligible actions. Bitcoin blocks advance the world's core clock. The pool keeps the fictional results separate from Bitcoin payouts and probability.

The result is not a World of Warcraft expansion, a RuneScape server, or a Dungeons & Dragons setting. It is an original system that asks what happens when the most durable parts of those play traditions meet physical proof of work.

Lesson one: MMO roles turn throughput into teamwork

Large online encounters become memorable when success depends on more than a single damage meter.

World of Warcraft's official class page identifies distinct combat roles such as tank, healer, and damage. Its official guild material emphasizes finding groups by activity and needed roles, then contributing individual and group activity toward shared advancement. The important design lesson is not a particular class name or boss. It is interdependence.

A group becomes a party when members need one another for different reasons.

Bitcoin mining creates an obvious measure of throughput: hashrate. A game built carelessly on top of mining would turn every encounter into a single question—who brought the largest machine? That would be a leaderboard, not a role-playing world.

The MMO influence suggests a broader design:

• A high-throughput miner can contribute intense work to a time-sensitive objective.
• A low-power miner with reliable uptime can sustain a long-running support function.
• A scout can direct future work by revealing useful information.
• A builder can turn accumulated effort into persistent infrastructure.
• A logistics player can make distant effort arrive where it matters.
• A guild coordinator can combine machines and intentions that would be ineffective alone.

The physical difference between miners remains real. The design does not pretend identical contribution. It creates multiple problems so raw throughput is powerful without being the only form of agency.

That is the raid-design lesson translated into proof of work: composition should matter without falsifying contribution.

Lesson two: skilling turns repeated action into identity

RuneScape's official skills guide describes a clear progression loop. Performing actions associated with a skill earns XP; XP raises the skill level; higher levels unlock new activities, equipment, locations, and quests.

The elegance is in the connection between repetition and identity. A player becomes a miner, crafter, cook, explorer, or combat specialist because of what they repeatedly choose to do. Long-term action leaves a visible record.

Bitcoin mining is already repetitive at an incomprehensible scale. An ASIC performs vast numbers of hash attempts without human input. But those hashes are not RPG experience points, and treating each hash as an individual game action would produce meaningless numbers.

The pool offers a more useful abstraction: accepted shares. A pool can set a lower target than the Bitcoin network so a miner regularly submits evidence of contributed work. Difficulty-normalized accounting can then provide a consistent basis for a fictional effort meter.

The important word is basis. Game progression can interpret accepted work, but it must not rewrite what that work means on the Bitcoin plane:

• An accepted share normally is not a Bitcoin block.
• Accumulating shares does not make a future block inevitable.
• Fictional XP does not increase the probability of the next hash.
• A level is not a claim on a payout.

Within those boundaries, skilling suggests rich possibilities. Repeatedly directing eligible work to exploration can build a history as a scout. Supporting construction can create a visible builder identity. Long-term participation can unlock new choices without granting a hidden advantage in Bitcoin mining.

The world can remember what the player did, not merely how much hashrate the player owned.

DCENT_Pool should not copy RuneScape's skill names, icons, world, quests, interface, formulas, or content. The transferable lesson is the action → experience → mastery → new-choice loop, an idea implemented through original terminology and mechanics.

Lesson three: tabletop play separates intent from resolution

The official Dungeons & Dragons Basic Rules describe a recurring pattern: the game master describes the environment, players describe what their characters want to do, and the rules guide the resolution when an outcome is uncertain.

That separation between intent and resolution is essential to DCENT_Pool.

A player can declare, "Direct my work toward the road," "Scout this area," or "Defend that position." The declaration does not create the result. It names where future eligible work should be applied. The mining hardware supplies work; the pool validates it; a versioned ruleset determines the fictional state transition; Bitcoin blocks determine when block-timed events advance or resolve.

The dashboard is therefore closer to an intent sheet than an action-energy generator. Clicking "build" should not conjure materials. Typing a command should not create boss damage. The interface chooses the purpose; mining supplies the force.

There is also a campaign-history lesson. Tabletop groups remember decisions because someone narrates and records what happened. A persistent MMORPP can preserve a chronicle indexed by block height. The world becomes the accumulated result of many parties' intentions under shared rules.

Bitcoin is not the Dungeon Master. It cannot interpret a clever speech, negotiate a moral compromise, or improvise an encounter. It can provide a public ordering of block events and data for deterministic resolution. The realm software still owns the fictional rules and state.

That is a narrower claim than "D&D on Bitcoin," and a more interesting one.

The new ingredient: physical action energy

The three traditions can be summarized like this:

None of those elements is unprecedented alone. The proposed combination is the design claim:

A role-playing pool in which real proof of work supplies the fictional action budget and Bitcoin block height supplies the world clock.

That is what makes the system physically bounded.

It also explains why the project should resist the phrase "gamified mining." Gamification usually adds points, badges, and leaderboards to an activity whose underlying structure remains unchanged. DCENT_Pool aims for the world to be the primary way players understand and direct their mining contribution, while preserving access to the raw evidence beneath every fictional interpretation.

Whether the result earns a new category depends on execution. "MMORPP" is D-Central's proposed name, not an established industry classification. The eventual claim should be demonstrated through playable mechanics and inspectable evidence—not repetition of the acronym.

What the project deliberately does not copy

Inspiration is most credible when its limits are explicit.

No borrowed worlds

DCENT_Pool needs original factions, classes, creatures, locations, histories, UI, symbols, and narrative language. It should not recreate recognizable maps, characters, raids, quests, trade dress, screenshots, sounds, item designs, or story beats from the games that inspired it.

No implied affiliation

Official game names can identify factual inspiration in editorial prose, subject to legal review. They should not appear in DCENT_Pool feature names, domains, campaign logos, ad creative, structured-data fields, or calls to action in a way that implies compatibility or endorsement.

No transplanted mechanics by name

Genre conventions such as classes, guilds, experience, parties, skill progression, roles, and campaigns are broad ideas. A distinctive named system, exact rules expression, text, art, lore, or interface belongs to its creator. DCENT_Pool's implementation must remain original.

No "better than" bait

The editorial point is not that a mining project replaces established games. It offers a new kind of input and time boundary. Community outreach should invite discussion about that experiment, not raid another game's audience with superiority claims.

An example party of machines and people

The following is a design illustration, not a production-status claim.

A five-person guild is preparing to defend a route before a block-height deadline.

• The steady home miner runs a small ASIC continuously and directs work toward the garrison.
• The burst contributor has more hashrate but limited operating windows and adds effort near the deadline.
• The scout has already used prior accepted work to reveal the safest path.
• The builder invested earlier work in infrastructure that changes the fictional logistics calculation.
• The coordinator watches the Bitcoin block clock and changes intent based on what other groups are doing.

The group cannot know the exact wall-clock moment of the next block. It can estimate. It cannot click a route into existence without work. It cannot turn a game buff into a better Bitcoin hash. It can combine real contribution and strategic choices inside the fictional rules.

This is neither an MMO raid in the familiar sense nor a tabletop session. It uses lessons from both while allowing machines to remain active between human check-ins.

The design tensions come with the inspiration

Each tradition contributes a problem as well as a strength.

From MMOs: social obligation

Guilds can create belonging, but they can also create attendance pressure and exclusion. A physical system magnifies the risk because participation has real costs. Independent play must remain viable. A guild should never pressure members to exceed safe energy, hardware, or financial limits.

From skilling games: grind without meaning

Long progression can become an empty counter. Work-backed XP is not automatically interesting. New decisions, visible world consequences, and varied roles have to justify the accumulation.

From tabletop games: operator authority

A human game master can make a fair judgment based on context. Software can only execute its rules and inputs. The realm operator also controls infrastructure. Versioned rules, auditable events, explicit trust boundaries, and replayable outcomes must replace appeals to invisible discretion.

From mining: power disparity and variance

Hashrate is unequal, and block finding is probabilistic. No narrative layer should obscure either fact. The game must remain legible and worthwhile even when the pool has not found a block.

From persistent worlds: accumulated advantage

History gives the world meaning, but early players can capture too much. Decay, frontiers, recent-contribution views, maintenance, specialization, and new kinds of objectives have to create room for newcomers without deleting the past.

These tensions are not reasons to retreat into a cosmetic leaderboard. They are the actual design work.

Why this synthesis may reach beyond Bitcoiners

A non-Bitcoin player does not need to begin with coinbase transactions or Stratum protocol details. They can begin with a game-design question:

What changes when a persistent world must respect externally verifiable work and externally produced time?

MMO players can recognize group composition and shared progression. Skilling players can recognize long-horizon mastery. Tabletop players can recognize the separation between declared intent and rules-guided resolution. Idle players can recognize the return-and-optimize loop. Hardware enthusiasts can recognize the satisfaction of a physical system behaving well.

Bitcoin provides the boundary connecting them.

The fiction makes the work socially legible. The work prevents the fiction from inventing contribution. The block clock prevents the world from promising an exact schedule. The audit trail gives players a path from story back to evidence.

That is the RPG design DNA of DCENT_Pool—and the point at which the comparison to any one existing game stops working.

Frequently asked questions

Is this a World of Warcraft, RuneScape, or Dungeons & Dragons project?

No. Those games are cited as design influences. DCENT_Pool uses original rules, names, art, interfaces, and fiction and is not affiliated with their publishers.

Can a guild role change Bitcoin mining probability?

No. Roles can affect fictional coordination and outcomes only. They cannot change a hash, Bitcoin's network target, or a miner's payout probability.

Are raids, skills, and campaigns live now?

Treat each named mechanic as a design direction unless the current product status and release evidence identify it as deployed.

Follow the project

Explore the MMORPP definition and the MMO whose physics engine is Bitcoin. Then read what a Bitcoin share actually proves to see where mining evidence ends and the fictional interpretation begins.

DCENT_Pool remains in development. Consult the canonical product status page before treating any example in this design essay as a live feature.

Sources

• Blizzard Entertainment, Playable Classes — official role categories and class descriptions.
• Blizzard Entertainment, Guild & Communities Finder — official guild search by activities, size, and needed roles.
• Blizzard Entertainment, Guild Advancement and You — official explanation of individual/group activity contributing to guild progression.
• RuneScape, Skills — official action, XP, level, and unlock loop.
• D&D Beyond, Playing the Game: 2024 Basic Rules and The Basics — official cooperative-party and intent/resolution descriptions.
• Bitcoin Developer Documentation, Mining — pool shares, network targets, and block construction.
• Trademark and fan-content policy references: Blizzard Trademark Usage Guidelines, Jagex Fan Content Policy, and Wizards of the Coast Fan Content Policy.