online-go / goban

A JavaScript library for exploring and playing the game of Go

Current state

Warning This code base has been extracted from the online-go.com source code where it was highly integrated and minimally touched for many years even during some moderinization of the rest of the site. Until v 1.0 is released of this library, it is not recommended to make use of it as much overhaul is happening to improve usability on sites other than online-go.com.

Usage:

To import into an application targeting the web:

import { ... } from "goban";

To import into an application targeting node, use the goban-engine package:

import { ... } from "goban-engine";

Documentation

https://docs.online-go.com/goban/

Dev setup

1. Building goban

If you have make installed you can simply run

make

Or, you can build and run manually using

yarn install
yarn run dev

(yarn install is only necessary the first time you start working on the project, or whenever dependencies are updated)

2. Using local clone of goban while working on online-go.com

From your goban directory run

yarn link

From the online-go.com directory run

yarn link goban

Once done, your online-go.com development environment will use your development goban code.

Before PR

Be ready for CI check on PR:

• run tests npm test
• run prettify npm run prettier

[Optional] You can also set up a pre-commit to run checks locally before you commit:

npx husky install

Running & Writing tests

Tests live in src/__tests__ directory, check it out & add Your own! To run tests:

npm test

goban's Issues

Right-clicking should not place a stone.

See https://forums.online-go.com/t/add-option-to-disable-right-click-placement/45422 and https://forums.online-go.com/t/wish-no-right-click-for-moves/38862

Model multiple edits in the same "move" node

From the forums:
https://forums.online-go.com/t/condense-edited-position-in-game-tree/50637

Currently OGS displays edited moves in the same way as regular moves. If you edit in multiple stones, each edited stone will show up as an individual move in the game tree. This makes it so if you make large edits to the board position or set up a problem on the board, it shows up as a long string of individual moves. This then makes it extremely confusing to navigate the game tree. Other programs will often condense all of these edits into a single icon on the game tree which greatly helps with tree navigation.

The GoEngine can't handle multiple edits in the same move node, so the first step is here in https://github.com/online-go/goban. This should be easy to add tests for, by parsing and/or dumping SGFs.

From the forum discussion:

• ; indicates a new game tree node
• B and W are moves.
  • They always require nodes, and show up as ;B and ;W in practice.
• AB and AW indicate edits.
  • They do not require nodes and could be part of previous nodes.
  • ;AB[aa] is a new node with a black edit
  • ;AB[aa][ab] is a new node with two black edits
  • ;AB[ff][fg]AW[ef][eg]AB[fh] is a new node with five edits

EDIT: the follow-up to expose this in the analysis interface is online-go/online-go.com#2559.

Displayed message strings appearing in multiple places

all the displayed message strings appear in:

1. goban: translate.ts
2. goban: messages.ts
3. online-go: translate.ts (but referencing the type defined in goban: translate.ts

Bit of a mess - should be the code used everywhere and the message string defined in one place linked to the label - I will raise an issue in both code bases

Uploaded SGF "winner" text is wrong if SGF contains comments before "RE" (result) tag

Instead of showing "White/black wins by resignation" it only shows "White/black wins by". For example in this game: https://online-go.com/game/29322976

GoEngine: remove ogs_import from config

There is a comment here that the field is deprecated and we no longer use it, but how to be sure?

https://github.com/online-go/goban/blob/main/src/GoEngine.ts#L202-L203

Maybe some error logs?

Change GoEnginePlayerEntry.pro to boolean

Request: Change GoEnginePlayerEntry.pro to boolean.

Would this cause issues on the server side of OGS? Currently, the front end treats it like a bool anyway:

    let pro = ev.target.value.indexOf(".1") > 0;    // result of comparison is boolean
    console.log(rank, pro);
    this.props.config.players.black.rank = rank;
    this.props.config.players.black.pro = pro;
    this.props.black.rank = rank;
    this.props.black.pro = pro;

Many similar examples in GameInfoModal.tsx. I ran into this when trying to add type information, in order to make #1362 easier to solve.

Uploaded SGF territory marking is incorrect

There are two issues:

1. For games that end in resignation, no territory should be marked, however this is not the case (e.g. https://online-go.com/game/29813935):
   

2. For games that do go to scoring, any territory with dead stones is not marked (e.g. https://online-go.com/game/29322975):
   

Right now it looks like the client just uses a basic heuristic to mark any unambiguous territory, but leaves the rest alone, which is not ideal.

I'm not sure if SGFs include any territory marking data (i.e. if the players manually marked dead stones), but it does not appear that the server provided game data includes this. If SGFs do include this, it would likely require a server side change to pass this information on to the client.

I think the best that can be done with a client-only change is not marking territory when a game ends in resignation.

EDIT: Looks like KGS SGFs (which is where these were downloaded from) do not include dead stone marking despite the SGF format supporting it. So I think the real solution here is for a "smarter" client-side dead-stone marking algorithm, or integrating this with the upcoming "AI scoring" feature.

EDIT 2: Nevermind, KGS SGFs do include the TW and TB properties. So it would be cool if OGS respected those when displaying SGFs (and also set them when exporting SGFs from OGS!). Since this requires server side changes, for now I think the easiest solution is to try to use a smarter client-side marking algorithm (as stated previously), probably just using the basic score-estimator is good enough (or at least better than the current solution)?

[Dev tools] In VSCode, ESLint and Prettier plugins don't seem to work

Steps to reproduce

0. install and enable ESLint and prettier plugins
1. open Goban in VSCode.
2. create a lint/format error (an easy one is to change a === to a ==)
3. Observe that there is no squiggly line

Expected

See squiggly lines under lint errors and errors in the Problems pane. For Prettier, I should be able to Format on Save/Paste, but it does not seem to work either.

This is an issue which I have tried to fix myself, but no luck. I'm not sure if this is a VSCode issue, or a ESLint/Prettier/TS project config issue. Hopefully someone with more know-how than I can resolve!

---

Workarounds

• npm run checks before a commit or push will run let you know if you have issues with either ESLint or Prettier (pending #54)
• npm run prettier will automatically format the project

Roadmap / work left until 1.0?

Hi,

I would like to leverage this for a project of mine; how much work is left until this is considered more widely usable?

With such a list I might also be able to contribute effort towards generalization of this codebase.

[svg] square linecaps

First of all, the SVG boards look slick! This issue is a minor nitpick:

https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-linecap

The default linecap is "butt" which leads to incomplete overlap in the corners:

I think square would be preferable:

Version 0.5.29 needs to be published

It looks like v0.5.29 of Goban wasn't published but is referenced by online-go: online-go/online-go.com@e3e62de

Maybe the version was locally bumped but not pushed upstream?

From inspecting the source of online-go.com the changes included in Goban since v0.5.27 are not yet live, so after releasing the version it may be necessary to redeploy.

I see the soneboard and shadowboard separately

Not sure what I'm doing wrong but I'm using quite simple code so I thought I'll ask here and maybe it is a bug.

I'm trying to use the library in my HTML page. I have the following code within my <script> tags. The board is drawn but I see the 2 canvases right after each other rather than overlayed. Am I doing anything wrong or how to go about it?

var goban_div = document.createElement("div");

const base_config = {
    interactive: true,
    mode: 'puzzle',
    board_div: goban_div,
    square_size: 30,
    draw_top_labels: true,
    draw_left_labels: true,
    draw_right_labels: true,
    draw_bottom_labels: true,
    bounds: {
        left: 0,
        right: 18,
        top: 0,
        bottom: 18,
    }
}

var goban = new window.Goban(base_config)
$("#goban_div").append(goban_div);

Webpack build generates failing code in goban.js (self is undefined)

Hello, webpack seems to generate failing code for this library.
The source of build/goban.js contains the following:

(function webpackUniversalModuleDefinition(root, factory) {
	if(typeof exports === 'object' && typeof module === 'object')
		module.exports = factory();
	else if(typeof define === 'function' && define.amd)
		define([], factory);
	else if(typeof exports === 'object')
		exports["goban"] = factory();
	else
		root["goban"] = factory();
})(self, () => {

The problem is on the last line, with self, and more specifically when importing this module in Nuxt this fails with:

self is not defined
   at ./goban:26:4

Looking at webpack/webpack#6784, it seems to be a Webpack issue.

The code should instead be:

typeof self !== 'undefined' ? self : this

Can you please update Webpack version to resolve this, or otherwise manually modify the output build in the library to prevent this error.

Better yet, it would be awesome if there would be just a mjs export with no need for webpack.

Many thanks!

[SVG] Hover missing for custom stone colors

Screen.Recording.2024-06-27.at.3.16.19.PM.mov

To Reproduce

0. Enable Experimental SVG renderer
1. Set stones to custom colors
2. Hover over a goban

Configuration

Browser: Firefox
OS: Mac OS
Renderer: SVG

Screenshots

No transparent stone on hover for custom stones (broken):

Transparent stone on hover for "normal" stones (correct):

Active chat input box causes auto scroll to it when playing a move on a touchscreen

see online-go/online-go.com#2270

Stones are slightly smaller than grid, not touching - esthetics

The stones are not touching, which is not esthetic IMO, and many players I talked to agree with me:

I believe these lines are related, with the radius of the arc being less than what's supplied at line 48:

goban/src/themes/disc.ts

Lines 45 to 52 in b1313e4

	ctx.arc(
	cx,
	cy,
	Math.max(0.1, radius - lineWidth / 2),
	0.001,
	2 * Math.PI,
	false,
	); /* 0.001 to workaround fucked up chrome bug */

Not sure whether the lineLength is 0 here (might be set to 0 if too small, line 37), but maybe nothing should be subtracted, which should make the lines overlap. This happens in Firefox and Chrome, in both "flat" mode (no shading / drawings in stones) and also in the regular mode. I also briefly checked the mobile view in Firefox and it's the same there.

Now that I think of it, the code I referenced is probably only used in the 'flat' mode.

This might be a nitpick, and I still think it justifies the fix.

Review message filtering is too aggressive when using multiple window for the same review

The current check in

goban/src/GobanCore.ts

Line 1515 in 7ce3d9b

!this.isPlayerController() ||

fails if the controller of a review has multiple views open. This can be two browser windows, but it could also be a different application and a browser window. Just turning the whole condition into true is a significant improvement and would synchronize two browser windows. Markers don't get synchronized correctly though and it would not be possible to have two different locations. So this issue is a bit about what the expected behavior is from a client perspective:

1. Only synchronize the move tree and update markers iff they affect the current move
2. Keep the board state fully synced

Idea: potentially more intuitive score estimator display?

Inspired by colorgoserver.com, I experimented with a more contiguous score estimator display on OGS. I think for beginners this might make more intuitive sense than the little squares currently deployed, especially if we rounded the corners of the area and found a better solution for contrast on the black stones.

Just fooling around, thought I'd share in case this was interesting!

v0.5.31 version bump

Looks like after #21 merged there wasn't a version bump, so OGS repo doesn't have the latest goban code.

comment get attached to wrong node when it precedes the move

I noticed that sometimes the comments felt out of place. I tracked this down to comments preceding the move property. I couldn't figure out a fix though. I hope the test case helps.

test("test for comments being attached to right nodes", () => {
    let sgfStr = "(;GM[1]FF[4]CA[UTF-8]AP[CGoban:3]ST[2] RU[Japanese]SZ[19]KM[0.00]PW[White]PB[Black];W[aa]C[Comment after move property];W[pd])";
    let goban = new TestGoban({ original_sgf: sgfStr, removed: "",  });

    goban.engine.jumpToOfficialMoveNumber(0);
    
    expect(goban.engine.cur_move.text).toMatch("");
    goban.engine.showNext();
    expect(goban.engine.cur_move.text).toMatch("Comment after move property");
    
    // now let's have the comment before the move property
    sgfStr = "(;GM[1]FF[4]CA[UTF-8]AP[CGoban:3]ST[2] RU[Japanese]SZ[19]KM[0.00]PW[White]PB[Black];C[Comment before move property]W[aa];W[pd]C[second comment])";

    goban = new TestGoban({ original_sgf: sgfStr, removed: "",  });
    goban.engine.jumpToOfficialMoveNumber(0);

    expect(goban.engine.cur_move.text).toMatch("");
    goban.engine.showNext();
    expect(goban.engine.cur_move.text).toMatch("Comment before move property");
    goban.engine.showNext();
    expect(goban.engine.cur_move.text).toMatch("Second comment");
});