devlog

Building an Online Tabletop Game (Devlog)

fczuardi

10 Dec 2025 — 4 min read

Our current work-in-progress is an open-source system to support online multiplayer, turn-based, board games. For example: sessions with 2-6 humans, dice rolling for movement and different outcomes based on spaces of the game board.

The project is in its early stages and the main code repositories can be reached at:

I will use this page for writing status updates and other development-related logs as the project grows in the following weeks and months.

January 07

End of the year was a difficult period to get tangible progress, family gatherings, holidays, and travels, but we can say that we are on a better shape regarding the server side of the game. Authentication proved to be a bigger fish than I initially foresaw, but I learned a lot in the process. An authentication server that will remain proprietary for some time as requested by the sponsors got much of my work time in the last month, this proprietary code will be also the system handling most of the blockchains and pay-to-play specifics, with any other sensitive matters...

The good news is that the actual game parts continue to be an open source project and that this game should stand on its own without the proprietary parts and be useful as a basis/reference for other possible tabletop-themed games. The goals of developing a multiplayer turn-based open source game, easy to adapt and create derivations is still alive, and to continue the transparency in progress report and updates, any pieces of the back-end that are useful on other contexts will be developed in public repositories.

Like the project https://github.com/Falafel-Open-Games/godot-multiplayer-auth that is a reference of a Godot headless server that requires validation of a JWT token first in order to keep new peers connected. A minimal server meant to be used by HTML targets in a way that is agnostic about which token issuer is plugged to it.

Developer Preview of the Authentication Flow

An online usage example of this minimal web-sockets server and html client working on a context of a token issuer that uses a login flow based on Sign In With Ethereum (SIWE) conventions can be accessed and tested here (Metamask or Brave Wallet required): https://tabletop-auth.fly.dev/demo/

December 08-12

The initial work focus has been into establishing a game-server to handle events communication between players.

Tech Stack

As a Godot-shop, we chose the path of having godot on both client and server sides. A headless Godot app on a Linux-based server to manage the connections of multiple Web-based clients using the WebSocketMultiplayerPeer APIs. One central web-sockets server that manages the state data and broadcast received messages only between players connected to specific rooms.

Centralized server broadcasts game events to players in a room

Multiplayer "Hello World" Application: a chat server

two web clients communicating on the same room of the same server

One first proof-of-concept to validate this architecture was a simple chat interface where clients connect to a server URL and a specific room id to exchange text messages.

Continuous Deploy

Play test should happen constantly during the development lifecycle, so part of the work was to setup automation workflows for creating a new release (server and client binaries) on every update of the main branch, as well as new OCI Image to be published on DockerHub and deployed to a temporary dev server in the cloud to test (Fly.io for the moment, with the intent of going to AWS's EC2 solution later). The CI/CD automation was setup using GithubActions and the feed can be monitored here: https://github.com/Falafel-Open-Games/tabletop/actions

This open source project was commissioned by a group involved in the cryptocurrencies space. It is natural for users on such ecosystems like Bitcoin, Lightning, Nostr and Ethereum to have software applications know as "Wallets" or hardware devices "Signing Devices" that store private keys and are capable of providing signed messages that validates ownership of certain public addresses.

On regular web apps that needs an identity layer and an authentication layer, it is common the use of a 3rd-party identity provider for this purpose, such as "Login with Google", "Login With Facebook", and other Oauth2 approaches. This is very practical for both system developers and users alike, users don't have to keep dozens of different login credentials and developers can delegate security concerns to big tech companies with some reputation. But on those architectures, the central providers are the custodians of the user's identities.

A more "web3" friendly approach to authentication, or sometimes called "bring your own identity" is to use public key criptography to cut out the big techs and keep the ownership of the identity with the users themselves, using "wallets" to validate the logins. Think of it as "Login With Nostr", "Login With Lightning", "Login With Bitcoin", "Login With Shi^H^H^H Ethereum"...

Users of browser-based wallets like Alby and Metamask or browsers with a built-in self-custody wallet like Brave already uses this kind of authentication on some websites.

💡

Despite the name Wallet, a "wallet" in this context acts more like a "keychain", it keep tracks of all the key pairs you can use to sign different types of messages with. Coins transactions, that moves funds, is one of the types of signed messages that uses the private part of the key pairs to prove that you own the addresses.

So, all this to mention that "Login With Metamask" is one of the requirements for the first game based on this tabletop framework we are working on, and a first version of this support is being implemented as part of Issue #12