Comments/Ratings for a Single Item

I must admit that it appears to work, but it should count as heavy abuse of XBetza notation. (Which is used to define all moves with detours to measure the location of the piece.) But it is true that the more conventional solution, of morphing th epiece to a type that has the proper moves on the square where it lands, is also no joy, because of the large variety of squares, and the huge number of types this would require. There must be more convenient methods of handling variants of this type...

Is it possible to define properties for spaces, then to define movement in terms of the properties of the space it moves from?

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.

I have never used morphing, though I assume it involves changing the type of a piece. What you are suggesting strikes me as no less of a kludge than what has already been done, as each solution handles movement in a way that is not strictly in alignment with the rules. If this were done strictly by the rules, the Numskull would have the same definition in this game as in Smess, and the identity of a piece would remain the same everywhere on the board. If there were a way to define space properties, it could be done strictly by the rules. One way to simulate board properties might be to have an invisible layer with stationary pieces that affect the directions the mobile pieces on the visible board can move. Another alternative would be to surround each space with eight other spaces for each possible direction, put an invisible stationary piece in any direction movement is not allowed, and require each move to go over its closest neighbor in whichever direction it moves. While piece movement would not be in strict conformity with the rules, this would at least separate the piece definition from the particulars of the terrain and avoid the expediency of changing the type of a piece.

Well, what's in a name? Whether you call the entire set of possible piece incarnations the piece type, and the sub-set of those incarnations on squares with identical 'properties' a sub-type, or call them meta-type and type, respectively, as I did below, doesn't change what they are and how they behave. We could also have called them macro-types and micro-types, which is pehaps even a better terminology. Normally every macro-type consists of just a single micro-type, so we don't have to make the distinction, and call them both 'the type'.

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.

I admit that having to define a huge set of micro-types with the same image in a Diagram definition is cumbersome and looks kludgy, leading to an ugly and bulky piece table. This is why I suggested to make it possible to define a macro-type in a single piece line, using a list of move descriptors (e.g. comma-separated) rather than a single one. But one would then still have to specify which move applies where (i.e. the micro-type taken on by the macro-type on each square). If they all use the same piece ID this cannot be done through a (board-size) array of piece IDs, as the currently implemented morph parameter does. But this can be solved by introducing a new parameter microTypes, which refers to the moves in the macro-types move list, e.g. through single-letter codes a-z.

The same shorthand notation could be used for the value of this parameter as is now used for morph: incomplete ranks could be completed by repetitions of the given part, and a special symbol for 'same as previous rank' or even as previous two ranks could be defined, while entirely missing ranks could default to the first move in the macro-type's list. That would reduce the definition of the Xiangqi Pawn macro-type to a move list fW,fsW and a following microTypes=b/b/b/b/b for the furthest 5 ranks entirely filled with b = fsW.

For a board as irregular as Storm the Ivory Tower there would probably be no shorthand, and all 90 squares would have to be specified. All macro-types are likely to require the same microTypes array (if you properly order their move lists), though. So it might be useful to also have a shorthand symbol for 'same value as for previous piece'.

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.

True, a special 'inherit directions from square' modifier (say '?' as 'a' is already taken) would allow a very elegant move description in Smess-like games. But that is really a very specific case. In Elk Chess the Elk moves as a Rook or as a Knight, depending on the color of the square it is on, and the square property would have to encode more than just a direction. A Querquisite moves as the piece that started in the rank it is in, so it can move like many different pieces. Gerd Degens has recently submitted many variants that have location-dependent moving: Avatar, (where there is only one type of piece next to the royal King, which can move like any orthodox Chess piece in a pattern that is scattered over the board), Bull's Eye (where pieces in the 4 central squares move as Amazon). He also had a variant (I forgot the name) where on some squares pieces keep the move of the square they came from. This is an awful lot like promotion, as on the same square a piece could now have different moves. So the move the pieces have on a square can no longer be a square property.

In Kyoto Shogi the piece type toggles on every move, with as a result that you often reach the same square in either of the two forms, or return to the same square flipped. So the move depends on history rather than on a square property. But the move change does not have the permanence we associate with promotion. A mapping (micro-type, square) -> new micro-type can still perfectly describe all the mentioned behaviors. In micro-Shogi the pieces only flip when they capture, so there a mapping (mover micro-type, destination square, occupant thereoff) -> new micro-type is needed. But that is a very poweful way of describing things. For a given square that mapping of (mover micro-type, destination occupant) -> new micro-type could be considered a (rather complex) 'property' of that square.

I don't think that 'conceptually' really means much. As far as I am concerned game rules are an abstract mathematical concept: a set of game states acting as nodes of a directed graph that indicate the legal transistions between one game state and another. Where the game states imply the player who is going to decide which of the legal transitions out of the state will be taken, and game states without any exits are labeled with a game result. Any verbal description that unambiguously defines this graph is as good as any other, and concepts like turn, piece, move, cell, type are not more than personal preferences of the person or machine learning the game, to help him remember and apply the rules. Often different concepts are just rewording the same thing. One could for instance call micro-type also 'current move set of the piece', and it might sound much less abstract to some.

I don't think that 'conceptually' really means much.

It refers to how human beings normally conceive of the rules of a game, particularly for the purpose of playing it themselves with physical equipment. What you have proposed could go on behind the scenes in a computer program, but it would not reflect how people would actually play the game with a physical set. Instead of thinking that a piece changed its type with each move to a square with a different arrangement of arrows, human players with a physical set would normally think of each piece as a singular thing capable of moving in the directions indicated by the arrows on its square.

As far as I am concerned game rules are an abstract mathematical concept: a set of game states acting as nodes of a directed graph that indicate the legal transistions between one game state and another.

I can understand a programmer thinking of game rules in those terms, but most people are not programmers and will not understand game rules in that way. Furthermore, keeping the code close to the conceptual understanding of the rules can make it easier for other programmers to understand. Consider the code in the interactive diagram for this game. It works as a way of allowing a computer program to play the game, but it's about as obfuscated as code can get, and looking at this code is not going to give anyone much idea about how to play. But my own code for Game Courier would give someone who examined it a much better idea of how the game is played.

Any verbal description that unambiguously defines this graph is as good as any other, and concepts like turn, piece, move, cell, type are not more than personal preferences of the person or machine learning the game, to help him remember and apply the rules.

Machines do not have to work with concepts, and they do not have personal preferences. If it works, a machine can be programmed to play a game in a manner very different from how humans would normally conceive of the rules. This might be due to the limitations of a programming language or for the sake of efficiency. But when the language allows it, and it can be done at no cost to efficiency, it is best to reflect a normal human understanding of the game in the code. Such an understanding will normally be common to many people thanks to being grounded in the common experience of playing with physical pieces on physical boards. This makes it normal for people to distinguish between the pieces and the terrain, whereas a computer program, not thinking about the game conceptually at all, could easily merge the pieces and terrain together in a way that humans would not normally do.

Haru's Diagram doesn't implement this game by change of piece type. It gives the pieces the same move set everywhere. But with moves that are making such complex detours that the unwanted moves will not be possible because they stray off board at the wrong step along their trajectory. This makes the move descriptions in the piece table totally uninterpretable for humans, and the I.D. thus a failure as an aid for explaning the rules. One can say that the program here uses the concept of pieces with a fixed set of very complex detour moves. For this game this seems a very cumbersome way to think about it, and it is hard to imagine that a human would be able to understand it, let alone prefer it.

But that is not the case for all games that can have different conceptual interpretations; for Xiangqi it makes very little difference in conceptual complexity whether you consider the Pawn to have a location-dependent move set, or that it promotes to another type on crossing the River. It probably depends on the player's background; Chess players are used to promoting Pawns, Smess players will be used to location dependence. Shogi players will be used to the concept of pieces having an 'internal state', and are more likely to see even promotion as merely a different micro-type of the same piece, which is the physical tile that can get flipped.

I only entered this dscussion to investigate whether it wold be possible to base an I.D. on a concept that is more useful for humans than the detour moves, so that it could not only play by the rules, but actualy present those in a helpful way. At least the concept of type change on arrival on each square would cause a more intellegible presentation of the moves (which would become the usual leaps and rides, rather than detour trajectories that stray over the board edge). The disadvantage in this case would be that it involves so many different types.

I think you are mainly turned off on this conceptual interpretation of the rules by that I happened to call these 'types'. But it is really not different from what you describe, that the same piece acquires a different set of moves when it lands on a square. The only difference is that what I called micro-types you call move set. But that is not a conceptual difference, it is just different terminology. Smess (as well as Xiangqi, Elk Chess, Avatar and Bull'sEye) happens to be a game where the current move set of a piece is completely determined by the square it last landed on. Chess promotions do not have that, and we tend to think of the pawn becoming of another type. (Even though in over-the-board Bughouse rules it retains the physical shape of a pawn, and players just have to remember how it moves.) In Shogi it is most clear that the same piece can have two different micro-types/move sets.

The I.D. currently only understands piece types as move sets/micro-types, and lists every micro-type as a different entry in the piece table, with its own fixed move set. For a Smess implementation using the micro-type concept that would give a very lengthy table. (But with simple moves.) It gives little indication which of these micro-types are just different move sets for the same macro-type. So I think it would already be an improvement if it would represent the macro-types as single entries in the table, and allow those to be defined as a macro-type (with multiple move sets) in the Diagram definition. E.g. for Elk Chess we could define

elk:E:R,N:pegasus:a1,h1
microTypes=ab/ba/"/"/"

(where ab expands to abababab to fill the rank, and the double quotes repeat the previous two ranks). That is simple enough, but the problem with Smess is that you still would need a quite long list to describe how, say, a Numskull could move on all the different squares. The number of move sets could be reduced by realizing that many are merely different orientations of others, but that would be hard to exploit, as you still would have to specify somewhere what orientation applies where. And it is very specific to Smess, where the location affects only the allowed directions of the move. So it would be something you would do in a dedicated Smess (or StIT) program, but not be generally useful enough to make it worth implementing in general-purpose chess-variant software.

Haru's Diagram doesn't implement this game by change of piece type.

I know that already. The alternative you were proposing is what does that.

At least the concept of type change on arrival on each square would cause a more intellegible presentation of the moves (which would become the usual leaps and rides, rather than detour trajectories that stray over the board edge).

That is true. It is much less obfuscated than using a long string of characters for each piece.

The disadvantage in this case would be that it involves so many different types.

I think you are mainly turned off on this conceptual interpretation of the rules by that I happened to call these 'types'. But it is really not different from what you describe, that the same piece acquires a different set of moves when it lands on a square.

Both would work, but the code for each would be very different. For what you are suggesting, you would have to multiply the piece definitions and implement a complex mechanism for changing from one piece type to another. Whereas my Game Courier code has a single definition for each piece, and it simply checks whether movement in a particular direction is allowed from a space before evaluating the rest of the function for how a piece moves.

but the problem with Smess is that you still would need a quite long list to describe how, say, a Numskull could move on all the different squares.

This underscores my original point. You were criticizing the way it has been programmed here as "heavy abuse of XBetza notation." In response to this, I pointed out that both this solution and the one you were proposing in its place were both kludges. While your proposal would be easier to read and use shorter XBetza codes, its kludgy approach to the game would still expand the required code, and it would not really be much of an improvement over what we already have. It's not that there is a problem with Smess. It is that the XBetza code approach to coding games focuses on describing the powers of pieces while neglecting other details that could be significant in a game, such as space attributes. While this one-sided approach works for many popular Chess variants, it will not work for a game like Smess without employing a kludge that somehow shifts information about the board into the piece definitions. Given this, I can accept a kludgy solution, but I'm not inclined to think that one kludgy solution is inherently superior to the other.

The issue is that Smess is really a game with very complex rules (which only becomes a problem if you want to express those in a simple way). The way you programmed it also requires an array of 90 8-bit numbers describing the square properties. For humans these properties are given through a picture of the board (so they won't even have to memorize those), and as we know a picture paints a thousand words. Computer programs cannot read pictures, though, so there we have to supply the thousand words...

Your solution can be so convenient, because it is a dedicated program for Smess, and thus can exploit some properties that are peculiar to Smess. Namely that the piece location only affects the directions you can move in. That would not hold for, say, Avatar, where the range and the move step are determined by the location, rather than the direction. Of course you could make a dedicated solution there too, where the square properties specify whether the move is N, K, R, B or Q.

In general what one would have to supply is a move set for every square, and that for every piece type, as not in every variant we will be so lucky that Numskulls and Ninnies on the same square must also move in the same directions. Specifying an array of 90 'direction sets' will be hardly less effort than giving 90 full Betza specifications of the move sets; exploiting that only the direction set is determined by the location allows you to omit the atom from the Betza descriptor, but that is just a single letter, while specifying the direction set will usually require several letters.

If one includes the specification of the board properties your GC solution is not so convenient at all, because each of the 90 properties requires a multi-character definition, hardly shorter than a full Betza move specification. For humans this complexity is hidden by painting this information in graphical form on the board.

It would be easy enough to allow specification of a location-dependent move in the I.D. by supplying a comma-and-slash-separated list of Betza move descriptors in a FEN-like organization, one move descriptor for every cell of the board. One could even use the short-hands discussed earlier, so the move of the Elk could be written as R,N/N,R/"/"/" instead of supplying moves for all 64 squares, but for Smess that would offer no relieve.

Space attributes are supported in the I.D. through the morph parameters that can be defined for each piece. These can specify all properties a piece type can have in a square-dependent manner. But it specifies these properties by a single letter, namely the piece ID, referring to a type-definition line that assigned this ID. This is in general more efficient, because usually many board squares would have the same properties, and repeating the full description of those properties for all of those would make the Diagram definition needlessly verbose.

One might argue that the Diagram's type definitions also specify image and name, and that these should remain the same on all squares, and thus are now needlessly repeated. But this is debatable. E.g. in Elk Chess you could specify piece names in the two required Elk types (with N and R move, respectively) as 'Elk (on dark)' and 'Elk (on light)'. This would be of significant benefit to the user, as he can now consciously summon move diagrams for either case. Having only a single entry for the Elk would raise the problem which move Diagram you would have to show, and would not make the user aware that the Elk would move completely differently elsewhere. And I definitely see some benefit to have a piece table with the Smess Diagram that would have a number of Ninnies, called 'Ninny (on e1,e4,e5,e8)', 'Ninny (on c4,c5,g4,g5)' etc., so he could summon all possible move diagrams for a Ninny. The only disadvantage I see is that the existing morph parameter could only specify which Ninny version is needed on a given square if all these versions had different piece ID, which then reflects on game notation.

[Edit] The latter can be solved by introduction of a new parameter localVersion, which does for the preceding group of piece types with the same ID what morph does for the single preceding type. Except that the type you would change to on each square would not be specified by the piece ID (which would be the same for each type in the group), but by letters a-z implicitly assigned to contiguous types with the same ID in table order. That would only allow changes to types within the group. Which is exactly what you need to implement location-dependent moving; in fact the localVersion parameter can be considered the definition of the square properties. If a promotion to a type outside the group is required, a normal morph parameter (indicating the types by piece ID) can still follow, overruling the type change specified in localVersion for all members of the group, while the localVersion of the group to which the piece changes would determine what (micro-)type with that ID we should change to.

In general what one would have to supply is a move set for every square, and that for every piece type, as not in every variant we will be so lucky that Numskulls and Ninnies on the same square must also move in the same directions.

This is along the same lines as an idea I had when I woke up during the night. My idea is that you could incorporate some kind of select-case structure into a move definition that allows you to use different Betza codes for the piece on different spaces. Using the Numskull as an example, it might start out something like this:

a1: i1: a10: i10: e1: e10: b3: h3: c4: g4: c7: g7: b8: h8: a2: i2: a9: i9: R; 
b1: h1: b10: h10: BvR;
c1: g1: c10: g10: BsR;
d1: d8: fRrRfrB;

For the sake of a game like Xiangqi, you could allow the use of wild cards in designating coordinates. So a Pawn definition might look like this:

?[1-5]: fW; *: fWsW;

Here the * functions like default in a select-case statement by coming at the end.

For the specification of a number of squares (e.g. the starting squares of the pawns) I support a shorthand I.D. where you only have to specify the lower left and upper right corner of a rectangular board area, separated by a dash. That doesn't help much in Smess, but for Xiangqi a0-i4 would give you the entire area below the River, and d0-f2 the white Palace.

Still, having to fully write down the list of coordinates for nearly all board squares is probably more cumbersome than using a FEN-like notation for the entire board. That would require the property of the square to be encoded by a single character, though. But that character could encode an index in a table of the properties. Like

a: R; b: BvR; c: BsR; d: fRrRfrB; ...

acabcbaca/bdbcacbdb/...

(Just a move assignment I made up on the spot.) For irregular patterns like Smess there is no way to avoid specifying all squares explicitly, but regular cases one often encounters are homogeneous ranks, alternating squares on a rank, identical ranks or pairs of ranks. This is acually a problem that is very similar to coloring of the board, so the solution you use in the Diagram Designer for that should be applicable here.

For the specification of a number of squares (e.g. the starting squares of the pawns) I support a shorthand I.D. where you only have to specify the lower left and upper right corner of a rectangular board area, separated by a dash. That doesn't help much in Smess, but for Xiangqi a0-i4 would give you the entire area below the River, and d0-f2 the white Palace.

Are you saying this is something your code already supports or that it is an idea you would be behind?

Still, having to fully write down the list of coordinates for nearly all board squares is probably more cumbersome than using a FEN-like notation for the entire board.

It would be more compact, but it would take the same mental effort^* as it would to write out each coordinate in a select-case structure like I proposed, and the select-case structure would have the advantage of being easier for a person to read and understand, as it would allow someone to go directly from the coordinate to the Betza code without taking the time to mentally unpack the FEN-like string.

* or more actually as you would be taking the extra step of compressing your data.

The current code supports the format for indicating starting squares of the pieces, which it currently the only place where it interprets square coordinates. But if it was needed to process case labels referring to board squares, it could use the same shortcut.

I am not yet convinced enumerating the squares as case labels is the most convenient solution for the reader, though. To know how a piece moves he would have to search it amongst the case labels. Even if we adopt the convention to order these alphabetically, if there are many different square properties, he still would have to examine all the lines. But if the board is represented as a FEN he would know exactly where to find the square, as a FEN is basically an image.

Another problem with the case labels is that it is hard to find a shortcut for checkered patterns, which can be expected to be a common case. For Elk Chess it would be annoying if you have to write 32 case labels of the dark squares for the N move, and the other 32 case labels for the R move. The shorthand rules already used by the I.D. for the morph  FENs make it easy to represent such patterns in a compact way.

But I guess that in the context of the I.D. we should above all ask ourselves the question "where will it be displayed, and what is the intended audience. The Diagram definition would normally be invisible to viewers of the page. And if this info would be displayed at all, it would not have to be displayed in the same format as in the Diagram definition.

I think the most convenient way to present this info to the reader is put the list of squares in parentheses behind the piece name in the piece table. Each move would have da different entry in this table. In the simplest implementation it would be the responsibility to write this list himself as part of the name. But it could also be added automatically, based on the square-property FEN. In principle it would be a comma-separated list of squares, but some regular patterns could be recognized (rectangles, which includes files and ranks, or chrckering), an special verbal descriptions could be shown for those (such as "on dark squares").

Of course the reverse could also be possible: the person creating the Diagram could write the list of squares, or the special phrases behind the piece names, and the Diagram script could recognize those, and apply the indicated moves accordingly.

Another problem with the case labels is that it is hard to find a shortcut for checkered patterns, which can be expected to be a common case. For Elk Chess it would be annoying if you have to write 32 case labels of the dark squares for the N move, and the other 32 case labels for the R move.

Using wild cards, it could look like this:

[aceg][1357]: [bdfh][2468]: R; *: N;

I looked into whether JavaScript has wildcard support, and I did not find any native function that supports it. But I did find an article called Wildcard Pattern Matching in JavaScript with a short function that does wildcard pattern matching by converting a wildcard pattern into a regular expression and then doing a regular expression match. Here is the function:

function wildcardMatch(text, pattern) {
    const regexPattern =
        new RegExp('^' + pattern.replace(/\?/g, '.').replace(/\*/g, '.*') + '$');
    return regexPattern.test(text);
}

To test it, I wrote a pair of loops to generate all the coordinates on a Chess board, and I had it display each coordinate only if it matched the pattern. Then I tested it with the patterns "a1", "*", "[abcd]?", [e-h]?", and "[aceg][1357]", and I got correct results each time. Since it's actually doing a regular expression match with some slight changes to the pattern, I also tested "([aceg][1357]|[bdfh][2468])" and got it to display all the black spaces.

But I guess that in the context of the I.D. we should above all ask ourselves the question "where will it be displayed, and what is the intended audience. The Diagram definition would normally be invisible to viewers of the page. And if this info would be displayed at all, it would not have to be displayed in the same format as in the Diagram definition.

There are two types of people who would be interested in looking at it. The first is someone with a knowledge of Betza code who finds it helpful for learning the rules of a game. The second is a programmer who wants to understand how it was programmed in order to be able to do something similar.

But if the board is represented as a FEN he would know exactly where to find the square, as a FEN is basically an image.

For each type of person who would be interested in looking at the code, I think that using a FEN-like representation of the board will add an extra layer that requires some interpretation for a full understanding. For most games that give the same piece different powers on different spaces, short wildcard patterns (or just regular expressions) could be used to distinguish light and dark squares, one side of the board from the other, or isolated sections of the board from the rest of the board. Only a game like Smess or Storm the Ivory Tower would need the whole board spelled out, and the code could be made more compact by grouping together squares on which the same piece has the same powers of movement. This could be done with a switch-case structure as I first suggested, or it could be done as a single regular expression that includes all relevant spaces. A switch-case structure, though, would still be helpful for providing a default value without the need to devise a wildcard pattern or regular expression to match the remaining spaces. It could just be applied to any space that had not matched any previous pattern in the sequence.

Note that by select-case in earlier comments, I meant switch-case, though it does look like BASIC does call it select-case instead, and I do also have background in BASIC.

Well, what programmers would have to specify for configuring the Diagram, and what users will finally get to see as a result of that, are completely independent issues. And I am usually a lot less considerate towards programmers than towards users. It is also worthwhile to have a unified method for specifying things, rather than completely different methods for each feature. Irregular promotion zones are already specified in the I.D. through a FEN-like board image, not through a case-label-like list of square coordinates.

What I would want the user to see in a variant with pieces that have location-dependent moves is a piece table with a separate entry for each possible move (so that the user can request move diagrams for each case selectively, by clicking those entries). And the name fields in the table should then get a list of squares where this move applies appended to them. Certain shorthands like a1-h4, or dark/light squares could be used in those lists. The image could be the same for all these entries, or different, as the Diagram's creator thought best. Personally I like to be able to see unambigously how a piece moves from its image, without having to deduce it. So for the Elk Chess Diagram I used a different representation for the Elk on light and dark squares (a Pegasus when it moves like a Knight, a Rook where it moves like a Rook). For Xiangqi I would be inclined to use the same Pawn image on both sides of the River, though.

As for configuring the I.D., I have been experimenting a bit with a new parameter moveMap, embedded between the piece definitions. This can define a FEN of lower-case letters abc..., where a then refers to the preceding piece definition, b to the one before that, etc. This map would than define the morph boards of all the piece entries it refers to. (While the existing morph parameter would define morphing in terms of piece ID rather than sequence in the table, and apply only to a single entry.)

As a shorthand for defining the various moves a piece can have I experimented with the possibility to write a comma-separated list of move descriptors in the field of the piece definition where normally the (single) move descriptor goes. The Diagram script would then automatically expand that to a separate entry for each move in the piece table, with all identical properties except for the move. This would work in cases where you want the piece to be represented by the same image everywhere. This is only useful, though, if the list of squares to which the move applies is appended automatically to the piece name; this cannot be done by hand when the name dield is automatically duplicated. This would require some smartness in the script for recognizing rectangular areas (including files and ranks) or square shades.

Considering that so very few variants would make use of this feature, I wonder if the latter is worthwile...

Well, what programmers would have to specify for configuring the Diagram, and what users will finally get to see as a result of that, are completely independent issues. And I am usually a lot less considerate towards programmers than towards users. It is also worthwhile to have a unified method for specifying things, rather than completely different methods for each feature. Irregular promotion zones are already specified in the I.D. through a FEN-like board image, not through a case-label-like list of square coordinates.

I have not proposed anything regarding the specification of irregular promotion zones. My proposal was for how to specify the powers of a piece whose powers of movement are location-dependent. While you might try to simulate that with promotion zones, it is not the same thing, and doing it this way would likely require more overhead and be more confusing to someone looking at it to understand how a piece moves.

I do not see any conflict between making things easier for the programmer and easier to understand for the visitor. What I proposed would be both. Wildcards (or even regular expressions) are no harder to understand than Betza code, and they are both better known than Betza code. Using them in a first-come-first-used manner like cases in a switch statement would allow for a compact presentation of how a piece moves in a manner that should be hardly any more difficult to understand than using Betza code to define how a piece moves.

Well, it is the same thing in the sense that you are specifying square properties. Which can be that the piece reaching it will change its move permanently (true promotion) or only for as long as it is there (location-dependent moving).

Well, it is the same thing in the sense that you are specifying square properties.

Technically, neither one is specifying square properties. Specifying square properties was the first thing I proposed, but you didn't want to do that. So I proposed an alternative to specifying square properties that would still allow each piece in this game to be described in a simple, self-contained way.

Which can be that the piece reaching it will change its move permanently (true promotion) or only for as long as it is there (location-dependent moving).

As far as I understand what you are proposing, it is neither simple nor self-contained. Instead of giving each piece a simple, self-contained definition, you would split the definition of each piece into multiple interrelated piece definitions that refer back to each other. If they all referred to the same FEN-like string, then they would all require something external to themselves to be complete. If they kept things internalized by duplicating this string, it would bloat the code.

Specifying square properties was the first thing I proposed, but you didn't want to do that.

Not really. What I said was:

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.

So what I really said is that the I.D. already did support square properties, through the morph parameters. It is just a matter of what game rules you want these properties to affect.

As far as I understand what you are proposing, it is neither simple nor self-contained. Instead of giving each piece a simple, self-contained definition, you would split the definition of each piece into multiple interrelated piece definitions that refer back to each other. If they all referred to the same FEN-like string, then they would all require something external to themselves to be complete. If they kept things internalized by duplicating this string, it would bloat the code.

It doesn't really bloat the code, as it would simply use the already implemented code for selectively transforming piece types into each other on reaching certain squares, in a peculiar way. But it would bloat the table that specifies this 'morphing', by adding a new board-size 'plane' to this conceptually 3-dimensional table indexed by piece type, file and rank. Having a few hundred extra integers in that table hardly seems an issue in these days, where computer memories are sold by the gigabyte.

How exactly things are implemented in the script should not concern anyone, as long as it does what is required and will not consume annoyingly much resources (such as CPU time or memory). The only thing that matters is how we want to present a game with such rules to the user, and to a lesser extent how someone posting a Diagram would have to configure it. How the latter works in HTML is actually hardly important, as people who master HTML should not have any difficulty either with the FEN or the case-label implementation, and those of a less technical disposition will use wizards like the Play-Test Applet for generating the HTML. So we'd better avoid that this discussion degenerates into some kind of rear-guard skirmish on an issue that no one will ever be exposed to.

So the real issues are what the user should get to see for a variant like this in the finished Diagram. Since one of the functions the Diagram support is the summoning of move diagrams through clicking on a list or a table of pieces, it seems necessary to provide multiple entries in these tables for a piece with a location-dependent move. The I.D. also allows summoning of a move diagram by right-clicking a piece, but in that case it seems the best thing to do is to show the moves diagram for the piece in the current location. For each move diagram the list of squares on which the displayed move pattern applies (in condensed form where this is possible) could be shown above the board, behind the name of the piece. Or perhaps better, it could already be shown behind the name of the piece in the list entry you would have to click.

What I have in mind is just a comma-separated list of square coordinates as the most general form, where shorthand notation would be used for at least entire files and ranks (e.g. as 'e-file' or '2nd rank') and the tems 'dark/light squares' for checkered patterns. So no case labels, and no FENs.

Do you have things in a mature enough state to show what your code would look like?