Reversteem – Building a Fully Frontend Reversi Game on the Steem Blockchain

puncakbukit (78)in Steem Dev • yesterday

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

After spending quite some time experimenting with frontend-only decentralized applications, I'm excited to share one of my projects with the Steem developer community: Reversteem.

GitHub Repository:

https://github.com/puncakbukit/reversteem

Live Demo:

https://puncakbukit.github.io/reversteem/

Although it is "just" a Reversi (Othello) game, the real purpose of the project was to answer an architectural question that has interested me for a long time:

How much can we build on Steem without introducing any backend infrastructure at all?

Reversteem is my attempt to push that idea as far as possible.

No Backend. No Database. No Smart Contracts.

Many blockchain games rely on one or more of the following:

Smart contracts
Centralized APIs
Backend servers
Databases
Dedicated game servers

Reversteem intentionally uses none of them.

The application is hosted as a static website and runs entirely inside the browser.

Every game is represented by a Steem post, while replies become blockchain events such as players joining, moves being played, timeout claims, or spectator comments.

Instead of querying a server for the current board position, the application reconstructs the entire game by replaying blockchain history.

The blockchain itself becomes the event log.

Deterministic State Reconstruction

One of the primary design goals was determinism.

If two independent users load the same game, they should always calculate exactly the same board position.

To achieve that, the replay engine validates every event before applying it.

Among the validation rules are:

Correct player's turn
Legal Reversi move
Move sequence validation
Automatic pass handling
End-of-game detection
Timeout validation
Winner calculation

Any invalid move is simply ignored during replay.

There is no trusted authority deciding the outcome of a game.

Instead, every client independently verifies the same immutable history.

Browser as the Consensus Engine

An interesting side effect of this architecture is that the browser effectively becomes the consensus engine.

Rather than downloading an already-computed game state, the browser derives everything itself.

This includes:

Current board position
Current player's turn
Remaining legal moves
Winner
Game completion
Timeout status
Player ratings

Nothing except the blockchain is treated as the source of truth.

ELO Without Storage

Another experiment in the project was the rating system.

Traditional games usually store ratings inside a database.

Reversteem doesn't.

Instead, ratings are reconstructed by replaying completed games in chronological order using the standard ELO formula.

Because every completed match already exists on-chain, every client arrives at exactly the same ratings.

The browser caches intermediate calculations only as a performance optimization.

The cache is never authoritative.

Static Hosting

Another goal was making deployment as simple as possible.

The project consists entirely of static files and can be hosted almost anywhere.

GitHub Pages works perfectly.

There are no environment variables.

No Docker containers.

No server configuration.

No deployment pipeline.

Publishing a new version is essentially uploading static files.

Vue Without a Build Step

The frontend uses Vue 3 together with Vue Router 4, both loaded directly from CDNs.

There is no npm dependency tree.

No webpack.

No Vite.

No transpilation.

No build process.

For a project of this size, I wanted to see how far a modern frontend could go while remaining completely static and easy to understand.

The application is organized into a few focused JavaScript files separating the game engine, blockchain communication, reusable components, and application routing.

RPC Resilience

One practical issue with decentralized frontends is RPC availability.

Instead of relying on a single endpoint, Reversteem automatically rotates through multiple public Steem RPC nodes whenever one becomes unavailable.

The failover happens transparently, allowing the application to continue functioning without requiring any backend proxy.

Why Reversi?

Reversi is actually a surprisingly good candidate for this type of architecture.

It has:

Simple rules
Fully deterministic gameplay
Small state space
Sequential turns
Easily validated moves

Those characteristics make it ideal for replaying events directly from blockchain history.

The same concepts could potentially be extended to other deterministic turn-based games.

A Small Experiment in Blockchain Applications

For me, Reversteem is less about creating another online board game and more about exploring alternative application architectures on Steem.

Social blockchains naturally provide immutable chronological event streams.

That raises an interesting possibility: perhaps many collaborative applications don't require backend infrastructure if the client is capable of reconstructing state deterministically.

Games happen to be an enjoyable way to test that hypothesis.

Feedback Welcome

I'd love to hear feedback from fellow Steem developers.

Are there architectural decisions you would approach differently?

Can you think of other deterministic applications that could benefit from this model?

Would you extend this protocol to support additional board games or entirely different collaborative tools?

The source code is fully open source, so feel free to browse the implementation, experiment with it, or suggest improvements.

Repository:

https://github.com/puncakbukit/reversteem

Thank you for reading, and I hope this project inspires more experimentation with what can be built using nothing more than the Steem blockchain and a web browser.

Assisted by https://ChatGPT.com/.