Ratings & Comments
Secret Intelligence Chess. A game of secrecy, disinformation, and detection. (8x8, Cells: 64) [All Comments] [Add Comment or Rating]One further tweak I'm thinking of making to the rules is to let the Decoy move to an attacked space next to its King. This would increase its attacking ability in the endgame, allowing a King + Decoy vs King game to play like a King + Centaur vs King game. But it would not decrease a player's knowledge about which spaces are attacked around the Decoy, because the King would still be unable to move to any attacked space next to it. By checking where both pieces can move, a player could still tell whether a Decoy move next to its King would be safe.
Another alternative I was considering is that a Decoy could move next to the enemy King. While this would also allow the Decoy to behave like a Centaur in a K+D vs K endgame, it would impair the Decoy's ability to avoid check and to detect the enemy King.
One more alternative I was considering was to allow the Decoy a one-time demotion to a Centaur. This would remove its disinformation sowing and intelligence gathering abilities and give it more attacking power. I even considered the idea of letting most pieces demote to lesser pieces, which could be an effective way to sow some disinformation when a piece is about to be captured, but that's probably going too far.
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 28 11:23 AM UTC in reply to Fergus Duniho from Thu Jul 18 04:38 PM: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...
Elkrider Chess. Elkrider plus regular pieces. The Elkrider moves like a Nightrider if standing on white squares, otherwise it moves like a Rook.[All Comments] [Add Comment or Rating]Rotate Symmetry Elkrider Chess
Or use friendly capturing pieces, or use relay pieces, or use backup moves.
Ghetto Gang by AlexandrGornostay, AKA CatTitan, alexandrhermeline, Sasha Gornostay
You can find more of his board games here.
Muje (Untitled). Members-Only Janggi + Chess + Drop rule of Shogi. (9x9, Cells: 81) [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.
Rocket Chess. Space-themed fairy chess variant on neoteric board: piece’s movement depends on type of cell where it stands. (Cells: 248) [All Comments] [Add Comment or Rating]Snake Pit by Stuart Spence, AKA Zulban_tyr
But 961.
Regular Riders. Members-Only An army where pieces are riders. (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.
It turns out, rather to my annoyance, that my computer problem wasn't with my computer at all, but with my uninterruptible power supply, which needed to be reset.
Meaning I could've had it going in a half hour if I'd tried it in the first place.
Ah well... with the month-long delay, this will no longer be Piece of the Day. It'll just be a Piece Index once I get things going again.
(And yes, I probably will make a single-page index of the bunch.)
Play-test applet for chess variants. Applet you can play your own variant against.[All Comments] [Add Comment or Rating]In this Play-test applet I haven't found out how to promote multiple pieces to different promotions. How would an HTML-Code for Variants such as Shogi look like?
💡📝H. G. Muller wrote on Tue, Jul 30 12:10 PM UTC in reply to Khai from 10:26 AM:This is indeed something that cannot be done through the Applet, but which can be specified in the HTML for an Interactive Diagram. With the promoChoice parameter you can specify several 'promotion sets', separated by slashes. For each piece that promotes you can then specify a morph parameter to indicate where it promotes, and a digit 1-9 would indicate which of the extra promotion sets should be offered as choice there. (For the first set the square in the morph value should be set to *.)
Great Bird Chess. Members-Only Missing description (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.
Jester chess
Omega chess plus
Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]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.
Featured Chess Variants. Chess Variants Featured in our Page Headers.[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]H. G. Muller wrote on Tue, Jul 30 09:14 PM UTC in reply to Fergus Duniho from 05:54 PM: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.
H. G. Muller wrote on Wed, Jul 31 08:38 AM UTC in reply to Fergus Duniho from Tue Jul 30 10:58 PM: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.
Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]Do you have things in a mature enough state to show what your code would look like?
Secret Intelligence Chess. A game of secrecy, disinformation, and detection. (8x8, Cells: 64) [All Comments] [Add Comment or Rating]One further tweak I'm thinking of making to the rules is to let the Decoy move to an attacked space next to its King.
I have updated the alternative description of the Decoy to include this exception. Since there are no ongoing games of the alternative version right now, I updated the code to support this new exception, and I fixed some bugs concerning the movement of the Spy and Decoy. These changes did not affect the code for the earlier version, which does still have an ongoing game right now.
25 comments displayed
Permalink to the exact comments currently displayed.
Squirrel Chess