🛠️ Reversteem: Building a Zero-Backend, Deterministic Board Game Engine on Steem

puncakbukit (78)in Steem Dev • 14 hours ago

5% of the rewards of this post are for @steem.amal

Hey Steem Developers! 👋

When building dApps on Steem, the default architecture often involves spinning up a custom node, a Postgres database, or a centralized backend API to index custom JSON operations and keep track of application state.

With Reversteem (a decentralized Reversi/Othello dApp), we took a completely different approach: Pure Client-Side State Machine Driven Entirely by Steem Comment Trees.

There are no databases, no server authorities, no custom indexing servers, and no smart contracts. Everything — from legal move validation and turn logic to per-move timeouts and global ELO recalculations — is computed 100% locally in the user's browser by replaying immutable blockchain history.

Here is a breakdown of how it works under the hood and why Steem is uniquely suited for deterministic client-side state machines.

🏗️ Architecture Overview

The system treats the Steem blockchain strictly as an append-only, immutable event log.

┌──────────────────────────────────────────────────────────┐
│                   Steem Blockchain                       │
│  Root Post (Game) ──► Reply (Join) ──► Replies (Moves)   │
└────────────────────────────┬─────────────────────────────┘
                             │ Raw Comment Tree Fetch
                             ▼
┌──────────────────────────────────────────────────────────┐
│                 Client-Side Engine (Browser)             │
│                                                          │
│  1. JSON Metadata Filtering   (app: "reversteem/x.y")     │
│  2. Sequence & Turn Replay    (moveNumber == applied)    │
│  3. Rule Engine               (Pass logic & board flips) │
│  4. Deterministic Timeouts    (Claimable elapsed checks) │
│  5. Incremental ELO Engine    (Replayed match history)   │
└────────────────────────────┬─────────────────────────────┘
                             │ Output
                             ▼
┌──────────────────────────────────────────────────────────┐
│                  Reactive Vue 3 UI                       │
└──────────────────────────────────────────────────────────┘

🔑 Key Engineering Strategies

1. The Immutable Event Log Hierarchy

Instead of custom operations (custom_json), Reversteem structures games natively as Steem discussion threads. This makes games visible on standard frontends like Steemit while keeping parsing straightforward:

Root Post: Represents the game session created by Black (type: "game_start").
First Valid Reply: Registers the White player joining (type: "game_join").
Child Replies: Represent individual sequential moves (type: "game_move").
Timeout Claim Reply: Finalizes a match if a player exceeds their allocated turn time (action: "timeout_claim").

2. Strict Replay & Deterministic Validation Rules

Because any user can post anything as a reply, trust resides entirely in client-side validation logic during replay, not in the input step.

During the execution of engine.js (which operates without any DOM or Vue dependencies), every incoming reply is evaluated against strict state rules:

App Scope Filtering: Rejects any comment missing a valid reversteem/x.y app signature in json_metadata.
Sequential Indexing (moveNumber): The payload must include moveNumber, which must exactly match appliedMoves count. Gaps, duplicates, or out-of-order comments are dropped instantly.
Turn Enforcement: The comment author must match the expected username for the current active color.
Board Mechanics: The chosen cell (0–63) must be a legal Reversi move that flips at least one opponent disc.
Automatic Pass Rules: If a player has zero legal moves, the engine automatically passes the turn to the opponent during state calculation. No manual pass transaction is posted.
End-State Locks: Any moves submitted after a game is finished (or after a valid timeout threshold has been crossed) are silently ignored.

3. Claimable Timeouts Without Time Servers

Enforcing move time limits (e.g., 60-minute Standard mode) without a server cron-job presents an interesting challenge.

Reversteem solves this using a Claimable Timestamp Delta Model:

$$\text{currentTime} - \text{lastMoveTime} \ge \text{timeoutMinutes}$$

The replay engine tracks the block timestamp of the last valid move.
If the current player stalls, the opponent's client enables a Claim Timeout UI action.
The opponent broadcasts a timeout_claim reply.
When any client replays the thread, it checks if minutesPassed >= timeoutMinutes was true at the time of the claim. If valid, the match halts deterministically, and the claimant is awarded the win. Late moves posted after the timeout threshold are rejected.

4. Client-Derived Global ELO Leaderboard

How do you maintain a global player ranking without an on-chain database or state storage?

Reversteem reconstructs the entire leaderboard client-side using an Incremental ELO Engine:

On loading #/leaderboard, the dApp queries recent games tagged with reversteem.
Matches are sorted chronologically by creation date.
Starting from a base rating of 1200 ($K = 32$), finished games update player ratings sequentially:

$$E = \frac{1}{1 + 10^{(R_{\text{opponent}} - R) / 400}}, \quad R' = R + K \times (S - E)$$

To keep this performant, completed states are cached incrementally in localStorage (reversteem_elo_cache). The engine only processes matches newer than lastProcessed, maintaining $O(1)$ startup loads after the initial fetch.

5. Native Steemit Markdown Engine Integration

To bridge dApp interactions with the native Steemit reading experience, every move broadcast includes a visual ASCII/Emoji Markdown representation of the board in the comment body:

|   | A | B | C | D | E | F | G | H |
|---|---|---|---|---|---|---|---|---|
| **1** | · | · | · | · | · | · | · | · |
| **2** | · | · | · | · | · | · | · | · |
| **3** | · | · | · | ⚪ | ⚫ | · | · | · |
| **4** | · | · | · | ⚫ | ⚫ | ⚫ | · | · |

This allows non-dApp users to follow live games natively in their standard feed, turning every move comment into an interactive, readable log.

⚡ Multi-RPC Fallback & No-Build Setup

To ensure total independence from single-point infrastructure:

CDN-Only Vue 3 / Vue Router 4: Loaded directly via CDN script tags using native ES modules / Options API string templates — zero bundlers, Webpack, or npm build steps required. Hosted effortlessly via GitHub Pages.
Transparent RPC Failover: Multi-node rotation (api.steemit.com $\rightarrow$ api.justyy.com $\rightarrow$ steemd.steemworld.org $\rightarrow$ api.steem.fans) automatically retries failed reads seamlessly behind the scenes.

💡 Takeaways for Steem Developers

Reversteem shows that Steem's fast block times (~3 seconds), zero-cost comment transactions, and immutable custom JSON metadata offer a complete foundation for turn-based state machines. You don't always need a layer-2 node or external SQL engine — sometimes, the blockchain log and a well-designed pure JS engine are all you need.

💻 Explore the Engine Source: github.com/puncakbukit/reversteem
🌐 Live Application: puncakbukit.github.io/reversteem/

What other turn-based state engines would you like to see built on Steem using this architecture? Let's discuss in the comments below! 👇

Assisted by https://gemini.google.com/.