add button to submit moves

[JonKo314]

Adds a client-side option to protect against misclicks by adding a move to the GameResponse before it's sent to the server. That's a bit problematic, because it leads to side effects which need special treatment, as the usage of the resetMoveToSubmit() method shows.

It might be better to do this with the board components, because those have to display the move, but then we'd have to implement it for different variants.

[merowin]

Nice, looks good to me!

That's a bit problematic, because it leads to side effects which need special treatment, as the usage of the resetMoveToSubmit() method shows.

One possibility to consider may be to not push the moveToSubmit into gameResponse.moves, but then add some logic to the computed function of game. That may allow us to avoid certain UI aspects being updated (e.g. game result, next to play indicator) if we want that.
Not sure if that helps with the reset function though :D

[benjaminpjones]

Awesome! Yeah this seems super important for correspondence.

I agree pushing into the GameResponse seems weird, but I'm fine with it. The main concern I have is that this is one more feature we will need to re-think when we move the moves logic server-side. (#174, #48)

[merowin]

That's a good point. What we need here is like a "move preview", and taking the normal move transition is kind-of conflicting with hidden information variants, where moves might reveal new information.

[JonKo314]

That's a good point. What we need here is like a "move preview", and taking the normal move transition is kind-of conflicting with hidden information variants, where moves might reveal new information.

Yeah, but the hidden information should never be shared with the client in the first place, so I think that's another issue. I agree about the "move preview" though.

[merowin]

I agree, I was just thinking that for variants with hidden information, we can't use the normal move transition as a move preview.

But all that doesn't need to hold this PR back, I think.

[benjaminpjones]

I think this actually does make it a lot easier to cheat. For parallel games, if someone has a setting on and ends the round, they can see opponent moves without submitting.

Granted, you can already do this by looking at your network tab. But yeah I think if we could land on a solution that doesn't involve moves, it will make our lives easier when it we push this stuff to the server.

[JonKo314]

I think this actually does make it a lot easier to cheat. For parallel games, if someone has a setting on and ends the round, they can see opponent moves without submitting.

And it could put users into an uncomfortable position, even without the intent to cheat.

So now I think it would be better not to merge this currently.

[benjaminpjones]

Converted to draft given the concern for simultaneous variants.

Happy to discuss design - these are what I have in mind, but probably not the only options:

• Place a dummy stone or marker on the board, but don't do any game logic <-- my preference
  • Pro: Can be used for hidden info games
  • Con: Somewhat reduced experience for full-info games as we won't see captures previewed
  • Con: needs to be implemented for each board
• Keep this implementation, but turn it off for hidden info
  • Pro: full experience for full-info games
  • Con: no feature for hidden info/simul
• Hybrid of above (use moves for full-info, don't use moves for hidden info)
  • Possibly best user experience
  • Con: needs to be implemented for each board
  • Con: maintenance burden 😞

[JonKo314]

Another option would be to apply the game logic to the information the client is allowed to know about.

If a player wants to capture a stone by playing K10, but there is already a stone there which is unknown to the player, their new stone will be shown at K10 and the stone that is about to be captured disappears. Then the player submits K10 and only after that the collision is handled according to the game rules.

• Pro: Full experience for perfect information games
• Pro: Some experience for games with imperfect information
• Con: Requires a somewhat predictable game state even with imperfect information (maybe acting as if there was no hidden information isn't easy in some future variants)

[merowin]

I like this idea. Given (#48), maybe we can make it so a new instance of AbstractGame can be created from the game state. For hidden information games, that may be a partial state of sorts, and we can think of the move transition from a partial state instance as a move preview.

[benjaminpjones]

This has potential to give the user the highest quality experience. A couple of thoughts - nothing blocking:

Given (#48), maybe we can make it so a new instance of AbstractGame can be created from the game state.

We actually had an importState function originally, but I removed it because it wasn't used and only implemented for some variants. Will we want to make this function required? And how can we convey to variant implementers what is expected of this function?

For hidden information games, that may be a partial state of sorts

exportState() isn't even a complete representation for perfect info variants! For example, we leave out SuperkoDetector because it's a larger object and not very important for displaying the board.

---

Oh one more thought:

If a player wants to capture a stone by playing K10, but there is already a stone there which is unknown to the player, their new stone will be shown at K10 and the stone that is about to be captured disappears.

We actually don't yet preview the captures in this way after submission. See this Fractional game, where I try to capture a stone in the bottom left: https://www.govariants.com/game/6608a41233149f0bd9a1f055

It would be kind of strange to preview the capture, then undo it after clicking the button. Of course this can be updated to give the preview, but it does make me wonder if this would be an oversized burden for variant implementers.

[JonKo314]

It would be kind of strange to preview the capture, then undo it after clicking the button. Of course this can be updated to give the preview, but it does make me wonder if this would be an oversized burden for variant implementers.

Good point. I didn't really consider Fractional when composing the example above. It feels natural not to show the stone as captured in this case, because the moves of the other players aren't decided yet. So nothing happens until all moves of the current round are known, just as the game logic does too.

We probably also don't want to show previews for one color go.