Joshua Sterner

As of the writing of this post, Infinite Go has yet to be released. Login/registration functionality has been implemented, and most of the purely front-end functionality has been implemented. I expect progress to version 0.0.0 to accelerate, at least to some degree, now that I have gained some familiarity with Node and the libraries I'm using for this project.

One of the projects I have been working on recently is an online, massively multiplayer game of go played on an infinite game board. This game will be available at infinitego.net upon release (currently, this redirects to the GitHub page for the game).

The Game of Go

If you aren't familiar with Go, it is 2 player strategy board game, where the goal is to capture more territory than your opponent. The game is played by placing black or white stones on the intersection points of a grid. A group of stones can be captured if all of the stones vertically and horizontally adjacent points are taken by the opposing color.

Implications of Infinity

In traditional go, territory is typically counted at the end of the game, when no more useful moves can be made. Stones that are unable to be protected are captured and thus removed from the board. At this point, territory can be defined by the grid points surrounded entirely by one color of stones (or the edge of the board). An infinite game board will never reach this end-game condition, however, and determining whether or not stones are destined to be captured is a difficult problem. To simplify this, territory in infinite go will be defined as the grid points surrounded entirely by one color of stones. This means, for example, that if White surrounds an area of empty grid-points, those grid-points are considered to be White's territory. However, if Black places a stone on one of those grid-points, those grid-points are no longer considered to be White's territory.

The other major implication of playing on an infinite game board is that the game will never end, and therefore no team will ever win. There are a few different ways that I intend to make the game-play meaningful despite this. Firstly, territory, captures and the total number of points held by each team will be tracked continuously. Furthermore, players individual contributions to the territory and captures held by each team will also be tracked continuously. These contributions will be weighted — that is, if Alice and Bob capture a stone together by surrounding it with one of Alice's stones and three of Bob's stones, Alice will receive 0.25 weighted capture points and bob will receive 0.75 weighted capture points. There will be a number of leader-boards based around these stats. In addition to this, there will be achievements or challenges of some sort that players can complete. I have yet to work out the details of these challenges, as that functionality will be added a number of releases from now.

Multiplayer Mayhem

Traditional Go is a turn-based game, and thus a massively-multiplayer variant of go faces the challenge of not breaking the strategic game-play of Go that is enabled by its turn-based mechanics. It is clearly unreasonable to expect everyone currently in-game to take turns, and so there must be some sort of localized turn-taking functionality. I have decided to implement this through what I will refer to as Battlegrounds.

Battlegrounds

Battlegrounds define the areas within which players are required to follow precisely the same rules. Within a battleground, players may vote on whether or not to take turns, and if taking turns, the time each player has to make a move when it is their turn. Battlegrounds are formed by the overlapping viewports of two or more players.

Battleground boundaries are dependent upon the viewport history of the players in the battleground. Grid-points that were within a battleground stay within the battleground for some duration of time after they are no longer in the viewport of any players within the battleground. This allows players to move outside of the battleground area without immediately leaving the battleground.

When two or more battlegrounds are bridged by one or more player viewports, they must merge into a single battleground. All players in the merging battlegrounds will be notified of this change. Since the rules may not be consistent between the merging battlegrounds, a vote is forced, so that players must choose which battleground's rules to follow.