Check out Grant Acedrex, our featured variant for April, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

LatestLater Reverse Order Earlier
Metamachy. Large game with a variety of regular fairy pieces.[All Comments] [Add Comment or Rating]
🕸Fergus Duniho wrote on Thu, Feb 7, 2019 11:15 PM UTC:

Ideally, I want to treat Metamachy as a game in which White has the first move of the first turn but Black has a special setup move before White moves. The trouble is that the more complicated Game Courier has gotten, the more difficult it has become to change how it behaves. I have some ideas for what to do, but I also worry about breaking things to get it done. It also takes a lot of inspection of the code to figure out how it works and what can be changed. Some of my ideas might also be useful for supporting multi-player games, but that's another thing I have not added yet because of the difficulty in doing so.


📝H. G. Muller wrote on Wed, Feb 6, 2019 09:37 AM UTC:

Well, I guess black logically is the first player in Metamachy. Don't you have the same problem in Shogi?


🕸Fergus Duniho wrote on Tue, Feb 5, 2019 11:20 PM UTC:

I have made good progress toward making a rule-enforcing preset for Metamachy. The last thing to do is to enable Black to place pieces before White moves. Game Courier is not currently set up to allow anyone to do anything before the first player moves. One way to handle this would be to give the first move to Black, but this would involve inverting the board, switching the sections coding for each side, and listing White as the second player in the movelist. I would rather avoid all that, but that means working out a way to allow the second player a pre-game move.


Erik Lerouge wrote on Thu, Nov 8, 2018 07:26 PM UTC:

I made a GC preset for Metamachy here.


📝H. G. Muller wrote on Thu, Aug 10, 2017 12:44 PM UTC:

Oh, it seems I broke something when making it possible to have multiple diagrams on one page: all collapsable legends now get different HTML IDs, so the test whether the legend table is open or closed, which decides whether you automatically get the default piece, now looks for a legend with the wrong name, and as a result considers it closed.

[Edit] OK, I fixed the JavaScript, and now you will have again promotion choice. (In the legend table, when it is open. When it is collapsed, you get the default piece, which is Queen here.) Don't forget to hold Shift down when you reload the Metamachy article, to also force loading the new .js file instead of using the cached one.


sirius628 wrote on Wed, Aug 9, 2017 11:09 PM UTC:

There's a problem here. The Pawns and Princes promote only to Queen, and never to Lion or Eagle.


📝H. G. Muller wrote on Wed, Aug 9, 2017 07:45 PM UTC:

Ah, but this is new information. You can also not make the jump when in check. I did not get that from the description on Jean-Louis' website.

Btw, it seems that this in-check business has been a seriously disputed issue at one time in the history of orthodox Chess, whether you could be in check by a pinned piece, or whether you could step your King next to an enemy King when you were protected (so that the opponent King could not legally move to the square your King was on to capture the latter). In Tai Shogi there is a similar issue, because there is a rule that says an Emperor (which is a universal leaper) cannot capture a protected piece, and it is not clear whether a piece is protected by the opponent Emperor (as he is also subject to this rule, and might thus not be able to recapture your Emperor if you had a second attacker to the square).

But I understand that this 'attacked' test in Zillions would never say that a piece is attacked by a piece of the same player.


🕸Fergus Duniho wrote on Wed, Aug 9, 2017 03:53 PM UTC:

Here's how the function works. It starts with the piece on the space it was already on before moving. It then verifies two things, that the piece hasn't moved, and that it is not attacked. The first checks an attribute of the piece, and the second checks whether an enemy piece could reach the space using its powers of movement. If these are both true, it continues to process the move. The $1 is a variable standing in for the first argument passed to the function. This will be a direction, and it will move in that direction to a new space. It then verifies that this space is not attacked. If this is true, it then proceeds in the direction provided by the second argument, $2. The one thing it verifies here is that the space is empty. If it is, it continues with the rest of the function. The next line sets the piece attribute "never-moved?" to false, which will stop the piece from making a second move of this type. The line after this is commented out. It would have set an attribute that appears to be redundant and unused. With the last line, the add command makes this an official legal move, understood in terms of the piece's powers of movement, but not in terms of whether the move would create an illegal position.

Consider the game of Chess. A King cannot legally move to a space the other King could otherwise move to, because then it would be moving into check. This implies that each King can attack a space it cannot actually legally move to. And this is what attacked means in Zillions-of-Games. It identifies a space that the King would be in check on if it moved there.


📝H. G. Muller wrote on Wed, Aug 9, 2017 02:09 PM UTC:

Well, I don't understand Zillions coding. But do you mean 'legally' as 'also not leaving the player in check'? I.e. would player A be allowed to move his virgin King from f1 to d1 if e1 was attacked by a Rook of player B that was pinned on the King of player B?

For orthodox Chess being in check is defined in terms of pseudo-legal moves, and 'not passing through check' would also forbid castling when a pinned piece attacks the square through which the King passes, and thus does not have a legal move to that square.

Capturing your own pieces is not even pseudo-legal, however, so I guess it is would never be a problem to jump over an enemy piece.


🕸Fergus Duniho wrote on Wed, Aug 9, 2017 01:34 PM UTC:

The code for the King's skip move looks like this:

  (define skip
( 
(verify never-moved?) 
(verify not-attacked?)
	   $1 
	(verify not-attacked?)
	   $2
		(verify empty?)
	        (set-attribute never-moved? false)
	   ;     (set-attribute never-skipped? false)
		 add
	 ))

The only condition on the first step of this move is that the space is not attacked. A space is considered attacked in Zillions-of-Games only when an enemy piece could legally move there.


📝H. G. Muller wrote on Wed, Aug 9, 2017 12:48 PM UTC:

OK, thank you for clearing this up. I will make the article conform to the Zillions implementation.

Perhaps you could try the following as well? (I don't have Zillions):

Is the not-passing-through-check rule also enforced when the square jumped over is occupied? And does it depend on the player to which the occupying piece belongs? Logically, if the King tries to move f1-d1, and e1 is attacked (by a Knight, say), it should be forbidden when there is a friendly piece on e1, but allowed if there is an enemy, as the Knight cannot capture the King on e1 when there also is a piece of his own on e1. (At least, I think so; it is not very logical in the first place that the King could be on a square already occupied by another piece, to be checked there...)


🕸Fergus Duniho wrote on Tue, Aug 8, 2017 11:20 PM UTC:

Thanks for putting this up. You didn't mention that the Prince moves as a non-royal King, one space in any direction.

I played both sides with Zillions-of-Games to get the ambiguities in the rules clarified.

When I attacked a space vertically in front of a King with a Knight, it could not leap as a Knight to the space the Knight was actually attacking, but it could still move as a Knight to the other space. So it looks like the overpassed square applies only to orthogonal and diagonal moves, not to hippogonal moves. But looking at the code, I see that the King is given two paths for each hippogonal move. So I setup a position where both the Mao path and the Moa path of the King to a particular space are attacked, but the space itself is not attacked, and the King could not move to that space. So the rule is that a King may make a Knight leap if there is at least one two-step path to the space with an unattacked space, and this path may be like the move of a Mao (Chinese Chess Knight) or a Moa, which goes diagonally, then orthogonally outward.

Also, while a Camel is attacking a space near the White King, it's within a Knight's leap away from the King, nothing is attacking any space the King would have to pass over, and nothing is protecting the Camel, yet the King cannot capture it. So it looks like the King's two-space leap must be non-capturing. Looking at the code, this is confirmed. The King may make its skip move, as it is called in the code, only to an empty space.

Finally, I setup a stalemate position, and Zillions reported that it was a draw. So it looks like stalemate is a draw.


12 comments displayed

LatestLater Reverse Order Earlier

Permalink to the exact comments currently displayed.