Inspiration
I wanted to play an online competitive board game with a mix of mechanics I could not find anywhere else, so I built Blockblock. It combines ideas from several games with mechanics of my own: a head-to-head race where the route can change on every turn.
Chess.com influenced the experience around the game. I wanted strategy players to feel at home, with a clear board, focused controls, and a way to learn from each match. That last part became a defining feature: Socrates, my custom post-match evaluation engine.
What it does
Blockblock is an online 1v1 strategy board game. Race your pawn to the opposite side before your opponent. Each turn presents a choice: move through an open lane or reshape the board with a card. Winning means balancing your own progress with disrupting your opponent's route.
After a match, Socrates analyzes the game and evaluates your moves, helping you review decisions and understand where you could improve. The game also includes private matches with friends, bots, rated puzzles, leaderboards, and move-by-move replays. Completing a full row or column clears it and grants another action, adding another layer of tactical timing. Blockblock is available on the web, iOS, and Android.
How I built it
My original plan was Kotlin Multiplatform for shared business logic, React for the web, Swift for native iOS, Kotlin for native Android, and Ktor for the backend.
I started in Figma with design guidelines for typography, colors, the board, cards, and tiles, alongside a purchased icon pack. These references helped keep the interface consistent throughout AI-assisted development with Codex. I explored my own ideas and AI suggestions, then refined the experience through playtesting with friends.
Once the web app and backend were ready for an initial release, I built Socrates in Rust, taking inspiration from Stockfish. It is a purpose-built engine for Blockblock's rules and positions, with substantial room to improve its accuracy and maturity.
For mobile, I first tried native iOS. Recreating every polished web interaction made it clear how much work three separate interfaces would require. I switched to Capacitor to reuse the React app across iOS and Android. Within about a day I had usable mobile versions, followed by roughly another week refining mobile interactions, UI details, and features.
The shipped stack keeps Kotlin Multiplatform game logic shared between the Kotlin/JS frontend library and the Ktor backend, with PostgreSQL for persistence. RevenueCat powers monthly and yearly mobile subscriptions, purchase restoration, and premium entitlements. Premium offers an ad-free mobile experience and expanded access to practice and analysis, helping support the ongoing cost of the game.
Challenges I ran into
The hardest challenge was the evaluation engine. Reducing analysis time from minutes to seconds took much longer than expected, and the engine became complex enough that understanding its behavior was a challenge in itself. After about a month, I had a usable version producing reasonable evaluations.
I also had to balance analysis quality against the server compute I could afford before the game generated revenue. A stronger engine is valuable only if players can get useful feedback quickly and the service remains sustainable.
On mobile, the challenge was polish. A functional screen was relatively easy; reproducing the feel of every interaction across separate native apps was much harder. Choosing Capacitor changed the practical scope of the project.
Accomplishments I am proud of
- Turning an original board-game idea into a playable online 1v1 experience.
- Building a custom Rust engine that makes post-match analysis practical in seconds.
- Bringing the game to web, iOS, and Android with a consistent visual identity and interaction model.
- Using early playtests and repeated UI refinement to turn a working prototype into something I was happy to release.
What I learned
AI can help build a great deal, but architecture still determines how much work remains. Reusing a polished interface let me spend more time improving the game itself. Clear design references were just as useful: they gave the implementation a consistent direction.
I also learned that a game-analysis engine is a long-term project. Useful evaluations require continued testing, performance work, and a realistic understanding of the engine's limits.
What's next for Blockblock
Improve Socrates' evaluation accuracy and performance, keep refining the mobile experience, and use player feedback to guide the next changes. As the game grows, I want to invest in more analysis capacity and make the feedback more useful to players.
Built With
- capacitor
- kotlin
- react
- revenuecat
- rust
- typescript