Decoupling sgf interpretation from board visualization

[fvictorio]

I have a very simple problem: I want to take an SGF and a move number, and get a matrix with the stones at that point. I've been looking around for a while but I haven't found anything yet (sgfutils doesn't have anything like that; there doesn't seem to be anything in javascript or python neither). So I think this is something that, maybe, besogo could do?

More specifically, I think parsing an SGF should generate a game tree, and each element of that tree should have an abstract description of the game at that point (stone positions, whose turn is it, captures, ko).

This could go hand in hand with #12, meaning that you could expose both the function to show the board, but also a "low-level" function for doing this. That way anyone could use this to visualize the board however they want. A contrived example: you could use this to make a command-line go player in node.js. Or you could use this to make your own HTML/JS board component, using besogo as the interpreter but doing the UI in some other way.

What do you think? Is this something worth doing?

[yewang]

I think this should be doable.

To get straight from an SGF to an object containing a representation of the game tree, without any of the other UI/editor functionality of besogo, I think it may be possible to just use these three files (with some very minor modifications):

https://github.com/yewang/besogo/blob/gh-pages/js/parseSgf.js
https://github.com/yewang/besogo/blob/gh-pages/js/loadSgf.js
https://github.com/yewang/besogo/blob/gh-pages/js/gameRoot.js

The readFile function from js/filePanel.js illustrates how to the functions in these files are used to going from parsing an SGF file to loading it into a game tree object.

I think the only minor modifications need to detach this from the editor is to change line 2 of js\loadSgf.js to
besogo.loadSgf = function(sgf) {
and line 11 of js\loadSgf.js to
return root; // Returns an object containing the loaded game tree

The function makeGameRoot from js/gameRoot.js produces a classless object that encapsulates the entire game tree, and the loadSgf function from js\loadSgf.js interacts with that object to build up the game tree.

Note: I have not tested the above, and these are just some quick thoughts. I will look into it further, but hopefully these notes are useful to you.

I'd also need to write up some documentation about how to work with the game tree object in order to navigate through it and interrogate the board position, ko status, captures, etc., but the main editor object produced by js/editor.js should offer some hints about how that works.

[fvictorio]

Thanks a lot for the explanation, @yewang!

I started experimenting with this. You can check what I did so far in the master branch of my fork: https://github.com/fvictorio/besogo/tree/master

The main changes are:

• The source is divided in modules and a UMD bundle is generated using rollup. They are under the src directory.
• I extracted some parts of the code that seemed more independent and I moved them to their own modules (meaning, they don't live under the besogo object anymore). I also added several tests.
• I added some tooling (eslint for linting, prettier for formatting)

I tried it out and it works pretty well: you can use it in a node.js environment via require or just take the besogo.all.js bundle (that you can generate via npm run build) and include it in an HTML file, as it is right now.

Before continuing I want to check if all this non-trivial changes are OK with you. If they are, I think the next step is to continue to divide this in modules, add tests, and eventually try to have all the logic that can be used independently in their own modules.

After that, I think having the generation of the UI totally decoupled from the underlying logic would be a huge win. You could have a default UI generator (the one you have right now) but anyone could write their own. For example, I'd love to use this in a react-native project I'm working on, but that requires writing a board component from scratch.

As always, thanks a lot for your help!