I am a Free Internet Chess Server (freechess.org) refugee. I'd like to tell you about how the rematch behavior of that service differs in a significant way from that of lichess.org.
At FICS, when I'm done playing a game I can set up a seek AND a rematch at the same time.
The motivating emotion is, I don't care whether the player I just finished playing with agrees to a rematch or not, and if he does not I want to play someone else.
As it stands, I have to click "rematch", wait to see if the person accepts the rematch and if not, click "new opponent". This adds up to a lot of clicking if I play 20 blitz games in a row.
This is related to the bug reported elsewhere that "New opponent" sometimes includes the just-played player as the next game, which is clearly wrong (or at the very least, horribly mis-labeled). So I would suggest reworking the rematch/new game semantics as follows:
1) "New opponent" - seek game from set of all players, except the one most recently played.
2) "New game" - seek game from all set of players, including one most recently played (no priority).
3) "Rematch + new game" - seek game from all set of players, but give player most recently played 5 seconds to accept rematch before general matching algorithm.
4) "Rematch" - seek game from just-played player only.
One of the things FICS has going for it is its command line interface, which allows players to do complicated seek algorithms and aliases, without necessarily needing to build a bunch of UI around it.
So as an alternative to building something complex like the above, maybe just build a RESTful API or other command line utility that sophisticated players could use. I looked at the current lichess API, but it seems limited in that it doesn't allow one to submit seeks but perhaps I am missing something.
-firearm
At FICS, when I'm done playing a game I can set up a seek AND a rematch at the same time.
The motivating emotion is, I don't care whether the player I just finished playing with agrees to a rematch or not, and if he does not I want to play someone else.
As it stands, I have to click "rematch", wait to see if the person accepts the rematch and if not, click "new opponent". This adds up to a lot of clicking if I play 20 blitz games in a row.
This is related to the bug reported elsewhere that "New opponent" sometimes includes the just-played player as the next game, which is clearly wrong (or at the very least, horribly mis-labeled). So I would suggest reworking the rematch/new game semantics as follows:
1) "New opponent" - seek game from set of all players, except the one most recently played.
2) "New game" - seek game from all set of players, including one most recently played (no priority).
3) "Rematch + new game" - seek game from all set of players, but give player most recently played 5 seconds to accept rematch before general matching algorithm.
4) "Rematch" - seek game from just-played player only.
One of the things FICS has going for it is its command line interface, which allows players to do complicated seek algorithms and aliases, without necessarily needing to build a bunch of UI around it.
So as an alternative to building something complex like the above, maybe just build a RESTful API or other command line utility that sophisticated players could use. I looked at the current lichess API, but it seems limited in that it doesn't allow one to submit seeks but perhaps I am missing something.
-firearm