Arimaa Forum - Print Page


    
      
        Arimaa Forum
        (http://arimaa.com/arimaa/forum/cgi/YaBB.cgi)
      

        Arimaa >> General Discussion >> 2008.07.01 Core Rule Changes
        
(Message started by: omar on Jun 18^th, 2008, 11:55am)

Title: 2008.07.01 Core Rule Changes
Post by omar on Jun 18^th, 2008, 11:55am

Since I may be traveling on July 1st, I decided to implement the rule changes a little earlier.

See this thread for the discussion of the changes.
http://arimaa.com/arimaa/forum/cgi/YaBB.cgi?board=talk;action=display;num=1206399208

1. First player to lose all rabbits loses the game. If both players lose all rabbits the player who made the most recent move wins. This eliminates the possibility of draw by both players losing all rabbits.

2. Repeating the same position (including side to move) for the 3rd time no longer causes the player to lose, but rather the move is considered illegal and rejected. The player should select a different move.

Title: Re: 2008.07.01 Core Rule Changes
Post by mistre on Jun 18^th, 2008, 12:05pm

Are these rules in effect for current postal games?

Title: Re: 2008.07.01 Core Rule Changes
Post by Janzert on Jun 18^th, 2008, 1:54pm

on 06/18/08 at 11:55:53, omar wrote:

2. Repeating the same position (including side to move) for the 3rd time no longer causes the player to lose, but rather the move is considered illegal and rejected. The player should select a different move.

It would be interesting to see, and also check than an edge case is correct, if someone would play a game such that the bot is left with only one repeating move and check that the game server stops the game at the third repetition with an immobilization win.

Janzert

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 18^th, 2008, 2:14pm

While I'm at it I also made a change to the Arimaa scoring function. This comes into play when the preset time for the whole game runs out. For example a tournament game might allow a maximum of 4 hours for the game to finish, but neither player has won within this time. The current rules call for the game to be stopped and a score used to determine which player wins. It doesn't happen often and so far only 6 games have been decided by score; none of which where HH games. Currently the score is determined as:

Score = R + P*(C+1)

R = Points given for how far the players Rabbits have progressed.
The row to which each rabbit has progressed is cubed (i.e.
raised to the power of 3) and these values are summed up to
determine R. The first row is 1 and the goal row is 8.
C = The number of Rabbits the player still has on the board.
P = Points given for the pieces the player still has on the board.
The value of each piece on the board is summed.

Value of each piece is:

1 - Rabbit
2 - Cat
3 - Dog
4 - Horse
5 - Camel
6 - Elephant

See this thread for previous discussion of the scoring function:
http://arimaa.com/arimaa/forum/cgi/YaBB.cgi?board=talk;action=display;num=1092524589

Ideally I would like to use accelerated time controls proposed by Karl which would eliminate the need for any scoring function, but it is a little difficult to implement and requires a lot of changes throughout the site where ever timecontrols are used or displayed. Since I want to eventually move away from using a scoring function I did not include an area for displaying the score in the new flash client. But if a human player ever needed to figure out the score it would be a real pain with the current formula. So in the mean time I decided to make the scoring function simply be that the player with more pieces on the board wins. In case of a tie the second player to move wins. This is probably not any better, but it's simple to state and simple to determine by looking at the board.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 18^th, 2008, 2:31pm

on 06/18/08 at 12:05:36, mistre wrote:

Are these rules in effect for current postal games?

Yes, they are in effect now for all games.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 18^th, 2008, 2:47pm

on 06/18/08 at 13:54:49, Janzert wrote:

I did not add this check. Currently the server would keep rejecting the 3rd repetition move and the game would end with the bot losing on time instead of immobilization. Actually to check this properly the server needs to generate player B's moves when player A's move is received and see that player B only has one move and that move is a 3rd repetition. This adds more overhead to the move checking logic which would have to be run on every move check but would only trigger in very rare cases.

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 18^th, 2008, 3:08pm

I'm thrilled with both of these rule changes. Thank you for implementing them, Omar!

Simplifying the score function can't hurt, although it mostly reminds me that we are lucky no game between humans has ever run out of time.

I'm a little leery of rule change in the middle of a tournament, since RonWeasley vs. mistre in the Postal Mixer might just have changed from a draw to a loss for mistre. But if mistre is not complaining, then I should hold my peace. Clearly he has not been playing for the draw anyway.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 19^th, 2008, 2:19am

on 06/18/08 at 15:08:21, Fritzlein wrote:

I'm a little leery of rule change in the middle of a tournament, since RonWeasley vs. mistre in the Postal Mixer might just have changed from a draw to a loss for mistre. But if mistre is not complaining, then I should hold my peace. Clearly he has not been playing for the draw anyway.

I was so caught up with trying to make these changes before I leave for travel, I forgot to consider the effect on the postal games. Sorry mistre.

Title: Re: 2008.07.01 Core Rule Changes
Post by aaaa on Jun 19^th, 2008, 4:22am

It would have to be beyond ironic if draws were abolished just about when we would finally get our first legitimate one.

Title: Re: 2008.07.01 Core Rule Changes
Post by RonWeasley on Jun 19^th, 2008, 7:19am

Omar,

If you look at the replay of a game won by rabbit extermination, the reason-for-losing field next to the non-winner's name says "undefined". I'm thinking you intend to put something like "No rabbits" there.

This rule had some effect on my postal game with mistre. Near the end, there were lines mistre might have tried where he would have had to trade his last rabbits for my horse and played for a draw. I remember seeing extermination chances for my rabbits when planning my move and avoiding those lines, partly because I didn't recall if that was a tournamant rule, but partly because I was playing for a win. I didn't think mistre could get a draw if he would have tried for one, contrary to one of Fritz's comments, and I think mistre had enough position that he was right to play for the win.

Title: Re: 2008.07.01 Core Rule Changes
Post by mistre on Jun 19^th, 2008, 10:08am

I was fine with the rule change. It really didn't dictate how I approached the endgame - RonWeasley forced me into goal threat mode after he hostaged my H.

Don't get me wrong, I would have preferred a draw over a loss, but I did not see a strategy that would produce such a result and since Ron was actively avoiding it, it wasn't ever really an option.

This game just goes to prove that even with so few rabbits on the board, it is still most advantageous to play for the win (extermination rule or not). I felt like if I played more defensive, I would have lost earlier.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 19^th, 2008, 1:30pm

on 06/19/08 at 07:19:20, RonWeasley wrote:

If you look at the replay of a game won by rabbit extermination, the reason-for-losing field next to the non-winner's name says "undefined". I'm thinking you intend to put something like "No rabbits" there.

For now only the Flash V2 client displays it properly.

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 19^th, 2008, 4:18pm

on 06/19/08 at 07:19:20, RonWeasley wrote:

I didn't think mistre could get a draw if he would have tried for one, contrary to one of Fritz's comments, and I think mistre had enough position that he was right to play for the win.

Just to clarify, I never analyzed the position. I didn't mean to assert that mistre could have gotten a draw by playing for one. What I meant by

on 06/18/08 at 15:08:21, Fritzlein wrote:

I'm a little leery of rule change in the middle of a tournament, since RonWeasley vs. mistre in the Postal Mixer might just have changed from a draw to a loss for mistre.

is that it was the type of position where a rule change could make a difference. I'm sure that, since two players both agree that no draw was in the offing, none ever was.

Title: Re: 2008.07.01 Core Rule Changes
Post by RonWeasley on Jun 20^th, 2008, 3:52am

Sorry, Fritz. I was a bit awkward in my wording. I should have said something like "contrary to speculation" and not singled you out and changed your meaning. And I agree that discussion about the possibility of a draw was appropriate for this game.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 20^th, 2008, 4:57am

on 06/18/08 at 13:54:49, Janzert wrote:

I thought of a way to check this more efficiently and added this check now. Only problem is that it is very hard to test this condition. If someone wants to test it that would be great.

It may also be possible for a player to have more than one move and all of those moves are a third time repeat. I don't check for this. I only check for the case where the player has only one move and it is a third time repeat.

Title: Re: 2008.07.01 Core Rule Changes
Post by Arimabuff on Jun 20^th, 2008, 7:30am

It would appear that if you eliminate your opponent's last rabbit at the same time you immobilize him your win will be counted as immo. and not elimination.

Title: Re: 2008.07.01 Core Rule Changes
Post by Janzert on Jun 20^th, 2008, 7:54am

on 06/20/08 at 04:57:25, omar wrote:

It may also be possible for a player to have more than one move and all of those moves are a third time repeat. I don't check for this. I only check for the case where the player has only one move and it is a third time repeat.

Yeah, I thought of this the other day as well but didn't mention it since the simple case wasn't handled anyway. The way I thought that might be able to handle it efficiently would be to incrementally generate moves stopping as soon as a move is found that isn't a 3rd repetition. This should be very fast in the common case but of course the move generator still needs to be fairly efficient for the rare time it does need to check a large number of moves.

Janzert

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 20^th, 2008, 9:16am

on 06/20/08 at 07:30:17, Arimabuff wrote:

It would appear that if you eliminate your opponent's last rabbit at the same time you immobilize him your win will be counted as immo. and not elimination.

Here is the order of the checking:

First check if the move is valid; 3rd time repetition and moves which don't change the board position are rejected here. If the move is OK then add move to the move list and check for win/lose conditions.

1. Check if our rabbit reached goal.
2. Check if opponent's rabbit reached goal.
3. Check if opponent has no possible move (immobilization).
4. Check if opponent's only move is 3rd repetition (immobilization).
5. Check if opponent lost all rabbits.
6. Check if we lost all rabbits.

If you immobilize the opponent, but doing so requires you to move their rabbit to goal, you will lose since a rabbit reaching goal is the most primary win/lose condition in Arimaa.

If you eliminate the opponents rabbits, but doing so causes you to become immobilized, you will win, since putting your self in an immobilized position is not a condition for losing (only after your opponent moves and you are left immobilized then you lose).

I suppose #5 could be done before #3, but I don't think it matters that much. Historically #3 came before #5.

Title: Re: 2008.07.01 Core Rule Changes
Post by Arimabuff on Jun 20^th, 2008, 10:25am

on 06/20/08 at 09:16:20, omar wrote:

...I suppose #5 could be done before #3, but I don't think it matters that much. Historically #3 came before #5.

I am perfectly OK with it, I was just relating it as a fact. :)

Title: Re: 2008.07.01 Core Rule Changes
Post by aaaa on Jun 21^st, 2008, 3:56pm

Given how well the threefold repetition rule has become established, what's the point anymore of forbidding null moves? For one thing, dropping that rule would simplify bot programming.

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 21^st, 2008, 4:47pm

Passing is not quite the same at three-fold repetition. If Arimaa allowed passes and forbid repetition, it would prevent you from passing only after your opponent has just passed. I don't know of any situations where you could pass your way to victory, or pass your way out of defeat, but I can see how either would be unappealing in some light.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 21^st, 2008, 5:26pm

on 06/21/08 at 15:56:27, aaaa wrote:

Given how well the threefold repetition rule has become established, what's the point anymore of forbidding null moves? For one thing, dropping that rule would simplify bot programming.

By "null moves" I assume you mean moves that do not change the board position.

If such moves are allowed, then it is equivalent to allowing a player to pass their turn; which I did not want to allow. I think I chose not to allow players to pass, because Chess didn't allow it. It is not something that I even contemplated when I was creating the rules.

But once (much after the release of the Arimaa rules) I was thinking how I didn't like seeing games suddenly end on time if a player did not make a move and ran out of time (this happens to me a lot at Blitz speed :-). As a possible solution I thought of allowing players to pass their turn and if a player did not make a move within the time allowed then it is as if they passed their turn and their opponent would then get to make another move. Thus, less games would suddenly end due to a player running out of time and more games would have a natural ending (g, m, e), though some might have forced passed turns in them. You do run into problems if both players keep choosing to pass. I suppose with 3rd time repetition check in place the player that passed first would eventually have to make a move and could not continue to pass. But then what if they don't make a move within the allowed time. I suppose at this point the game could be considered lost on time.

I just contemplated this possibility, but eventually decided that the timed out games didn't bother me enough to make these changes to the rules and reprogram the server :-) I am open to reconsidering the possibility of allowing a player to pass their turn. Has anyone experienced situations in a game where they did not want to make a move? In my own games, I think I've always wanted to make some move.

If a bot checks for 3rd time repetitions (which it should) then checking if the move does not change the board position is actually easier to do.

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 21^st, 2008, 6:17pm

on 06/21/08 at 17:26:28, omar wrote:

I suppose with 3rd time repetition check in place the player that passed first would eventually have to make a move and could not continue to pass.

Actually, I think it would work just the opposite. The player who passed second would have to move to avoid repetition. To wit:
1. Player A passes. This doesn't cause a repitition because there hasn't yet been that position with B to move.
2. Player B passes. This causes the position with Player A to move to occur for the second time
3. Player A passes. This causes the position with Player B to move to occur for the second time.
4. Player B can't pass, because it would cause a third occurrence of the position with Player A to move.

Quote:

I am open to reconsidering the possibility of allowing a player to pass their turn. Has anyone experienced situations in a game where they did not want to make a move? In my own games, I think I've always wanted to make some move.

I have never wanted to pass, and I can't recall a game where it would have been beneficial for a player to pass.

Actually, how the game plays is the main issue. In chess endgames there are occasionally double-zugzwang positions where neither side can improve position and each player would be better of if the other were forced to move. If you allow passes but disallow repetition, then getting into a double-zugzwang position has the odd effect of forcing the the player who isn't on move to get out of the position.

If Arimaa positions are never zugzwang, then the rule is irrelevant. If the rule is ever relevant, though, I would prefer it kept the way it is.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 22^nd, 2008, 8:26am

on 06/21/08 at 18:17:39, Fritzlein wrote:

Actually, I think it would work just the opposite. The player who passed second would have to move to avoid repetition.

Thanks for correcting me Karl. I think I would have preferred if the second player to pass could force the first player to make a move and not the other way around. To achieve this we would explicitly need another rule saying a player cannot pass two consecutive times.

Title: Re: 2008.07.01 Core Rule Changes
Post by aaaa on Jun 22^nd, 2008, 8:45am

If the repetition rule would not take into account whose turn it is, then the prohibition against passing would automatically follow and you wouldn't need two separate rules.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 22^nd, 2008, 8:46am

I updated the written Game and Match rules pages to reflect the recent changes to the core rules and scoring function.

http://arimaa.com/arimaa/learn/rulesIntro.html

http://arimaa.com/arimaa/learn/matchRules.html

[fixed the second link; thanks aaaa]

Title: Re: 2008.07.01 Core Rule Changes
Post by aaaa on Jun 22^nd, 2008, 9:29am

I think you meant this to be your second link:
http://arimaa.com/arimaa/learn/matchRules.html

Given the goal and elimination victory conditions, it would make sense to continue to stress the importance of rabbits when the time control limit has been reached, that is declare thereafter whoever has the most rabbits the winner with the number of other pieces only possibly serving as a tie-breaker (i.e. using a scoring function like 9*rabbits+other_pieces).

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 22^nd, 2008, 10:40am

on 06/22/08 at 08:45:19, aaaa wrote:

If the repetition rule would not take into account whose turn it is, then the prohibition against passing would automatically follow and you wouldn't need two separate rules.

That is true, although it creates a different oddity. Supposing a position has occurred twice with Player A to move. From then on Player A would be prohibited from creating that position with Player B to move. That's hardly the intent of the repetition rule, since the position with Player B to move is a never-before-seen situation, not part of an endless loop. The inelegance of this little quirk might balance out the inelegance of having a "no pass" rule.

Title: Re: 2008.07.01 Core Rule Changes
Post by RonWeasley on Jun 23^rd, 2008, 5:16am

on 06/21/08 at 18:17:39, Fritzlein wrote:

I have never wanted to pass, and I can't recall a game where it would have been beneficial for a player to pass.

Consider a bot bashing position where the bot has been herded into a position where its only legal move is to push the opposing rabbit onto a goal square. Per the previous discussion, the opponent must do something else.

My instinct is not to want a PASS option, but only because of the risk of weird side effects like this one.

Title: Re: 2008.07.01 Core Rule Changes
Post by mistre on Jun 23^rd, 2008, 5:43am

on 06/21/08 at 17:26:28, omar wrote:

But once (much after the release of the Arimaa rules) I was thinking how I didn't like seeing games suddenly end on time if a player did not make a move and ran out of time (this happens to me a lot at Blitz speed :-). As a possible solution I thought of allowing players to pass their turn and if a player did not make a move within the time allowed then it is as if they passed their turn and their opponent would then get to make another move. Thus, less games would suddenly end due to a player running out of time and more games would have a natural ending (g, m, e), though some might have forced passed turns in them.

I don't think it would ever be to your advantage to pass, as this is like giving the bot 4 free steps after which you surely will be in a worse position then you were before that.

Having said that, many times in bot games I would run out of time with a full move or partial move programmed, but I couldn't hit the submit button in time.

So, an alternative solution (if it is possible), is for the interface to force the programmed move when the time hits 1 sec. (without having to hit submit). Then the only way you could run out of time is if you did not at least have 1 step programmed when the timer hit 1 sec left.

Not sure if it is really worth the effort to implement. I definitely agree that passing a turn is not needed nor a good idea anyways.

Title: Re: 2008.07.01 Core Rule Changes
Post by aaaa on Jun 23^rd, 2008, 5:51am

So to summarize, the immobilization victory condition effectively exists to prevent the turn-sensitive repetition rule from forcing a player to give up the immobilization of an opponent. But I guess it can also be seen as a sort of "mercy rule" as it is hard to see the immobilizer not being able to goal otherwise. Then again, having a loss recorded as immobilization could be considered to be more humiliating.

Title: Re: 2008.07.01 Core Rule Changes
Post by Janzert on Jun 23^rd, 2008, 8:37am

on 06/20/08 at 09:16:20, omar wrote:

If this list could be put in the rules page or somewhere else it would be handy for future bot developers. I know I was looking for something similar when building OpFor.

Janzert

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 23^rd, 2008, 11:21am

on 06/23/08 at 05:51:13, aaaa wrote:

So to summarize, the immobilization victory condition effectively exists to prevent the turn-sensitive repetition rule from forcing a player to give up the immobilization of an opponent.

One could argue that a "no pass" rule obviates the need for an immobilization rule. However, speaking as someone who has twice written up the rules of Arimaa, once for Wikipedia and again for the Arimaa book I hope to publish, I am very sensitive to the comprehensibility of rules. In the rules, even if I have already said that a player must change the position on every turn, I would also have to say that a player with no legal move loses, or the readers would be confused. (In chess, for example, passing is not allowed, yet a player with no legal move draws, so the Arimaa rule can hardly be assumed.)

Alternatively, supposing that the rules allowed passing, and suppose that the three-fold repetition rule didn't take into account side to move, and suppose the rules specified that a player with no legal move loses. Although those rules would contain enough information to determine that immobilization is a loss whenever the immobilizer is smart enough to answer a pass with a pass, if the rules contained no explanation, readers would be confused about the rules when encountering immobilization, not to mention any other time a player passes. An explanation would still be necessary that two consecutive passes force a move if one is available and a loss if one is not.

In short, I expect that the immobilization rule does not at all exist for the reason you say; rather it exists to make the rules comprehensible. Perhaps we could rework four current rules to be restated as three logically equivalent rules, and that might save a programmer a few bits, but such a rewording could make a clear explanation of the rules longer rather than shorter.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 23^rd, 2008, 9:07pm

on 06/23/08 at 08:37:57, Janzert wrote:

If this list could be put in the rules page or somewhere else it would be handy for future bot developers. I know I was looking for something similar when building OpFor.
Janzert

One could look at he matchOffline code to figure this out :-)

I added this now to the core rules page. Thanks for the suggestion Janzert.

Title: Re: 2008.07.01 Core Rule Changes
Post by aaaa on Jun 24^th, 2008, 2:27am

Can you please make rabbit elimination have a higher priority than immobilization? It's pretty awkward for bot development otherwise, as one would either have to figure out the possible moves in the evaluation function or have to make partial evaluations at different stages.

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 24^th, 2008, 6:59am

on 06/24/08 at 02:27:49, aaaa wrote:

Can you please make rabbit elimination have a higher priority than immobilization?

I rather liked the principle that if a player's move simultaneously meets two victory conditions, then the player making the move wins. It's some kind of reward for being active, a confirmation that you sometimes have to sacrifice to win. So I was already uncomfortable with Omar's ruling that if you push an opposing rabbit to goal and simultaneously immobilize the opponent, you lose.

on 06/20/08 at 09:16:20, omar wrote:

If you immobilize the opponent, but doing so requires you to move their rabbit to goal, you will lose since a rabbit reaching goal is the most primary win/lose condition in Arimaa.

I guess once you are going the route of prioritizing victory conditions, instead of favoring the player who made the move, you might as well rank all the victory conditions as more or less primary. If we have to rank, I guess "having no legal move" is something to check only after all other victory conditions. It's a case that must be handled, but it isn't what the game is about. So I agree with aaaa's ranking. Intuitively what the game is about is goal, capture, and immobilization, in that order.

Title: Re: 2008.07.01 Core Rule Changes
Post by RonWeasley on Jun 24^th, 2008, 8:26am

on 06/24/08 at 06:59:05, Fritzlein wrote:

Intuitively what the game is about is goal, capture, and immobilization, in that order.

I agree with this.

On the PASS move proposal, I haven't quite followed the discussion to this point, but I would not like to see PASS be a move alternative.

Title: Re: 2008.07.01 Core Rule Changes
Post by Arimabuff on Jun 24^th, 2008, 10:52am

on 06/24/08 at 06:59:05, Fritzlein wrote:

I don't know. If you follow the logic of Chess for instance, when you castle you aren't authorized to put your King in check even if it is during a "virtual" position, that is during the castling procedure. That's equivalent to say that you can't put an opponent's rabbit at the goal line even if it is in the middle of a move. If we followed the logic of Chess then the first rabbit to reach the goal-line chronologically (stepwise) or the first last rabbit to be killed would decide who the winner is. Also following that logic, if you kill your last rabbit in order to immobilize your opponent then you'd be the one losing the game since chronologically speaking you’d be the first to be in a losing situation.

Title: Re: 2008.07.01 Core Rule Changes
Post by Arimabuff on Jun 24^th, 2008, 10:57am

on 06/24/08 at 08:26:06, RonWeasley wrote:

I agree with this.

On the PASS move proposal, I haven't quite followed the discussion to this point, but I would not like to see PASS be a move alternative.

I say "pass move" would be too much of a disturbance to be introduced at this juncture, that is after tens of thousands of games have been played. How many of those games would have taken a radically different direction had the "pass your move" been an option? Nearly all of them most likely.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 24^th, 2008, 11:20am

on 06/24/08 at 02:27:49, aaaa wrote:

I think it does make more sense to have elimination be higher priority than immobilization. Not just for bot developers but also as Karl mentioned in terms of what the game is about. I will make the changes. Thanks for the suggestion aaaa.

Also as Arimaabuff mentioned passing is perhaps not worth considering at this point. Also as Karl mentioned it would complicate the explanation of the rules.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 25^th, 2008, 6:43am

on 06/24/08 at 02:27:49, aaaa wrote:

I just made this change. It still needs to be tested though.

Title: Re: 2008.07.01 Core Rule Changes
Post by aaaa on Jun 25^th, 2008, 3:18pm

This suggests a new type of bot-bashing record: Fastest simultaneous goal, elimination and immobilization against a particular bot (per color).

Title: Re: 2008.07.01 Core Rule Changes
Post by gatsby on Jun 27^th, 2008, 2:44am

I am thrilled with these rule changes. The new rule concerning repetition of position is fairer than the old one, and the win by elimination healthily unifies normal and tournament rules. Thank you, Omar!

The new scoring system is also more practical than the old one, but, on the other hand, I don't like the way it solves ties when both sides have the same number of pieces. Also, given that the objective of a game of arimaa is to take one rabbit to the last row, it is IMHO a bit illogical not to take it into account in the score. All of us know that having the higher number of pieces on the board doesn't assure the victory at all.

I have been thinking a little about it, and I'd like to share with all of you the idea it has occurred to me. Would you, Omar, be so kind as to consider it (or to have it a look, at least)? It is as follows:

If the game hasn't ended within the time assigned to it, the game will be won by the player who has advanced more squares with one of his rabbits than the other player with any of his ones (captured rabbits doesn't count, of course). If the tie persists, the game will be won by the LAST player who has had this kind of advantage in a previous position.

Example: if Gold's most advanced rabbit is in the fifth row (counting from Gold's nearest row), which it has reached on move 70, and Silver's most advanced rabbit is also in the fifth row (counting from Silver's nearest row), which it has reached on move 72, then the scoring system will assign the victory to Gold.

Greetings from León, Spain!

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 27^th, 2008, 2:04pm

on 06/27/08 at 02:44:39, gatsby wrote:

If the game hasn't ended within the time assigned to it, the game will be won by the player who has advanced more squares with one of his rabbits than the other player with any of his ones (captured rabbits doesn't count, of course). If the tie persists, the game will be won by the LAST player who has had this kind of advantage in a previous position.

The score function has almost never come into play, but one of the few cases it was called upon was this game (http://arimaa.com/arimaa/gameroom/replayFlash.cgi?gid=6990&s=b&client=1), in which it chose the wrong answer. Your proposal also picks wrong: the side with a rabbit furthest advanced would have lost eventually if the game had continued.

As I look back at that game, however, the problem is not that the scoring function was bad, it was that the game was halted. The reason to even have a time cutoff is for games that aren't progressing. The only proper situation for imposing a result is if neither player wants to undertake something active.

To put it another way, the game shouldn't hit the time cutoff unless at least one player is doing something wrong. If there were a situation where both players were playing well and nothing was happening, that would be a flaw in the game design, but in that case, no score function could heal the damage.

Therefore, assuming that the design of Arimaa is not flawed, and assuming we make the time cutoff long enough that it is only invoked at the fault of the players, I don't really care if the score picks the player with the better position. It should just be simple and decisive.

Both omar's proposal of who has more pieces and gatsby's proposal of who has the most advanced rabbit are simple and decisive. How to choose? I guess I would fall back on what I said in a previous post: the game is about goal first, capture second, and mobility third. So here is my proposal: when a result is imposed, the winner is whoever has a rabbit furthest advanced, with ties broken by whoever has the most pieces, with further ties broken by whoever has his elephant closest to the center.

The good news is that the score function has never mattered in any human game so far. Let's hope it stays that way!

Title: Re: 2008.07.01 Core Rule Changes
Post by Janzert on Jun 27^th, 2008, 2:15pm

on 06/27/08 at 14:04:10, Fritzlein wrote:

As I look back at that game, however, the problem is not that the scoring function was bad, it was that the game was halted. The reason to even have a time cutoff is for games that aren't progressing. The only proper situation for imposing a result is if neither player wants to undertake something active.

Another reason for time cutoffs is for tournaments that need to get so many rounds or games played within a certain amount of time. While this isn't much of a concern for the internet based games I imagine it will become a much larger one if (once?) live tournaments become popular. This also means that unfortunately the whatever rule is chosen doesn't effect much now but could be much more important in the future.

Quote:

Both omar's proposal of who has more pieces and gatsby's proposal of who has the most advanced rabbit are simple and decisive. How to choose? I guess I would fall back on what I said in a previous post: the game is about goal first, capture second, and mobility third. So here is my proposal: when a result is imposed, the winner is whoever has a rabbit furthest advanced, with ties broken by whoever has the most pieces, with further ties broken by whoever has his elephant closest to the center.

The good news is that the score function has never mattered in any human game so far. Let's hope it stays that way!

Although I agree the game is about goals then captures and so on, I think when stopping a game at an arbitrary point and deciding a winner it is better to count pieces before looking at most advanced rabbit.

Janzert

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 27^th, 2008, 2:21pm

on 06/27/08 at 14:15:00, Janzert wrote:

If the rule ever becomes important, it should be replaced with accelerating time controls. If I remember correctly, the consensus of the previous discussion of this rule was that accelerating time controls were the most satisfactory solution, and the only reason not to have them instead of a cutoff is that they are difficult to implement.

Title: Re: 2008.07.01 Core Rule Changes
Post by aaaa on Jun 27^th, 2008, 2:29pm

Hmmm, no one commented on my proposal to count the number of rabbits before other pieces, which I consider to be a natural extension of the victory condition of the game.
Anyway, here's another, crazier idea: Let the 4-step limited version of the current bot champion (or winner of the challenge qualifier) play out the game on its own.

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 27^th, 2008, 2:47pm

on 06/27/08 at 14:29:47, aaaa wrote:

Hmmm, no one commented on my proposal to count the number of rabbits before other pieces, which I consider to be a natural extension of the victory condition of the game.

Sure, that makes sense. Although the victory condition could be extended in many ways. Is having more rabbits more important than having the furthest advanced rabbit? What about the second-furthest advanced rabbit? It's pretty easy to get a score function just as complicated as the one Omar just replaced. I guess my triple-tiebreaker was complicated too...

One criterion to choose between score functions is to see which works better as the evaluation function for a 1-ply bot. Clauchau showed us that "have the furthest advanced rabbit" works much better than "have the most pieces". Unfortunately for my proposal, "maximize the old score function" works better than either of these.

Quote:

Anyway, here's another, crazier idea: Let the 4-step limited version of the current bot champion (or winner of the challenge qualifier) play out the game on its own.

Yeah, or have the current bot champion evaluate it for 60 seconds and just decide. Using a bot is a procedure that is easily described, and one that will agree with who humans think is winning more often than any formula will. I like it! I believe that at present BombP2 determines whether or not a game that ended on time can be unrated.

Title: Re: 2008.07.01 Core Rule Changes
Post by aaaa on Jun 27^th, 2008, 3:06pm

on 06/27/08 at 14:47:13, Fritzlein wrote:

or have the current bot champion evaluate it for 60 seconds and just decide.

I thought of that too, but it's not necessarily the case that the bot comes with an analysis mode.

Title: Re: 2008.07.01 Core Rule Changes
Post by Janzert on Jun 27^th, 2008, 4:50pm

on 06/27/08 at 14:47:13, Fritzlein wrote:

One criterion to choose between score functions is to see which works better as the evaluation function for a 1-ply bot. Clauchau showed us that "have the furthest advanced rabbit" works much better than "have the most pieces". Unfortunately for my proposal, "maximize the old score function" works better than either of these.

I would tend to think that seeing what works better as a predictor of the eventual winner would be the most important criteria. Maybe weighting towards positions closer to the endgame since presumably the time will run out closer to the endgame than the beginning. :) And now thinking about it in this way I'm not really sure which would come out the best. At least among the simple methods, a good bot should beat any of them.

Janzert

Title: Re: 2008.07.01 Core Rule Changes
Post by mistre on Jun 27^th, 2008, 6:27pm

How about the winner is whoever took the least amount of time when the time runs out? Or was that the solution you were referring to when you mentioned accelerated time controls?

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 27^th, 2008, 8:13pm

on 06/27/08 at 18:27:53, mistre wrote:

How about the winner is whoever took the least amount of time when the time runs out? Or was that the solution you were referring to when you mentioned accelerated time controls?

That's basically equivalent to having the last acceleration be sudden death. I think chess tournaments sometimes do this, for example 2 hours for 40 moves, plus 1 hour for the next 40 moves, plus half an hour sudden death. Game is over in seven hours max. However, because not all reserve time is banked in the Arimaa game room, the "least time" criterion works out a little different.

I prefer a gradual acceleration of, say, 60 seconds per move to 45 seconds to 30 seconds to 15 seconds. That way players have to speed up steadily rather than making a "time gamble" where one player might have two minutes left in sudden death where the other player has twenty. You can say that long-term time management is part of the game, but I'd rather force the players to move steadily faster than have them take chances based on how many moves they think the game might last.

Title: Re: 2008.07.01 Core Rule Changes
Post by Janzert on Jun 27^th, 2008, 9:16pm

I do see a certain draw towards the accelerating time controls, but then you end up with something like the 2008 US Women's Chess Championship (http://www.youtube.com/watch?v=fNQjXHjRkNQ) (Relevant part of the video is 20 seconds to 1 minute if you haven't seen it yet). After which there was a fair amount of controversy and commentary (1 (http://www.chessbase.com/newsdetail.asp?newsid=4700), 2 (http://www.chessbase.com/newsdetail.asp?newsid=4710), 3 (http://www.chessbase.com/newsdetail.asp?newsid=4725)) on it being a disgrace to chess.

Janzert

Title: Re: 2008.07.01 Core Rule Changes
Post by Fritzlein on Jun 28^th, 2008, 9:40am

Yes, this video is an argument against any sudden death time control. If we accelerate to some fastest speed, say 15 seconds per move, to insure that the game lasts for a certain length, say at least 160 moves, and then we have a time cutoff, I might prefer the board position to decide the outcome in some way rather than total time used. If total time used to decide, then an eventual sudden-death time scramble is inevitable.

Chess has a problem that Arimaa does not have, namely games that are drawn on the board. Therefore we can have Armageddon games by getting in enough moves by accelerating the time control. We have never had an over-the-board drawn position. Until we encounter a position that is legitimately drawn, or a game that would naturally last a huge number of moves, the issue of what to do after time cutoff is merely an issue of what to do if some player or players decide to behave oddly.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jun 30^th, 2008, 6:44am

When I was rethinking about the scoring method it seemed to me that no matter what method was picked there would always be some positions for which it would be wrong. Also trying to making the scoring method more accurate in predicting the outcome tends to make it more complex to the point that humans would have a hard time evaluating it in real time. What seemed more important was for the scoring method to encourage players to make real irreversible progress on the board and not just shuffle pieces. Ideally the scoring method should encourage irreversible progress that results in a natural ending to the game and thus the scoring method never needs to be evoked. One problem with all scoring methods is that the player in lead will want to take as long as possible to make the move while the player who is behind will want the moves to be made faster. Only accelerating time controls can fix this.

The only thing in Arimaa which is totally irreversible are captures. Rabbit advancements could be undone by the opponent pushing your rabbit back. Also captures are not as easy to achieve and usually require several moves worth of effort to setup and execute. Thus a player who was behind could not so easily make a move that gives them the lead just before game time runs out.

I like gatsby's proposal that in case of a tie the player who previously had the lead wins. When total captures are used to determine the winner this would require a player to make two captures in one move to jump ahead.

I also though about using a bot to decide the outcome, but it didn't seem that natural. It also requires storing with the game which bot and what bot setting were used to decide the outcome.

Title: Re: 2008.07.01 Core Rule Changes
Post by The_Jeh on Jun 30^th, 2008, 9:44pm

I won a game by elimination (does the "e" mean elimination or extermination?) using the old client. However, the box that popped up to announce the end of the game was blank. Could this be fixed? Those new to the game might become confused.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jul 2^nd, 2008, 8:46pm

Decided to use the word "elimination" instead of "extermination". So e = elimination. If you notice the word "extermination" being used anywhere, please let me know via the Contact page.

I think you were using the old client (Flash V1). I am not going to make any changes to that client and hope to phase it out soon (by the end of July). I suggest switching to the Flash V2 client. If you encounter any problems with it, please let me know via the Contact page. Thanks.

Title: Re: 2008.07.01 Core Rule Changes
Post by aaaa on Jul 3^rd, 2008, 2:56am

This page (http://arimaa.com/arimaa/gameroom/reasonCodes.html) is no longer reachable by clicking on the "Reason" link on a "Recent Games" page, at least not for me.
BTW, shouldn't the 'p' reason also be listed as being no longer in use, like the 'n' one is?

Title: Re: 2008.07.01 Core Rule Changes
Post by mistre on Jul 3^rd, 2008, 5:35am

on 07/02/08 at 20:46:40, omar wrote:

I think you were using the old client (Flash V1). I am not going to make any changes to that client and hope to phase it out soon (by the end of July). I suggest switching to the Flash V2 client. If you encounter any problems with it, please let me know via the Contact page. Thanks.

Omar, Please do not phase out Flash V1! I am still using it as I still don't like the new client (after recently trying it again). In my opinion, the graphics are better, the sound is better and I like the layout better. I would think that there are other supporters of V1 out there - please speak up as well.

Is there any particular reason that V1 has to go away?

Title: Re: 2008.07.01 Core Rule Changes
Post by Soter on Jul 3^rd, 2008, 10:49am

Quote:

Another supporter of V1 speaks up and agrees with mistre. :)

Title: Re: 2008.07.01 Core Rule Changes
Post by Arimabuff on Jul 3^rd, 2008, 10:52am

on 07/03/08 at 05:35:30, mistre wrote:

I don't like the V2 either for similar reasons and can't bring myself to using it. If V1 goes away, I will be using it until the last minute. Unless there is an imperative and I wonder what that might be I think it should stay as an option for people like the two of us.

Make that the THREE OF US I didn't notice soter at first sorry.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jul 9^th, 2008, 9:26am

on 07/03/08 at 02:56:40, aaaa wrote:

Thanks for noting this; I've fixed it.

Title: Re: 2008.07.01 Core Rule Changes
Post by omar on Jul 9^th, 2008, 9:40am

on 07/03/08 at 05:35:30, mistre wrote:

OK I will still keep it available from the Settings -> Game Client page and only change the default to be the V2 client. But I won't be making any changes to it since I don't want to support multiple Flash versions of the client. Things like graphics, sound and layout can be changed in the new client if more people prefer that of the old client.