After I released Mahjong101, a web app that calculates the faan of a Mahjong round, a friend suggested evolving the calculator to a multiplayer online game.
As I live in a place where I can’t easily find friends to play Mahjong with, taking his suggestion could be a good idea. But I had no idea how to implement a game with live action over the Internet. That was completely beyond my knowledge – all I knew was HTTP.
Based on my knowledge at that time, running a multiplayer Mahjong game would require a game server to centralise the calculations and manage communication between four player clients. As the game server can’t send requests to the players, how does the it shares information with the other players when one of them takes an action?
To simulate real-time actions, all players must send requests to the server periodically. If the game state has been updated, the game server will respond with details of the change so that players can update their state. Otherwise, it will return an empty response. This is called short polling.
While short polling can simulate real-time actions, it also creates other problems. How frequently should players poll the game server? For the pure turn-based game, polling could be less frequent. However, in Mahjong, there are situations where other players can interrupt during the game, such as melding or declaring a winning hand. The polling frequency may need to as high as once per second, or even higher.
A simplified representation of a 2-player game with short polling.
For a single game, four HTTP requests per second are created. If 100 games are running concurrently, that amounts to 400 HTTP requests per second, which would place an unacceptable burden on the game server and network.
After a quick Google search, I came across a term I might have heard during my undergraduate studies – WebSocket.
WebSocket is a protocol that allows bidirectional communication between client(s) and server. First, the client sends an initial handshake request to the server, asking to upgrade the HTTP connection to a WebSocket connection. Once the server accepts the request, the connection is established. Messages can then be sent in both directions until either side closes the connection.
With real-time bidirecitonal data transfer, the game server can send updates directly to player clients without requiring them to repeatedly send requests. This simplifies the implementation of interruptions during a Mahjong round.
There are two libraries in Go for WebSocket, maintained by Coder and by Gorilla, so we don’t have to implement WebSocket from scratch (which isn’t my current priority). But even though I’ve discovered the technical details, that doen’t mean I can immediately implement a multi-player game immediately – a 4-player, turn-based game with real-time interruption is still a complex challenge. A new project comes to mind – Reversi.
For those unfamiliar with Reversi, it’s a board game for two players, played on an 8 x 8 grid with black and white discs. Each player places a disc on a valid empty square. If the current player is black, any white discs lying in a straight line between the newly placed black disk and another black disk will be flipped to black. The game ends when there are no more valid moves for both players.
During one of my flights with my girlfriend, we played several rounds on the plane and couldn’t stop until we landed. By reinventing the wheel, I can:
- Gain more experience coding in Go.
- Learn the basics of Go’s concurrency model.
- Explore WebSocket implementation and prepare for the multi-player Mahjong online game.
- Most importantly, have fun.
As of now, I’ve implemented the console version of Reversi, which offers local multiplayer mode and a computer opponent with random move. Unlike Mahjong101, this time I can’t fully focus on Reversi due to other personal matters. My pace will slow down a bit, but I will keep you all posted and share more about my learning experience in the future.
It's so weird to play in a console where the grid is displayed in rectangle.