Check out Janggi (Korean Chess), our featured variant for December, 2024.


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

Single Comment

Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]
🕸💡📝Fergus Duniho wrote on Mon, Jul 15 05:01 PM UTC in reply to H. G. Muller from 05:30 AM:

The Xiangqi Pawn can both be considered a single type, with a move dependent on which side of the River it stands, or a piece that promotes to a new type when crossing the River. These are fully equivalent descriptions, because the network of (type, square) transitions trivially satisfiies the condition that no closed loop alters the type, as the move confines closed loops to a rank. I would't say any of those descriptions is not in strict alignment with the rules.

They are functionally equivalent, but they are not conceptually equivalent. Technically, the Pawn in Xiangqi never promotes, because when it crosses the river, its name remains the same, and it is not replaced with another piece or flipped over like in Shogi. But in this case, one could conceive of it as promoting and play the game the same way as other people, because an irreversible one-time promotion adds no further complexity to the game. But with Storm the Ivory Tower, understanding the game as involving promotions would shift too much of the complexity of the game onto the pieces, and while it might provide a way to program the game solely in terms of piece definitions, these piece definitions would not be as easy for players to understand, and they might have to be rewritten for different terrains.

The movement options available to a piece in this game are normally understood as a function that makes use of data about the space it is on. In Game Courier, I have represented this data as an 8-bit number for each space. Each bit represents one of the directions away from the space, and to check whether a piece can move in a particular direction, it does a bitand of the value for that direction with the space's 8-bit number. Doing it this way allows me to completely separate board data and piece definitions, which makes the piece definitions easier to understand and doesn't require them to be rewritten if the terrain changes. Just to illustrate the principle, here is how the Numskull (identified here as R for Rook) is defined:

def R checkride #0 #1 1 1 or checkride #0 #1 0 1 and fn legaldir #0 #1;

If xBetza defined these pieces in an equivalent manner, all it would need is a new modifier, such as a for any available direction indicated by an arrow. This would be similar to modifiers like v, s, f, and b, except the actual directions would depend upon board data instead of being fixed. So, to give the simplest example, the Numskull could be defined as aQ, and in Smess at least, the Ninny and Brain could be defined as aK. This would be in accordance with how the rules are conceptually understood by humans and actually be a useful mnemonic for quickly identifying how a piece can move.