In fischer time, your clock runs down and when you make a move time is added, so I’m not sure where the confusion or abuse is? As far as I’m aware, it’s functioning as designed and intended by Fischer himself.
Now he also did invent a Fischer delay system, which is closer to what you’re talking about, but still not overlapping. The delay is to account for the physical delay of moving around to hit clock buttons or place pieces etc… we do not implement this currently.
Fischer timing means that a preset increment is added to the player’s clock for each move. There are two “variants” of this system: adding that increment before the move (at the beginning of their turn), or after the move (at the end of their turn). This website simply follows the “after” variant.
I’m not sure if the timing system that you’ve described:
has a particular name. It certainly is not Fischer timing nor Bronstein timing. The interesting thing about the system that you propose is that one would have to actually move within 12 hours on average in order to keep their time remaining steady.
It really isn’t an issue, but originally, Fisher’s system didn’t have a cap on the amount of time that could be accumulated. But the system with a cap is quite widely used on correspondence game servers with all kinds of games (including Go, Chess…), so it actually isn’t an OGS innovation.
So if i’m playing game with using fischer 7d+1d/move, and i have 2 hours on the clock when i make my move, my time won’t increase and i still have only 2 hours. So i can’t be away from OGS over 2 hours straight unless taking the risk that my opponent plays and then it would lose on time, only thing i can do is to stay put and wait that my opponent makes his move, which he has to do within 1 week.
Did i understand correctly?
And if somebody thinks it is “abusive behavior” to use a lot of time, then
Nope, for each move your clock would increase by 1 day. The only exception is when the increment would exceed the cap, in that case your clock is set to the cap value.
Additionally the cap cannot be smaller than any of initial time and increment value, so for your scenario the cap would be at least 7 days, not 2 hours.
It is in fact Bronstein timing. The time control @SunPin initially described follows the idea of these two variants:
Bronstein delay: At the end of each turn, the increment or the time spent on that last turn is added, whichever is smaller.
Simple delay: At the beginning of each turn, a countdown with the increment time is done, apart from the main clock. Only after that countdown runs out, the main time starts running.
The functional difference between these two is that when you have little time on your main clock (less than the increment), you can’t use more than that time to make your move within Bronstein control, because you lose by timeout before the increment is applied. In the Simple delay case, the main clock is paused until the countdown is finished, so you always have that increment time available at the beginning of each turn.
If I understood Sunpin’s idea correctly, it was actually different.
It means that you have two options:
a)you move before the move time is up and get the increment added to your clock (less the time you spent thinking)
b)you do not move before the move time is up and you are not compensated/delayed/incremented at all and the time you took is subtracted
So if the delay was 24h and you moved in 23h59m, you gain 1m of thinking time, if you moved in 24h1m you loose 24h1m of your thinking time. But I doubt this would catch on.
In fact, it seems more like the conceptual opposite of Bronstein or simple delay (within the family of time systems that delay/increment).
With Bronstein or simply delay, you have more time “slippage” if you move faster. Slippage means getting less than the full increment added. For example, with Bronstein delay and an increment of 24 hours, if you take 6 hours to make a move, you only get that 6 hours added back to your clock. If you take 36 hours, you get the full 24 hours. The time added is min(increment, timeSpentOnMove).
SunPin describes a system where the time added to your clock is also function of how long you spent on the move, but it is a very different function. Based on his description and examples, it seems that he is suggesting:
max( 0 , increment - timeSpentOnMove )
He gives the examples: getting 18 hours added if you take 6 hours to make a move, and getting 0 hours added if you take 3 days. Thus, with SunPin’s system, you have more time slippage if you move slower, and you get the maximum increment if you move almost immediately.
Also, note that with the Bronstein and simple delay system, your time “bank” only monotonically goes down, in the sense that at the beginning of each turn, the time you have before timing out can only be less than or equal to the time that you had last turn. With SunPin’s system (or Fischer timing), you could potentially accumulate more time into your time bank with each move (unless some maximum has been reached), giving you more time available on later turns.