150 move rule?

As mentioned in other threads, there is a small problem which might conceivably become a large problem regarding Twixt implementation on this server. Drawn positions are not automatically recognized. If one or both players refuse to agree to a draw, the game might go on for 572 moves. What would happen after that, I don't know.

So, I propose a rule change which is easy to implement. If a game lasts 150 moves, 75 by each side, and neither side has won, the server declares a draw.

What do you think?

I think it's time to whip out an old Ruby script.

Out of more than 48000 games, only 4 have had more than 150 pegs:

154 pegs in game 40348 between safe and vacsi

248 pegs in game 45896 between Barry and Claire

221 pegs in game 262993 between Dorraine and DENISE

161 pegs in game 741677 between kpato and lore

Hey! That last one's quite pretty! Are you sure you'd want to forbid it?

My first move stats skip any game with 100 moves or more. Here's the 100 to 149 set:

112 pegs in game 41069 between nightowl02 and safe

117 pegs in game 260341 between Laurentio (BSW) and Julee

122 pegs in game 850900 between sweetdancerteena and purplepokeypineapple

107 pegs in game 921521 between Steven and Pessoa

106 pegs in game 1036682 between matjazo and Steven

Those last two games involving Steven look like serious games, but arguably, are not meaningful anyway for first move stats, given the extreme number of gimme-more-time pegs in the border rows. However, getting back to automatic draws on peg limits, if there was a 100-move or 100-peg draw limit, those two games would have been affected.

99 moves is where it gets interesting: After 99 moves, World Traveller gave up against TwixtBot and let it win a drawn game:

99 pegs in game 986600 between TwixtBot and World Traveller

Perhaps World Traveller would have given it one more move if the 100th peg automatically triggered a draw.

Then again, TwixtBot must know something about draws, as its 91-peg game against blargdragon ended in a draw. I wonder how TwixtBot handles draws. Anyone know?

The 90-99 set is:

99 pegs in game 986600 between TwixtBot and World Traveller

96 pegs in game 671957 between bugaboo84 and babybach

93 pegs in game 386658 between Steven and dopplefunker

91 pegs in game 1144239 between TwixtBot and blargdragon

91 pegs in game 1033757 between Carroll and slaapgraag

The 80-89 set is:

86 pegs in game 142641 between Ego and lee

86 pegs in game 264785 between EMILY and Santiago

85 pegs in game 826705 between Matteo A. and 12

84 pegs in game 1074473 between Steven and David

84 pegs in game 240489 between Ralph Thomas Bednarczuk and powerrade

84 pegs in game 329992 between Sebastian Ilie and Zunitko

82 pegs in game 380626 between Steven and Les Hazlett

81 pegs in game 230620 between siena and Luka's~

81 pegs in game 1024436 between Steven and Frank!!

The danger of setting a peg limit too low is that Twixt has a long tail - it may encourage people to play differently, to try to get to N pegs instead of resigning. This sort of changes the nature of the game, especially the endgame, but only for long games... for worse? Or better?

I counter-propose a 100 move rule.

Has there ever been an official rule for what happens when a physical set runs out of pieces?

Cancel that; I counter-propose a 100- peg rule, not a 100-move rule.

Thanks for the data!

Whom would this new rule benefit, and would it interfere with anyone's good faith intentions? If the limit is 150 moves, it might have helped safe in safe-vacsi 154 moves, who was lost from early in the game, but his opponent decided to make frivolous moves instead of completing the winning chain. If vacsi knew the server would declare a draw at move 150 if neither side had won yet, he might have completed the chain on that move. But this is not the scenario which the new rule is intended to fix. The other over 150 move games contain so many frivolous moves that I cannot believe either player cared about the outcome.

A 100 peg limit might affect games like Steven-Pessoa 107 pegs with lots of "gimme time" border pegs. Or it might affect games like Ego-Lee 86 pegs which looks to me like both players were trying to win and knew what the object of the game was. I believe it's conceivable that a game like that might go over 100 moves, but not 150 moves.

So in a nutshell, it looks like a 150 move limit would not really help anyone the rule was intended to help, but it also would not interfere with players who are truly trying to win. The scenario I envisioned, where a drawn position is achieved by players who were actually playing the game, but then one side refuses to agree, has not happened as far as I can tell. A 100 peg limit might have helped Pessoa, but this is primarily due to all those "gimme time" pegs, and this might arguably be called interference with intention rather than helping.

Since I believe it's more important to not interfere with players who are both trying to play well, I still think 150 moves is better than 100 pegs (which would mean either 100 or 101 moves depending on whether swap was used.)

If my "nightmare scenario" ever comes to pass, a 150 move limit would make the game about 50% worse than an Amazons game where one side refuses to resign. That's a lot better than 572 moves.

Regarding an official rule for running out of pegs, I know of no published edition that mentions it, but at the WBC I told the players they could use pieces from other sets if they ran out, which of course no one did.

One reason players make frivolous moves is that they're having a conversation and the outcome of the game is no longer in doubt.

TwixtBot detects when neither side can complete a full path under any legal sequence of moves, and then offers draws every turn. It cannot force the other player to accept the draw, of course.

If TwixtBot's algorithm could be shared, than it would be ideal for LG to allow either player to demand a draw in a drawn game, I guess.

In game 986600 the opponent resigned on move 100 against TwixtBot in a drawn position. Did TwixtBot propose a draw on move 99? Clearly white is blocked from a win, and I see no sequence for black which can win. There is a sequence of vacant holes B2-D3-F2-H3-J2 which would connect to the black peg at K3, but this just connects the left side to the left side, not to the right side. This game was played in January of 2009. Did TwixtBot recognize draws then? Is this game perhaps the reason why you implemented draw recognition?

If the server could directly recognize a draw, that would of course be far superior to any N-move limit kludge. I would be in favor of the server declaring a draw when neither side has any way to win. Ironically, the Twixt PP rules make these situations more clear. One cannot argue that "maybe my opponent will remove a link." So this is another reason for this server to keep the PP rules.

On the subject of draws in the context of loooong games, I don't remember who suggested it first, but I like the draw-breaker where as soon as one person offers a draw the board is filled with the opponent's pieces, and if the opponent wins, that's the result of the game, but if there is indeed a draw, the one who offered it wins.

That can be most simply implemented by just making the offer of a draw "sticky" and automatic when stuck, so that you never need to play another move. The opponent just plays with himself until he accepts the draw (and thus loses), resigns, or wins.

FatPhil, one of the main purposes of the draw offer is to save time in a game which is not yet drawn, but which will become a draw with best play by both players. If the draw offer gives the opponent unlimited moves in such a situation, that would usually give the opponent a win. So that would mean both players would have to play the game out to a real draw before either dares to propose a draw. Perhaps in addition to a draw offer, a player could make a draw claim which would work as you describe in an overly long game like game 986600 with TwixtBot. But there's one aspect I don't follow: "if there is indeed a draw, the one who offered it wins." Why not end the game as a draw if the position is drawn?

If the server could recognize a draw and end the game automatically, that would be a better solution IMO.

I thought of something else. If this "sticky draw claim" were to be put into effect, in addition to and separate from the draw offer option, and the position is indeed drawn, but the opponent of the draw claimer refuses to accept a draw and continues to make moves, how would such a game end? This option is supposedly to replace software which recognizes a draw. So would the claimee be allowed to fill up the board with pegs? Suppose this game were part of a monthly or championship cycle. At the rate of one move every 36 hours, a player could hold up the show for over a year.

Part of the skill in a game would be recognizing a draw. Some would say that a program that tells players about a draw would be interfering with an unfinished game. Plenty of people can lose a potentially drawn game. They can even lose a potentially won game.

I agree with David -- if the LG server can quickly and positively detect a draw, using TwixtBot's algorithm, then it should automatically declare draws, in the same way that it now automatically declares a winner when someone connects their sides, with no intervention from the players. The current mechanism for offering and accepting draws should still be in place, since you don't always want to play out the inevitable.

Now that I think about it, draw detection in TwixtPP seems pretty simple: make a copy of the current board, fill remaining empty holes that are legal for Black with Black pegs and links, and check if Black connects; if he doesn't, then do the same for White, and if white has no possible path either, then it's a draw. Is this what TwixtBot does?

"FatPhil, one of the main purposes of the draw offer is to save time in a game which is not yet drawn, but which will become a draw with best play by both players."

If you assume best play by both players, neither player needs to play any of his moves. Or even be on this site.

"Why not end the game as a draw if the position is drawn?"

Because the person who detected that it was a draw first has read the board better. And better players should be rewarded for being better.

I think that only your opponent should be able to make you the winner of a drawn (or losing) position.

More about the offer-draw-for-a-win idea here.

"If you assume best play by both players, neither player needs to play any of his moves. Or even be on this site."

Consider the specific example of Alan Hensel versus spd_iv. Both players saw that best play by both sides from that point would lead to a draw. Reading out an endgame position precisely is not beyond the capabilities of human beings. But if either player had allowed the opponent unlimited moves from the point where a draw was agreed, that other player could have won easily.

"Plenty of people can lose a potentially drawn game. They can even lose a potentially won game."

But Alan and I do not suggest that the server should interfere with a potentially drawn game, only an absolutely drawn one. In other words, the server would declare a draw if and only if neither player could win even if all remaining vacant holes (other than opposing border row holes) were filled with that player's pegs.

You could have an argument for the case where it is IMPOSSIBLE NOT TO DRAW.

And you have pointed out a feasible criterion which works for Twixt.

Of course in other games people would have to approach this problem carefully. For example, in Chess a king and two knights versus a lone king is a draw with best, and in fact most kinds of play, but it is possible to concoct a win with cooperative play so I have read.

This is not such a big problem in chess due to "pawnless 50 moves" and "dinamic 3-fold position repetition" rules.

BTW bare king should be more than cooperative to be checkmated by 2 knights. K+N+N against K+P is another thing, though.

No with cooperative play you can checkmate the other king with two knights. Imagine black K on b8 and white K on b6 and the white Knights in position, so you move one knight to c6+, the cooperative black king moves on a8 in the corner, then you move the other knight on c7 check mate.

And I think 100 moves are enough for TwixT, the game strategy wouldn't change... Or it may change something for a percentage that is probably lower than those of drawn games.

What I meant with the "more than cooperative" statement is that, to be checkmated, the player with the bare king should walk so deeply and consciously into the checkmate position that I would call that conspiration not cooperation.

As regards game 986600, indeed the bot is a work in progress and did not always have draw recognition.

The algorithm to detect "any possible winning path" is pretty simple: you just use Depth First Search to find the set of reachable points from the left side going over knight's moves, not allowing yourself to step on White pegs or go over a White link. Whether Black pegs or links are present is irrelevant for this search. If you get to the right side, then Black "could possibly win" under some sequence of moves, and if you run out of nodes to expand then Black cannot possibly win.

If Black "cannot possibly win" then you try again top-to-bottom for White, and if it turns out White "cannot possibly win" also, then you have a draw.

As a side comment, is this problem with unending drawn games merely a theoretical possibility, or has it actually happened here on LG?

Heh your game 986600 was the closest thing to it so far. It must have seemed unending to World Traveller. At any rate, due to the misleading title of this thread and its excursions into unrelated topics, I started a new thread to talk about what I finally decided to talk about, which is automatic draw recognition implementation on LG.