Adding the following features for go/variants/quantum

[zcbwh]

Adding the following features for go/variants/quantum

[SameerDalal]

Looking into the save feature, I think we would need to create our own SGF file generator and interpreter.

While the moves on both boards may be the same, if a quantum piece is captured, the changes on both boards are likely to be at different coordinates. A typical SGF viewer like Sabaki may not be able to handle this since it can’t manage two boards simultaneously. Please correct me if I am wrong.

We should also add a variation parameter. Eg: VA[quantum] in the SGF file so that this feature could be used for other variations.

[merowin]

Some thoughts:

1. Save games

Downloading the game moves is certainly possible. Some of our variants (including Quantum Go) save the moves in Smart Game Format (SGF). So I believe the produced files could then be opened by SGF Editors like Sabaki. But the games would not be display in the same way as on the website (e.g. for Quantum Go, a normal SGF reader would not display two boards).

3. Undo Request

This would be nice to have for all variants. It would be desirable if we could implement this without adding complexity to the variants (i.e., without handling "take-back" moves in all variants, if possible).

4. Making Quantum Go to be an Incomplete Information Game

Should this be the default rule for all games of Quantum Go, or should it be configurable whether this rule is used or not?

[zcbwh]

Thanks for your prompt response! I agree that saving may need a different format, but perhaps we could start with the regular SGF? That is there will be two .SGF one for each board; Note that for the second board, it also would need to be Black, White, Black, White--the current way of displaying is not optimal because it shows White goes first on the second board, so could this be fixed? I agree with you on "Undo Request". Regarding 4, could we make one quantum variant where we count the average of both games as the result (complete information), and another quantum go variant where it is an Incomplete Information Game?

[benjaminpjones]

I agree that saving may need a different format, but perhaps we could start with the regular SGF? That is there will be two .SGF one for each board;

I think a single SGF file would be sufficient. SGF stores move coordinates, not board states, and the moves are the same on both boards.

the current way of displaying is not optimal because it shows White goes first on the second board, so could this be fixed?

I think I understand what you're saying, although the intent was not to say "this move was placed by white", but rather "this stone will function as a white stone throughout the game".

This would be a a small thing to change - I can share some code pointers if you or someone else is interested in making the change to just solid green on the first move.

Regarding 4, could we make one quantum variant where we count the average of both games as the result (complete information), and another quantum go variant where it is an Incomplete Information Game?

This is a little more in-depth change, but its possible, and again, I'd be happy to work with a willing implementer.

My main question is UX: how do users select the board? Would this get easier with #134?

[benjaminpjones]

That seems correct. I realize that if the goal is to view in a standard SGF editor, then it makes sense to output two files (representing quantum capture with the AE field?)

Generally, captures are not explicitly included in the SGF, which is why I commented that one file should be sufficient earlier.

[SameerDalal]

Sounds good. Here are the two versions I could work on:

1). The software will create a modified SGF file to include all the game data in one file. This may break some format rules of the standard SGF file and would be unusable by other SGF editors except for ours. But regardless, most SGF editors won't be able to handle the quantum version anyways.

2. The software will create two files that follow the SGF format. These files could be opened by SGF editors, but the downside is that the user would have to keep two files per game.

I'll start working on this feature and see what works best.