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]
H. G. Muller wrote on Sun, Jul 14 09:34 PM UTC in reply to Fergus Duniho from 07:47 PM:

Well, move sets are 1-on-1 associated with piece types. So if a square must somehow affect the move, it must affect the type. I suppose that it could be called a property of a square how it would change one piece type into another, and such a property can be assigned by the 'morph' parameters for each piece type, which for each (type, square) combination defines the type that would result from a piece arriving there.

The way how piece types (repeatedly) change into each other defines a network, and this network can consist of a number of disjoint sub-nets. Such a sub-net could then be considered a 'meta-type'. If the sub-net has the property that every closed path that brings you back to the same square results in the same type, the meta-type could be considered the same piece moving differently depending on where it stands. In other cases it would be considered a promotion. E.g. a Pawn can reach last rank, promote to Queen, and then return to its starting square as Queen.

A trivial case for a meta-type always manifesting itself as the same type on a given square occurs when all types that belong to the meta-type morph to the same type on arriving on that square. This is the case we have here. Currently it would have to be defined in the I.D. by explicitly defining all the types, one for every possible move set, and then for each specify the same morph parameter to indicate how they change into each other. This is a bit repetitive, and you might easily run out of letters to designate the types.

Perhaps it should be possible to define meta-types directly, by allowing a piece definition (which now consists of name, ID, image, move and starting squares) to contain not one, but a list of moves. For each move a type would then be created, but all these types would have the same name, ID and image. Such a meta-type definition could then be followed by a morph parameter to indicate which move from the list should be used on which square. E.g. by designating the moves in the list by a single letter a, b, c, ..., and using these letters in a FEN-like string for associating squares with the moves of the preceding meta-type definition.