Hashgraph Chess
The motivation behind Hashgraph Chess was to develop a proof-of-concept application demonstrating how Hedera could be used to store a gamestate, in this case, chess. As the Hedera Consensus Service is designed to record immutable messages, it’s naturally well suited to act as a save file. Attempting to store a complex game's rolling save file in each message would likely hit the size limit. The game's history could be spread out across its topic instead. The architecture of the HCS log would need to be designed to facilitate this: passing the minimal information required in each message to track the gamestate. In addition, the game application would need to recreate the gamestate from this log in a timely fashion. In this regard, designing a game’s HCS log would be very similar to architecting a relational database service (RDS) -- it needs to contain the pertinent information in the appropriate format to succeed in its purpose.
Furthermore, I wanted to demonstrate the concept using production-grade web architecture: NuxtJS containerized with Docker and hosted via AWS Elastic Beanstalk.
Program Overview
To develop a PoC, I would need a turn-based game with a ready-made Node module, as I did not want to spend time recreating the game's logic in Javascript. Chess was an obvious choice, as it had the popular chess.js module available. This module handles gamestate and retains additional features applicable to the PoC: move validation, turn history, and end conditions, to name a few. To use chess.js as the game's logical foundation, the app would need to send and retrieve players' moves from a Hedera topic. However, the chess.js module's Chess() gamestate was not intended to be decoupled in this manner. Therefore, a large portion of the development effort involved engineering a solution to decoupling the chess moves from their gamestate.
The solution was for a Hedera topic to function as the match's canonical gamestate, while the NuxtJS front-end would store a dummy Chess() game object. Automated API calls to a mirror node would update this browser-side dummy with the latest, valid message data. And when a player submitted a chess move, instead of performing that move on the Chess() object in a typical fashion, it would be sent to the topic. The dummy gamestate would then be updated on the following API call. Because chess is a turn-based game with only two players, there was no risk of gamestate deviation if the application correctly validated the players' turn order.
Initially, the intent was for players to submit individual chess moves to the match's topic. However, chess.js utilizes PGN (Portable Game Notation). This compressed notation for a chess match's history could easily fit within an HCS message. Therefore, the topic would store the match's rolling PGN instead of individual moves. For longer and more complex games, I would still resort to submitting unique moves -- or the results of turns, if the game's server needed to arbitrate their outcome (such as dice rolls).
The result of this design was an application that allowed players to conduct chess matches on Hedera. The canonical gamestate being stored in a topic also meant that players could freely interact with the dummy gamestate without risking gamestate deviation. So, this allowed for a turn history browser function: players could scroll back and forth through their game's history with the confidence that they will always be interacting with the canonical gamestate for move submission. Storing each match's history in a topic also provided the durability and validity of that format. In addition, that same topic could be used to store chat messages between the players, and both the chat messages and chess moves would be available and synchronized so long as the topic remains.
Topics as NuxtJS Dynamic Routes
NuxtJS allows developers to populate dynamic routes from their URI. Things like rooms, menus, or chess matches can retain their dynamic route based on their URI parameters. This means that whenever a user wants to join an existing match, we can simply send them to a route like `~/matches/0.0.1234'. This URI is the ID of the topic where the match is stored. The dynamic match page uses that ID to load information about its match via the mirror node API call.
NuxtJS also allows dynamic pages to have a parent page. So, in a more sophisticated version of the application, a URI like `~/matches/' could become a menu that allows users to browse their current and past matches.
Subscribing to a Topic
Subscribing to the match's topic is done through API calls that are repeated every 4 seconds. The API calls go out to a mirror node and perform a GET request for the message log of the page's topic. Messages the application hasn't seen before are then parsed for new data.
Parsing Topic Messages Through Vuex
The same topic is used to store information on chess moves, chat messages, and other game-related functions like resigning from a match. NuxtJS comes with a standard Vuex store that allows developers to utilize its mutations and actions from anywhere in their app without worrying about importing them into components. This Vuex store is where the app parses all the messages received from the API request.
The message parsing method chain first determines the message's legitimacy: filtering out anything from one of the match's two players. It also filters out double moves and blank chat messages. The remaining validated messages are pushed into the appropriate array of the match’s Vuex object. The match’s game and chat panels are populated from those arrays.
Learning Experiences
While developing this PoC, there was a lot of trial-and-error involving subscribing to the topic. Initially, I had intended to use the gRPC API. This presented several problems:
Each match would require a unique gRPC subscription
A gRPC subscription can only be initialized from a server-side Hedera client
I didn’t want to initialize the user’s Hedera client server-side, as this client contains sensitive account information that should be kept isolated and encrypted.
Clients can be dynamically initialized server-side for the sole purpose of gRPC subscriptions, but each client has a limit of 5. So, the application would require a fleet of clients that scale in and out dynamically
Creating this functionality was beyond the scope of this PoC.
Eventually, I decided to make automated API calls to the mirror node instead of using a gRPC subscription. However, I still have a tentative solution for how this process might work.
Possible Architecture for a Multi-User App
The application would utilize socket.io's ‘Rooms’ feature. Every topic already has its dynamic Nuxt route. Each of these pages would also retain a socket.io room, where a gRPC subscription would be broadcast to all users visiting the page. The users’ browser clients would then translate these messages via a Vuex store in the same manner as it’s being accomplished now. This does not solve the issue of the subscription limit for Hedera clients. There are two ways we could organize the relationship between Hedera clients and gRPC subscriptions:
The code is open-source and lives here.