Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding the following features for go/variants/quantum #222

Open
zcbwh opened this issue Mar 28, 2024 · 6 comments
Open

Adding the following features for go/variants/quantum #222

zcbwh opened this issue Mar 28, 2024 · 6 comments

Comments

@zcbwh
Copy link

zcbwh commented Mar 28, 2024

Hello fellow developers and go enthusiasts, We wonder if someone could help with adding the following feature for go/variants/quantum: 1. Save games 2. Rating (like ELO) 3. Undo request; 4. Calculate the results based on the following rule (such that it becomes an incomplete information game): Before the start of a Quantum Go game, players are required to designate either board 1 or board 2 as the chosen board (neither player knows the other's choice). When the game ends, if both players initially choose the same board as the chosen board, the winner is determined by the score on that board. Otherwise, the winner is determined by the weighted average of the scores on both boards.
Many thanks!

@merowin
Copy link
Collaborator

merowin commented Mar 28, 2024

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).

  1. 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).

  1. 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
Copy link
Author

zcbwh commented Mar 30, 2024

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
Copy link
Collaborator

benjaminpjones commented Apr 5, 2024

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?

@SameerDalal
Copy link

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.

@benjaminpjones
Copy link
Collaborator

benjaminpjones commented May 20, 2024

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
Copy link

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.

  1. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants