New time control mechanism for simuls

[TheBigGreekChess]

It would be extremely helpful to be able to give different time controls in simuls to opponents in order to be able to assess better the length of simuls. I have a team with nearly 8000 members on lichess - TheBigGreek - and started to play MEGA-Simuls against a big number of opponents. It also would be helpful not to have a limitation of 100 opponents. Why is that? Thx!

[Eselce]

I second that! Simuls with some 100 participants tend to be unbalanced, you need to have a huge increment to manage that, but then, each player has too much time for the game. We've tried 60 to 180 seconds. Even more players in a MEGA simul had some of them waiting almost 2 hours for their first move...

[schachprofinot]

So do I! The host absolutely needs other time controls, especially the additional time should be different for the host than for the participants.

[Klickmichi]

This would be a great issue. We want to play with more then 100 players sumultan. And we need enough time for the host.

[Klickmichi]

Here is the code for the extra time for the simul host.

https://github.com/ornicar/lila/blob/e227700d42d37664498bd7e5cc5e4c14661be421/modules/simul/src/main/SimulForm.scala

If you replace

val clockExtras = (0 to 15 by 5) ++ (20 to 60 by 10) ++ (90 to 120 by 30)

by

val clockExtras = (0 to 15 by 5) ++ (20 to 60 by 10) ++ (90 to 120 by 30) ++ (120 to 600 by 60)

then the host can add up to 10 hours extra time, this should be enough time.

[schachprofinot]

@Klickmichi I do not think that this would solve the issue. The point is that there should be separate time controls also for the increment, not just for the basic time. I do not know scala, but it looks to me like your proposal would just add another option for increments, but these would still apply to both, the host as well as the participants.

No, I see now that actually your proposal would add the option for up to five hours extra time for the host, but it would not change anything with respect to increments. What @TheBigGreekChess would like to do (and that is what he said in his stream yesterday) is have 3 seconds increment for the participants, say, and, e.g., one minute (or more) for himself (or other such options).

[ornicar]

simuls with more than 50 players last way, way too long, and no player has the time to wait it through. They just drop during their games.

100 is completely unreasonable and there's no way we'll allow even more.

[Eselce]

@ornicar I see your point on 100+ players, but there is still the issue of allowing different (independent) increments for organizer and participants. That's also an issue for smaller simuls. At least it was possible for the initial time chosen, why not for the increment?

[schachprofinot]

@ornicar @Eselce Exactly my point. Also, while one could argue about the sensibility of these mega-simuls, we are certainly grateful for being able to have at least 100 participants, since last week and yesterday there were even roughly 180 people who wanted to participate (they all had to be in @TheBigGreekChess 's team). This is currently an experiment and we are aware that it only really makes any sense if the separate increment option is added.

Furthermore, about the waiting: in our case we can also follow the whole simul live in the stream, which makes it much more enjoyable. Yesterday, e.g., of the 100 participants, only 1 (!!) resigned early (after move 1), everyone else stayed till the end (took 5+ hours ...). So, this seems to be a question of taste /technical setup.

And, before I forget: thanks, @ornicar , for the amazing work on Lichess, which I gladly support as a patron.

[Klickmichi]

@schachprofinot yes that's not exactly that what @TheBigGreekChess claimed. But if he has enough extra time as simul host he wouldn't need extra increment. This would be a quick fix. It would also be nice to have extra increment for the host later. But this needs a new control and variable. Should not be hard to implement but needs time.

@ornicar watch the "Mega Simultan" stream of @TheBigGreekChess on twicht. He is insane and i think he can play against 200 other players in simul. There would be also other GM or IM that wants to play such huge simuls.

https://www.twitch.tv/thebiggreekschach/video/797158660

[AndreEverts]

100+ participators: I think that should be decided by the host, not by the programmers. If there are no technical reasons it should be possible.

different increment for host/participators: If the effort is not too big, I would support this idear too. Again, the host would have more control about his simul.

[Jeremx03]

i really like the idea of tbg. it makes it much more fun to play

[maletin]

What should the contender do with three hours at the end? What do you think about the Bronstein delay? https://en.wikipedia.org/wiki/Chess_clock#Timing_methods

[wielandp]

I saw two of his "Mega Simultan" streams. I find it hard to watch, but it is possible :-) With some breaks I took it was even fun. Adding options does not hurt other players.

[joka921]

I have provided an implementation for this. It allows setting of base time and increment independently for host and participants. This allows replicating the old mode (same increment, longer base time for Host) As well as the new modes requested by @TheBigGreekChess (less increment for participants).

Feel free to test, review and discuss it.

7615

[TheBigGreekChess]

Thank you!

[joka921]

@TheBigGreekChess I am sorry to inform you, that @ornicar has argued, that there is no sufficient use case for having different increments for black and white and thus closed my pull request without considering it. As it seems, there will be no possibility to play Megasimuls with useful time controls on Lichess in the foreseeable future.

[TheBigGreekChess]

Thats really a pitty. Would it be really so much work to implement this feature? I mean, we are just talking about the possibility to implement different time control for the host and for the opponents. (not black and white btw.).

[joka921]

It is in fact not that much work and I have already done it. Typically at this point, you formulate a so called "pull request" which says "I want to add the following code to Lichess" and then this implementation is reviewed and discussed. That's what I did and the reply was:

"I don't want to add the complexity of having different increments for each players of a game. This use case is not enough to justify it."

In fact, there already is a different increment implemented (the berserk mode!) and there already was different base time for two players (e.g. the extra simul host time).

So in my opinion, this is a small evolution instead of a revolution and I even cleaned up some inconsistencies. I don't really follow the decision of the (benevolent) dictator here

[TheBigGreekChess]

"I don't want to add the complexity of having different increments for each players of a game..." What complexity? It would only give an additional option. The status quo would not change. Anyway...Thanks for the clarification. I assume this is it now and it stays the way it is.

[dspyrhsu]

Hi @joka921, thank you very much for your effort!

Actually, @ornicar, why even keep this issue open, if a pull request is not even considered? As @joka921 mentioned, the time controls are different already and the new implementation just adds more options without, it seems, adding to the complexity. The use case is there - what is the harm in merging the pull request? This is a genuine question, by the way, since I obviously do not know your CI/CD procedure (or whatever approach you take on releasing new features).

[wielandp]

How about the second best way to do it. Giving option for more extra time for the host. Now the maximum is 120 min. How about 300 and 600 minutes (5 and 10 hours). This should add no complexity, no translations and no communication change.

[joka921]

@dspyrhsu Thanks for supporting our cause! @wielandp @TheBigGreekChess More extra time for the host would be an option (and I agree, this is much simpler to implement). The realistic scenario would then be: Host plays 4 hours + 10 seconds (the last two 100 people simuls where roughly this long) Participants play 10 minutes + 10 seconds

IMHO this would somewhat solve the issue of participants collecting hours of time in addition. However this is still asymetric because the host is very likely to get into time troubles if many of the games last longer than expected (the 10 seconds increment does not really help the host if it is divided by 100 boards. This would lead to the host presumably setting an even longer base time ("I assume to be able to do this in 4 hours, so I'll give myself 6 hours, then there's no problem if I need 5"). In this case, the host basically plays unlimited time (the overall time limit is with very high probability longer than the maximum duration of the whole simul). This somewhat limits the challenge for the host to get better/faster.

Example scenario for the proposed time control:

Host plays 2 hours + 180, meaning "In 2 hours I have to finish so many games, that an Increment of 180 seconds suffices. And If the participants even only get e.g. 5+5 the whole duration of the event can be adjusted to a reasonable time with some experience.

I hope this was clear, TLDR: More extra time would IMHO improve the situation, but not solve all the issues, but I am of course willing to openly discuss this from the different perspectives of programmers, chess professionals and maintainers.

[TheBigGreekChess]

I like the idea of Wieland a lot. Simple and no complexity at all. The rest is up to the host to find out, what works best for him.

[Eselce]

@joka921 Thank you for your effort in implementing this. Seems to be a fine middle-of-the-road solution without adding too much new variables or structures. Would solve this issue quite easy. I understand why to avoid complexity (not in usage but in maintenance), but this looks very genuine.

[wielandp]

Hello @ornicar, what I wrote 8 days ago is the same like @Klickmichi wrote 22 days ago. Is there a way to get this simple change implemented? How does lichess accept proposals?