Please implement the "target square first" moves input mode

[VasiliPupkin256]

The mode is popular in Arena Chess GUI and very handy for bullet time control. The idea is to let a user select a target square first and then the piece with a second click. If the piece is unambiguous then no second click is required. For example in the opening white can just click on e4 square to move a pawn, or click c3 and then b1 to move a knight. You can try it in Arena Chess GUI to understand the concept but be careful you'll become addicted to this input mode in no time. This move input mode is perfectly compatible with Click two squares and Drag a piece move modes and can be used cooperatively.

[niklasf]

How would this interact with premoves?

[VasiliPupkin256]

@niklasf you mean what to do if the user have just selected the target square which is unambiguous for the current position but after the opponent moves it is become ambiguous? Well. Either (1) make a very separate mechanism for it, remember just the target square for premove and skip the move completely if it become ambiguous in this situation, or (2) enter the move as it is seen for the current position, show it to the user and then use it as always. The (1) first option would also allow to enter a move that is impossible now but will be possible after the opponent do the move, i.e. the target square is not reachable by any piece now but after opponent frees the way or put a piece on the square it will be possible to reach the target square or capture it with a pawn and this will also speed up moves in a bullet games yet remain intuitive.

The other possible option (3) similar to the option (1) is to also remember the target square selection after the opponent move and allow user to clarify the move by choosing a piece if it become ambiguous. This option seems counterintuitive to me. The user would also need to do additional clicks and unselect the target square if it not intended for the move after the opponents move which would turn it into an annoying mess. It is also very different from the current lichess gaming interface to keep the selection between moves.

[VasiliPupkin256]

The way you play in this mode is this: a) reach the target square and click it b) always aim for the piece to click it and complete the move if the game engine determine the piece you are planning to move after (a) you clicked the target square then you just skip the (b).

So, the user will also click (b) on the piece anyway. If the opponent finished the move in between then try to use the target square as premove if possible. If the opponent didn't do the move then the user will have time to choose the piece (b) and complete the move which will be used as premove afterwards. If the opponent finished the move but the target square is ambiguous then the user will just drag the piece he already reached during his time. Seems rather intuitive to me.

[niklasf]

Thanks for explaining. This seems like a very efficient input mode. In fact it would probably significantly change the hyperbullet meta.

Target-square-first seems a bit more prone to misclicks than two-click, but that's probably worth it. At least for analysis (where there will be no consequences) and for bullet timecontrols (where the extra efficiency might be worth the risk). If we're going to implement this it would probably be for analysis first.

It's good that there is basically no difference between premoves and normal moves. (In fact that's a requirement: A click with the intent to enter a premove will not always come in time to be a premove).

However in the presence of premoves it seems to conflict with the two-click input mode. I am thinking about this scenario: On my opponents turn, I click my own piece. Now with target-square-first input mode, that would be a premove to recapture on that square. With the current input that could be the start of a two-click move. So there would have to be a setting: Either target-square-first OR two-click.

[samcal]

Another unfortunate side effect of this interface involves what to call the option in the game behavior preferences, since the current option of "click two squares" could also describe this new behavior. Not insurmountable, just kind of a pain with i18n and all.

[ddugovic]

Also this has the unintended consequence of a misclick (either a left-click accompanying a right-click, or a left-click on a square not thought to be a valid destination square; or a square thought to be a valid destination for a different piece which just became pinned in a non-obvious way) unintentionally triggering a move.

Also this has the semi-intended consequence of spamming clicks to discover legal moves in dire time pressure (when the opponent is checking the king from a distance), thereby using computer assistance built into Lichess.

[VasiliPupkin256]

@ddugovic a popup yes/no dialog to approve every moves would help those who randomly click on squares in dire time

[ddugovic]

@VasiliPupkin256 What if the user has a popup blocker installed (or installs a script to autoconfirm/auto-dismiss the dialogs)?

[samcal]

@ddugovic @VasiliPupkin256 It's been a while since I've played correspondence, but that has a confirmation right? Wouldn't be affected by a blocker. I'm not as worried about mouseslips though, that's just part of online chess imo.

[stale[bot]]

There has been no activity on this issue for 2 years. It will be automatically closed in 2 weeks. If the issue is still relevant, please briefly explain (or remove the label). Feel free to reopen at any time.

[VasiliPupkin256]

I don't think a feature requests should be marked as stale. It is not implemented though.

[ddugovic]

As noted above It has an edge case which breaks it at a design level even before the first line of code is written. This proposal is a solution in need of a problem:

However in the presence of premoves it seems to conflict with the two-click input mode. I am thinking about this scenario: On my opponents turn, I click my own piece. Now with target-square-first input mode, that would be a premove to recapture on that square. With the current input that could be the start of a two-click move. So there would have to be a setting: Either target-square-first OR two-click.

[VasiliPupkin256]

@ddugovic I have already answered this before. This input mode is only accept the input if the move in unambiguous. No need to think of counterexample trying to invent a situation when the entered move will be ambiguous. In this case a "recapture" is ambiguous just as described and a single click on the piece wouldn't be enough to enter a premove and the UI should wait for the second click.

[TBestLittleHelper]

I would love to see this added. Also worth noting that "Smart Move" is now a FIDE accepted input format.

3.6 The following additional options may be activated and used by the player: a) Smart move: the player may play his/her move by selecting a single square when a unique move can be done involving that square.

https://www.fide.com/docs/regulations/Annex_6.4%20Fide%20Online%20Chess%20Regulations.pdf

Also there are some situations where it's never your opponents turn (Puzzle Storm and Analysis boards). To sidestep the premove discussion over, it would be a good idea to have Smart Move for these features anyway.

[ddugovic]

In my opinion "Smart Move" is unsuitable for rated play but otherwise could be fun.

As noted above It has an edge case which breaks it at a design level even before the first line of code is written. This proposal is a solution in need of a problem:

However in the presence of premoves it seems to conflict with the two-click input mode. I am thinking about this scenario: On my opponents turn, I click my own piece. Now with target-square-first input mode, that would be a premove to recapture on that square. With the current input that could be the start of a two-click move. So there would have to be a setting: Either target-square-first OR two-click.

[VasiliPupkin256]

@ddugovic please stop. It is not a "solution in need of a problem" it is a valid input mode already implemented in some chess UI. This input mode should only accept single click move when it is unambiguous and the quoted text discuss the situation of an ambiguous move but even then the quote is not a blocker it only promote to add a settings for the input mode priority, which is also possible. This input mode is not an easy to implement probably but it is not an artificially invented problem without a solution either.

[ddugovic]

I am not claiming any other such thing as it being artificial, just that:

1. It is a form of engine assistance,
2. There are corner cases which cause unintended consequences.