I use Tetris terminologies to understand certain endgame techniques. For example, the L-shaped Tetris piece tends to be a useful arrangement of squares for your pieces to control when surrounding the enemy king to prevent it from escaping to the center in an endgame. A queen alone is able to control the 4 squares that make up the L, which is why you don't need your king for the first phase of King Queen vs King.
An endgame that would simulate the first phase of King Queen vs King could be "L-Tetris Piece vs King", where the L cannot be captured, and stalemate is counted as a win. I think that every other Tetris piece would be a draw.
How hard would it be to implement Tetris pieces into chess endgame tablebases?
Re: How hard would it be to implement Tetris pieces into chess endgame tablebases?
Try defining the rules for your new piece. Then play with it and you should be able to see if you want a tablebase.
Fantasy pieces are generally not hard to implement a tablebase for.
If you have a queen which can lay eggs, the number of eggs need to be limited in order for a tablebase to be practical.
Fantasy pieces are generally not hard to implement a tablebase for.
If you have a queen which can lay eggs, the number of eggs need to be limited in order for a tablebase to be practical.
Re: How hard would it be to implement Tetris pieces into chess endgame tablebases?
Chess Rules for Tetris Pieces:
Occupies 4 squares simultaneously
Cannot be captured, and other pieces cannot move to any of the 4 squares occupied
Moves like the king (all 4 of the piece)
The question is whether a Tetris piece would have to be treated as 4 pieces, or if it could be treated as one piece.
Occupies 4 squares simultaneously
Cannot be captured, and other pieces cannot move to any of the 4 squares occupied
Moves like the king (all 4 of the piece)
The question is whether a Tetris piece would have to be treated as 4 pieces, or if it could be treated as one piece.
Re: How hard would it be to implement Tetris pieces into chess endgame tablebases?
Treating it as one piece seems reasonalble.
Would it have to stay on the board in its entirety?
Would it be allowed to capture even if no capture of itself was allowed?
Would it be allowed to rotate, and if so, when and around what axis?
Have you tried playing with it on a chess board to see what can be done and figure out fun rules for it?
Would it have to stay on the board in its entirety?
Would it be allowed to capture even if no capture of itself was allowed?
Would it be allowed to rotate, and if so, when and around what axis?
Have you tried playing with it on a chess board to see what can be done and figure out fun rules for it?
Re: How hard would it be to implement Tetris pieces into chess endgame tablebases?
It seems like the L-piece is unable to force stalemate, unless it is allowed to partially move off the board.
It should be allowed to capture pieces that occupy its squares, this makes more sense than restricting pieces from moving onto its squares.
It's hard to define concrete rotation rules, but I suppose that the rules should be defined by the maneuvers that create tablebase wins.
Example: If the L-piece occupies a6-b6-c6-c7, then its rotating move should be to a8-b8-b7-b6, because that is the maneuver that allows the L to force an enemy king from a7 to a corner, so that should be how its rotation is defined.
Example: If the I-piece occupies d5-d6-d7-d8, enemy king is on c8, and I's king is on b6, then the enemy king moves to b8, the I should be able to rotate to occupy d8-c8-b8-a8 and then that is checkmate, similarly to King Rook vs King
It should be allowed to capture pieces that occupy its squares, this makes more sense than restricting pieces from moving onto its squares.
It's hard to define concrete rotation rules, but I suppose that the rules should be defined by the maneuvers that create tablebase wins.
Example: If the L-piece occupies a6-b6-c6-c7, then its rotating move should be to a8-b8-b7-b6, because that is the maneuver that allows the L to force an enemy king from a7 to a corner, so that should be how its rotation is defined.
Example: If the I-piece occupies d5-d6-d7-d8, enemy king is on c8, and I's king is on b6, then the enemy king moves to b8, the I should be able to rotate to occupy d8-c8-b8-a8 and then that is checkmate, similarly to King Rook vs King
-
h.g.muller
- Posts: 223
- Joined: Mon Feb 19, 2007 8:24 am
- Sign-up code: 0
- Location: Amsterdam
- Contact:
Re: How hard would it be to implement Tetris pieces into chess endgame tablebases?
In the abstraction in which an EGT is defined, all that exists is a set of game states that can be enumerated by an index, and transformations between those states (the move rules) for each of the two players. And two sub-sets of the game states where one or the other player has won. The latter can be all game states where no moves are available, but it can also be a sub-set of that (as in Chess, where stalemate is not a win), or there can be 'artificial' game terminations, where there would be moves (such as King baring in Shatranj, or reaching a certain area with a certain piece as in Racing Kings or King of the Hill).
The 'L' vs King game perfectly satisfies these conditions; the game state is determined by two sets of square coordinates (and, as usual, who is on move). So it is basically a 2-men EGT, where one of the men does not even have access to all (say 64) squares, but has only 6x7 = 42 possible locations (if it must remain entirely on the board). Or, if the L is allowed is allowed to rotate, 4 times as many, as its orientation also becomes part of the game state. Or yet another factor 2 more if it is also allowed to flip over to a mirro image.
BTW, I have made some web applets for EGT generation of elementary end-games with fairy pieces (but only of the 'point type'!) on boards of various shapes and sizes which might interest you: https://www.chessvariants.com/page/MSch ... let-3-vs-1 . That version allows you to define the move pattern of the pieces yourself, and can handle limited-range riders and leapers (which are just riders with range 1). I also have a version that can handle certain bent riders or Xiangqi-Cannon-like hoppers, but this is limited to a number of pre-programmed piece types, ( http://hgm.nubati.net/applets/ ), as I have not designed a good interface yet to define such move patterns. They only work with an orthodox King, though.
The applets are not very fast, (It is all JavaScript, and uses a byte-based algorithm), especially on larger boards.
The 'L' vs King game perfectly satisfies these conditions; the game state is determined by two sets of square coordinates (and, as usual, who is on move). So it is basically a 2-men EGT, where one of the men does not even have access to all (say 64) squares, but has only 6x7 = 42 possible locations (if it must remain entirely on the board). Or, if the L is allowed is allowed to rotate, 4 times as many, as its orientation also becomes part of the game state. Or yet another factor 2 more if it is also allowed to flip over to a mirro image.
BTW, I have made some web applets for EGT generation of elementary end-games with fairy pieces (but only of the 'point type'!) on boards of various shapes and sizes which might interest you: https://www.chessvariants.com/page/MSch ... let-3-vs-1 . That version allows you to define the move pattern of the pieces yourself, and can handle limited-range riders and leapers (which are just riders with range 1). I also have a version that can handle certain bent riders or Xiangqi-Cannon-like hoppers, but this is limited to a number of pre-programmed piece types, ( http://hgm.nubati.net/applets/ ), as I have not designed a good interface yet to define such move patterns. They only work with an orthodox King, though.
The applets are not very fast, (It is all JavaScript, and uses a byte-based algorithm), especially on larger boards.
Re: How hard would it be to implement Tetris pieces into chess endgame tablebases?
Actually, the rotations and mirrorings would be cancelled out exactly by being able to rotate and mirror the board, so no extra state is required!Or, if the L is allowed is allowed to rotate, 4 times as many, as its orientation also becomes part of the game state. Or yet another factor 2 more if it is also allowed to flip over to a mirro image.