Building an Online Tabletop Game (Devlog)
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 code repository can be reached at https://github.com/Falafel-Open-Games/tabletop
I will use this page for writing status updates and other development-related logs as the project grows in the following weeks and months.
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.
Multiplayer "Hello World" Application: a chat 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
Wallet Login
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.
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