this is a stronger case for implementing the ko rule. however, i did just upload an sgf to ogs that breaks the ko rule: Black vs. White
did ogs not let you do this?
Ah, so youâre viewing the purpose of this tool more as producer of SGFs to be consumed by other pre-existing tools? (i.e. primarily oriented to compatibility for output, rather than compatibility for input)
Fair enough!
For what itâs worth, even on that side as I user I always lean towards permissiveness. Iâm often a bit sad as a user when a valid feature of SGF format is forbidden or unimplemented by an editor. It just means that to create the SGF that I want to create, I have to go searching around for other tools. (Iâve run into this a bit with many SGF editors not supporting rectangular boards, despite the SGF format explicitly having provisions for it, and specifically when Iâm trying to run analysis or record positions when exploring optimal play on small rectangular sizes).
The concern would presumably be that one can accidentally/unknowingly play a self-capture or ko-illegal move that then makes an SGF incompatible with some other server or tool, but one canât accidentally/unknowingly set the size of the board to a rectangle when one didnât mean to, so e.g. supporting the feature of SGF that lets boards be rectangular rather than just square is pure upside to users, whereas supporting suicide or more-permissive ko logic might not be. Maybe some compromise is possible though?
1 Like
this thread has honestly given me a lot to think about already.
originally, the purpose of the tool was to simply have a board to put stones on (producing an sgf was a secondary feature that didnât even exist in the prototype, and when i implemented it i thought it would be desirable to produce sgfs that work with existing go servers).
this tool is very intentionally not built to be an sgf editor. there are plenty of tools out there that exist for this very purpose. still, iâm trying to remain open to ideas!
3 Likes
Seems possible to submit mutliple moves with the same color as race condition. See this move tree (i did not fiddle with the color buttons at the top)
2 Likes
I was mostly asking to verify that I understand you correctly that you were disallowing suicide. I agree with hexahedron that maximum permissiveness is better for the same reasons youâre not enforcing ko. sometimes you just want to set something up on the board without worrying about those things
1 Like
Based on what @jarstar has said I think it could go either way. It depends on whether the goal is for the tool to beâŚ
- A way to collaboratively produce games/records/sgfs that are to be always readable by more other servers/tools (at the cost of being sometimes less accepting of and not supporting certain kinds of moves or input that arenât universal among other tools).
- Or a way for players to collaboratively interact on a board in a way that is more flexible and expressive like they could on a physical board (at the cost of other tools being sometimes less accepting of the output produced by this tool when that higher permissiveness is used).
Or any compromise in between those two extremes.
3 Likes
yeah, the OP suggested it was the second, with the focus on simultaneous editing. Personally, I think sticking with that would make it stand out as something which serves a unique and useful function than the latter
yep, indeed that appears to still be an issue! continuing to try to figure out the best way to solve it
- A way to collaboratively produce games/records/sgfs that are to be always readable by more other servers/tools (at the cost of being sometimes less accepting of and not supporting certain kinds of moves or input that arenât universal among other tools).
- Or a way for players to collaboratively interact on a board in a way that is more flexible and expressive like they could on a physical board (at the cost of other tools being sometimes less accepting of the output produced by this tool when that higher permissiveness is used)
this is definitely something i should think about. in my mind, the second point is more important, while the first one (nice sgfs) has emerged as a highly desirable trait.
regardless, iâm grateful to everyone here for the feedback!
3 Likes
Perhaps could transmit move number along with the move. That way, if two users submit at the same time, the server can choose which one is truth and throw the other away
1 Like
Another nice tool I assume it would be nice to have integrated into OGS (something like âmultiplayer study boardâ)
1 Like
Or you could use some other optimistic concurrency control, like have clients send the full board state (before the state change) to the server, along with the state change actioned by the local user. That would allow the server to reject one of concurrent state change attempts.
Number of people watching may be interesting but I would find it really useful to have some kind of accounts. I am thinking about very basic guest accounts that only require a nickname (maybe only as session variable). Seeing who played what move can make this the go-to tool for multiplayer Go variants.
I have considered adding nicknames. but how would you like to see who played what move?
Maybe like in google docs, where the curser of others have different colours. Stones could have a slight colored shadow for a few seconds after placing matching the nickname colour. An if you hover of the stone the nick also shows and in the game tree the colours could show in the graph lines
That or just an outline around the stone in the game tree, again matching the colour of a nickname.
All reasonable ideas I would think, assuming the nickname system already exists 
1 Like
Why not a chronological log of the moves for each user, directly linked with the moves on the board? ,(or a tree)
An eraser would be an important feature
Is this already âa great step forwardâ for OGS âReviewâ?
If we click on âReviewâ, then OGS opens a board in this system, with OGS chat alongside?
It strikes me that each placement might have a chat box⌠so you experience the conversation by clicking along the move tree in the direction youâre interested in and see what the people said as they place?
I love your app! I love that it doesnât prevent invalid ko moves, giving a good chance to teach about ko. It does prevent suicide, but thatâs simple enough to explain.
I love that it looks nice, that both sides always have control, that games, that SGF files can be uploaded and downloaded, and that the move tree is constructed. I love that it is a website, so it will work the same on all devices and not require storage.
The numbers that can be placed are a bit too small. After clicking Pass, the app seems to malfunction. And it is difficult to see how to switch out of edit mode after placing stones on the board, to resume play. But this is only a Beta release, and Iâm sure all that and more will be improved.
I love that you used the pure Bootstrap framework, so it can easily be edited in case you release it as Open Source in GitHub.
It is an excellent teaching adjunct just as it is and I feel encouraged to offer teaching to 35 kyu people who would like to learn Go. Thank you so much for filling this important need in the Go world!
4 Likes