Ratings & Comments
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 10:01 AM UTC in reply to Fergus Duniho from 02:04 AM: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...
Chu Shogi. 
Historic Japanese favorite, featuring a multi-capturing Lion. (12x12, Cells: 144) (Recognized!)[All Comments] [Add Comment or Rating]A. M. DeWitt wrote on Sun, Jul 14 01:46 PM UTC in reply to H. G. Muller from 09:38 AM:All the cases I mentioned are fixed. I did find a couple more bugs though:
In this game, after the Soaring Eagle takes the Lion and then moves to a non-Lion square, the counter-strike highlights do not appear.
1. e5 h8 2. De4 Dh9 3. Df5 Dg8 4. Dxf9+ Dxg4+ 5. Gd2 Gi11 6. Ke1 Kh12 7. +Dg8 +Df5 8. +Dh9 +De4 9. +Dxg10xf11 or +Dxg10xh9
However, if Sente makes a random move (i.e. advancing the left edge Pawn w/ 9. a5) and Gote tries the same thing w/ 9... +Dxf3xg2 or +Dxf3xe4, the counter-strike highlights are displayed correctly.
In this game, after a Kirin takes a Lion and promotes to Lion, the counter-strike highlights erroneously appear on the newly promoted Lion:
1. Ne5 Nh8 2. f5 g8 3. Of4 Og9 4. Of6 Og7 5. Of8 Og5 6. Og9 Of4 7. Oxh8+
In this game, after moving the Lions adjacent to each other, the bridge-capture highlights still show even though the Lions are adjacent:
1. Ng5 Ng8 2. Ni6 Ni7
📝H. G. Muller wrote on Sun, Jul 14 06:44 PM UTC in reply to A. M. DeWitt from 01:46 PM:OK, I solved the 'promoting Kirin' bug. This was due to the AI comparing the capture square with the origin of the previous move, rather than the destination.
The adjacent case is partially due to a 'calculated risk': the exemption of adjacent Lions from the protection rule is motivated by the fact that you would never want to capture a protected Lion by replacement if you could capture it throug hit & run. Making the same exception for a piece not capable of locust capture makes no sense. To make the rule also useful for such pieces, I dropped the adjacency condition from the implementation of the rule in the Interactive Diagram. The AI might erroneously believe it was illegal, but it would virtually never want to play it anyway. And when the highlights were still only pseudo-legal, it would not make any difference there either.
The other part of the problem might be solvable in the highlighting: even though it thinks the replacement capture is illegal, it thinks locust capture is allowed, so there also is a cyan start highlight on that square. (Which overrules the red triangle for the direct capture because of the order of these in the XBetza spec.) I guess I should in any case refrain from overruling the star marker by a cross. The cross then would still appear in the highlights for the second leg, for the click that would select termination after the first leg, though. But that is the move you would almost never want to play, so this might be excusable. After all, moving the King in check is also highlighted by a cross now, and that is not strictly forbidden in Chu Shogi either. So the meaning of the cross should be taken a bit liberally, as 'not recommended', rather than strictly forbidden.
The third case was due to forgetting to strip off the color bit when looking up the anti-trade properties when testing whether the replacement victim had to be replaced by the locust victim when setting the temp-iron type.
Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]Is it possible to define properties for spaces, then to define movement in terms of the properties of the space it moves from?
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.
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.
Chu Shogi. Historic Japanese favorite, featuring a multi-capturing Lion. (12x12, Cells: 144) (Recognized!)[All Comments] [Add Comment or Rating]A. M. DeWitt wrote on Sun, Jul 14 11:50 PM UTC in reply to H. G. Muller from 06:44 PM:Looks like everything is fixed as far as highlights go (The important part is that all illegal Lion-trading moves are highlighted as such). I have copied the updated betzaNew code to my Chu Shogi Applet.
[Edit] I added the line morph=| after the Pawn definition to allow Pawns to promote on the last rank on a non-capture.
Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]H. G. Muller wrote on Mon, Jul 15 05:30 AM UTC in reply to Fergus Duniho from Sun Jul 14 10:26 PM: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'.
Minor Chess Variations. Members-Only Slight diffs from popular inventions. (8x8, Cells: 64) [All Comments] [Add Comment or Rating]Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Comrade Chess. Comrade instead of Queen. (8x8, Cells: 64) [All Comments] [Add Comment or Rating]Thanks for reviewing and publishing!
Bn, you are the most active editor who attends to my pages)
Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]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.
H. G. Muller wrote on Mon, Jul 15 06:42 PM UTC in reply to Fergus Duniho from 05:01 PM: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.
FOOD FIGHT!!!. Game Courier preset for FOOD FIGHT!!! (12x12, Cells: 144) [All Comments] [Add Comment or Rating] Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]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.
H. G. Muller wrote on Tue, Jul 16 05:53 AM UTC in reply to Fergus Duniho from 02:36 AM: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.
Lighthouse. Game like Chess and Makruk but on the half of chessboard with drops and full chess set used. (4x8, Cells: 32) [All Comments] [Add Comment or Rating] Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]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.
Game Courier Logs. View the logs of games played on Game Courier.[All Comments] [Add Comment or Rating]Can someone add Red Rose I made to the "Alfaerie: Many" set under code _AS_RO_r
Link to the image: https://ibb.co/vd3CCSv
Chu Shogi. Historic Japanese favorite, featuring a multi-capturing Lion. (12x12, Cells: 144) (Recognized!)[All Comments] [Add Comment or Rating]A. M. DeWitt wrote on Tue, Jul 16 01:20 PM UTC:There's a visual bug with CountRoyals() where it counts a piece with the protected/counterStrike property as royal if there are no true royals of the same color on the board. This probably has something to do with how values in the royalness array are interpreted within the function.
As per your recommendations, I did some testing with the AI, and I encountered a bug where the counter-strike rule is not being followed by the AI at all.
Case 1: Normal pieces
1. Nh5 Ne8 2. Ni7 Nd6 3. Ixd6
Responds with 3... Ixi7
Case 2-5: Multi-movers
1. e5 h8 2. De4 Dh9 3. Df5 Dg8 4. Dxf9+ Dxg4+ 5. +Dg8 +Df5 6. +Dh9 +De4 7. Gd2 Gi11 8. Ke1 Kh12
Case 2: Normal move
9. +Dxg10
Responds with 9... +Dxf3xe2
Case 3: Igui
9. +Dxg10xh9
Responds with 9... +Dxf3xg2
Case 4: Double capture, Lion captured on first move
9. +Dxg10xf11
Responds with 9... +Dxf3xg2
Case 5: Double capture, Lion captured on second move
9. +Dxi8 +Dxd5 10. He4 Hh9 11. +Dxh9xg10
Responds with 11... +Dxe4xf3
Case 6: Capturing two Lions
1. f5 g8 2. Of4 Og9 3. Of6 Og7 4. Of8 Og5 5. Og9+ Of4+ 6. +Og7 +Of6 7. +Og6 +Of7 8. +Of4 +Og9 9. h5 e8 10. Hxd8 Hxi5 11. He9+ Hh4+ 12. +Hf8 +Hg5 13. +Hxg8 +Hxf5 14. Gd2 Gi11 15. Ke1 Kh12 16. +Hxg9xg10
Responds with 16... +Hxf4xf3
Case 7: Kirin promotion exception
1. f5 g8 2. Of4 Og9 3. Of6 Og7 4. Of8 Og5 5. Ne5 Nh8 6. Og9 Of4 7. Oxh8+
Responds with 7... Oxe5+
Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]H. G. Muller wrote on Tue, Jul 16 02:22 PM UTC in reply to Fergus Duniho from 12:43 PM: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.
Game Courier Logs. View the logs of games played on Game Courier.[All Comments] [Add Comment or Rating]Красиво, но вряд ли им нужно.
Chu Shogi. Historic Japanese favorite, featuring a multi-capturing Lion. (12x12, Cells: 144) (Recognized!)[All Comments] [Add Comment or Rating]📝H. G. Muller wrote on Tue, Jul 16 07:52 PM UTC in reply to A. M. DeWitt from 01:20 PM:It appears that betzaNew.js never passed the last game move to the AI. The code I had added to pass a dummy move in case no game move was played yet erroneously always passed the dummy move (because the moves are JavaScript objects rather than arrays, and I tested for the latter). So the AI would also not have been able to perform e.p. capture.
Should be fixed now.
25 comments displayed
Permalink to the exact comments currently displayed.
All problems you pointed out should be solved now. (Thanks for finding those!)
The problem with promotable pieces was caused by promotion scoring to take place after royalty checking in ScoreMove; because of that the 'immediate loss' score of -15000 was increased by the promotion gain, and no longer recognized as such. It should have returned the losing score immediately when it was found. (This should not have hurt the AI very much, as the score would still be extremely low, so that it would only count on the forbidden move in positions where getting checkmated was the only alternative.)
I implemented type groups for counter-striking, assigned by counterStike=N behind a piece type that should be added to another group N than its own type number (and added that behind the Kirin to map it to the Lion's type, N = 20).
The problem that the final victim of a double capture was not noticed as having to be declared temporary iron, is solved in a fragile way: ScoreMove was adding the anti-trade codes of all victims, and (if one of those was subject to a counter-strike rule) would then check the type group of the last-handled victim (the locust victim) to see if it belongs to the temporary iron type group. I now added code to test whether this victim actually has the counter-strike property; if not, the other victim must have been responsible, and it substitutes the replacement victim for it before doing the type-group test. This solves the Chu-Shogi case, but could fail if there are more than two victims, if there are two locust victims, or if both victims have the counter-strike property, but belong to a different type group. (And there is currently no method for declaring more than one type-group temporary iron.)
I also fixed the moving into check highlighting; I had forgotten to call CountRoyals() in the betzaNew.js here on CVP.