Sabaki SGF editor

[Kirby]

I should add, overall, I think you've done a very good job. I like the editor.

[ewan1971]

Wow, I just discovered Sabaki, and it's delightful. The wabi-sabi animation is brilliant!

There are two very minor issues/points I'd like to mention for the macOS Sierra (10.12.2) version:

1) When I replay an SGF record, there is no sound of the stones striking the board. Please enable it because I really enjoy Sabaki's sound effects.

2) A minor issue regarding the game tree visualization. For example, let's say move 23 has an alternate placement, call it 23A. Shouldn't the line be connecting 23 and 23A directly? As it stands right now, 23A is connected visually to 22, which I personally find odd.

Or am I alone in my borderline OCD opinion?


Thanks!

[yishn]

Re: #2.) Whether I visually see linebreaks depends on where I paste it. If I paste the diagram code into the editor here, I also see the lines wrap visually as you do. But if I post into Windows notepad, the linebreaks don't show up. My assumption was that this was due to notepad in Windows using \r\n for linebreaks, instead of just \n. However, when I paste into another editor like notepad++ and show the linebreaks, it looks like both linebreak and carriage return are present...

So #2 isn't a big deal, I guess. It's just a bit different in behavior when I copy diagrams from Sabaki into Windows notepad vs. when I copy a diagram from L19 into notepad. In the former case, notepad doesn't show the breaks, whereas in the latter, the breaks can be seen.

It's probably notepad's fault, as other editors don't have this issue.

Anyway, if you want to reproduce it, try to paste into Windows notepad.

Yeah, I can reproduce this now. It's as you say, Sabaki uses \n for linebreaks. Notepad++ probably converts any linebreaks to your preference. I've fixed it, Sabaki now uses \r\n on Windows and \n everywhere else.

[dfan]

2) A minor issue regarding the game tree visualization. For example, let's say move 23 has an alternate placement, call it 23A. Shouldn't the line be connecting 23 and 23A directly? As it stands right now, 23A is connected visually to 22, which I personally find odd.

Maybe I am misunderstanding the scenario, but the lines in the tree connect consecutive moves in a single "history". In the history expressed by the variation, the next move after White plays 22 is Black playing 23A.

[ewan1971]

2) A minor issue regarding the game tree visualization. For example, let's say move 23 has an alternate placement, call it 23A. Shouldn't the line be connecting 23 and 23A directly? As it stands right now, 23A is connected visually to 22, which I personally find odd.

Maybe I am misunderstanding the scenario, but the lines in the tree connect consecutive moves in a single "history". In the history expressed by the variation, the next move after White plays 22 is Black playing 23A.

That's one way of looking at it conceptually, but visually this could get messy because in an SGF file with many variations, the tree quickly gets out of control, with diagonal lines running all over the place, making it difficult to trace the branches. I was going through one of AlphaGo's commented games, and I found it tiring very quickly.

Again, I'm only speaking for myself, but if plenty of others agree, then this visualization style should be added as an option.

An additional thought, I think it'd be better if the current/active variation is highlighted more prominently (with a different line color and/or thicker line width), and the inactive branches are more grayed out. This will also help reduce fatigue.

[ewan1971]

Oh, one more thing, fuzzy-stone-placement animation isn't available when replaying a game. I'd love for it to be made available in replay mode. Thanks.

P.S. I use macOS Sierra (10.12.2).

[yishn]

Hello Ewan, thank you for your kind words!

2) A minor issue regarding the game tree visualization. For example, let's say move 23 has an alternate placement, call it 23A. Shouldn't the line be connecting 23 and 23A directly? As it stands right now, 23A is connected visually to 22, which I personally find odd.

Actually, I find that quite unintuitive... Clearly, lines should connect the precedent move with the next move? Otherwise, if a game has only one variation, there wouldn't be any lines at all?

That's one way of looking at it conceptually, but visually this could get messy because in an SGF file with many variations, the tree quickly gets out of control, with diagonal lines running all over the place, making it difficult to trace the branches.

I'm not sure how horizontal lines would make it any easier?

Oh, one more thing, fuzzy-stone-placement animation isn't available when replaying a game. I'd love for it to be made available in replay mode. Thanks.

I have experimented with fuzzy stone placement animations when navigating. The problem is performance. Navigating the game by holding down the 'down/up arrow key' will be very laggy, so I decided against it.

An additional thought, I think it'd be better if the current/active variation is highlighted more prominently (with a different line color and/or thicker line width), and the inactive branches are more grayed out. This will also help reduce fatigue.

Currently, the nodes of the current variation is in white, while other variations are in gray. I can try making the lines of the current variation thicker...

[hyperpape]

Actually, I find that quite unintuitive... Clearly, lines should connect the precedent move with the next move? Otherwise, if a game has only one variation, there wouldn't be any lines at all?

I tend to agree. For narrow paths, lines connecting the previous moves make sense.

That's one way of looking at it conceptually, but visually this could get messy because in an SGF file with many variations, the tree quickly gets out of control, with diagonal lines running all over the place, making it difficult to trace the branches.

I'm not sure how horizontal lines would make it any easier?

Perhaps if all sibling moves are:

X
|
Y - Y1 - Y2 - Y3

that might be a little more legible than a bunch of diagonal lines that are hard to follow.

[ewan1971]

Actually, I find that quite unintuitive... Clearly, lines should connect the precedent move with the next move? Otherwise, if a game has only one variation, there wouldn't be any lines at all?

I tend to agree. For narrow paths, lines connecting the previous moves make sense.

That's one way of looking at it conceptually, but visually this could get messy because in an SGF file with many sub-variations, the tree quickly gets out of control, with diagonal lines running all over the place, making it difficult to trace the branches.

I'm not sure how horizontal lines would make it any easier?

Perhaps if all sibling moves are:

X
|
Y - Y1 - Y2 - Y3

that might be a little more legible than a bunch of diagonal lines that are hard to follow.

Right, that's what I meant... It just looks neater this way, especially for a commented game with many variations, which themselves may have many variations. For me, things can quickly get messy visually.

[TheCannyOnion]

Actually, I find that quite unintuitive... Clearly, lines should connect the precedent move with the next move? Otherwise, if a game has only one variation, there wouldn't be any lines at all?

I tend to agree. For narrow paths, lines connecting the previous moves make sense.

That's one way of looking at it conceptually, but visually this could get messy because in an SGF file with many variations, the tree quickly gets out of control, with diagonal lines running all over the place, making it difficult to trace the branches.

I'm not sure how horizontal lines would make it any easier?

Perhaps if all sibling moves are:

X
|
Y - Y1 - Y2 - Y3

that might be a little more legible than a bunch of diagonal lines that are hard to follow.

I second this. This is more intuitive and visually less taxing.

[yishn]

I've hacked together a quick implementation of this suggestion:



Left is the suggestion and right is current implementation. How is this intuitive?

[Kirby]

Personally, I like the current implementation better. I don't feel that strongly about it, though.

[ez4u]

Personally the only problem I have with the current tree is the spacing is too wide. In a heavily commented game, too much of the time I just see a set of horizontal lines running off the screen to the right. Is it possible to add an option to adjust the spacing between nodes?

[quanloh]

Personally the only problem I have with the current tree is the spacing is too wide. In a heavily commented game, too much of the time I just see a set of horizontal lines running off the screen to the right. Is it possible to add an option to adjust the spacing between nodes?

or a collapsible tree?

[ewan1971]

Personally the only problem I have with the current tree is the spacing is too wide. In a heavily commented game, too much of the time I just see a set of horizontal lines running off the screen to the right. Is it possible to add an option to adjust the spacing between nodes?

or a collapsible tree?

That would work! Actually, I think the heart of the problem really is how best to display a commented game with a large number of variations. There is no need to lay out the entire game tree all the time, but to only display the relevant variation as one scrolls to the move that has that variation.

This would solve all problems...