Ratings & Comments
That's perfect! Now that that's done, I can test a double-burning Suzumu Fire Demon.
Also, for some reason the Comments section is excessively narrow when viewed from the interactive diagram page.
Now that triple captures other than those of the Lion Dog are supported by the interactive diagram, I am currently testing a new version of Suzumu Shogi, with burning pieces (Fire Demons and Heavenly Tetrarches) that can burn (or capture without moving as in igui) up to two adjacent pieces at once.
I have never built an engine for such variants, and hardly ever played them myself. But strategy is much more subtle than you might think. From other engines (like Sjeng) I know that piece values are different from Chess, but positive. E.g. a Queen is worth about 6 Pawns. To win you must get a controlling advantage, so that you can force the opponent to take your weak pieces, which otherwise are difficult to get rid of. E.g. when white has all pieces in the FIDE start position, and black only his King and Pawns, white very easily wins.
Ok, thanks. I was not aware of Sjeng. Open source too!
It’s not ready, it’s list, as notation, and for likers. This notation is used in my games. Symbols above/under pieces are existing when this piece is made later.
No, my Fluidity have many difference from it [Jumping Chess].
It’s not like diffs between Carrera’s and Capablanca’s setups of Archbishop and Chancellor, it’s like diffs between Capablanca’s and Seirawan’s chess.
https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168
We're having a problem with this game. On move 17, the pawn on g6 is captured when it shouldn't be. This seems to happen no matter what move white makes.
So it’s notation not for single variant, but for more — for game.
But I don’t know now how to enable letters with symbols or small letters.
It’s not ready, it’s list, as notation, and for likers. This notation is used in my games.
On a page for a game you can say what letter you want for each piece in that game, but the list will not have a page of its own. This page will not be published.
No, my Fluidity have many difference from it [Jumping Chess].
It’s not like diffs between Carrera’s and Capablanca’s setups of Archbishop and Chancellor, it’s like diffs between Capablanca’s and Seirawan’s chess.
I understand it is different. Jumping Chess is a good, playable game. This one is not.
If I understand this correctly the King is the only piece that can be captured by displacement. All other pieces can only be captured by jumping over them, and there is no limitation to the number of pieces you can capture this way. (Well, the limitation is put by the board size.) Only the final square has to be empty or contain a King. Knights are supposed to move along an L-shaped path, (long leg first), and are the only pieces that can jump over friendly pieces.
In principle the Interactive Diagram should be able to do this: In XBetza notation the sliders are just multiple mcaf steps, up to 6 times, followed by a final leg with mk mode. For the Knight there first are exactly two mpca steps before it turns sideways for the mk final leg, as it can also hop over obstacles.
For some reason the Diagram doesn't correctly perform these discriptions, though. I suppose there is a problem combining destructive (c and non-destructive (mp) modes on the same leg. For the Knight I could fix that at the cost of far higher complexity of the XBetza description (mpcafmpcasmkW should have been enough). This seems to be a Diagram bug that should be fixed.
[Edit] Oh, stupid of me. Because the sliders cannot jump friendly pieces, a much simpler description is possible. E.g. (caf)6mkB instead of (mcaf)6mkF. Because B is a slider the intermediate m steps are automatically bridged, and no combination of m and c modes is necessary. Apart from capture during castling everything now appears to work.
BTW, this is a nice demonstration of the Diagram's new move-entry system, with up to 7 pieces captured in one turn!
satellite=fluid
files=8
ranks=8
maxPromote=0
graphicsDir=/graphics.dir/alfaeriePNG/
squareSize=50
firstRank=1
lightShade=#FFFFCC
darkShade=#669966
holeColor=#663300
rimColor=#663300
coordColor=#D6DEAD
whitePrefix=w
blackPrefix=b
graphicsType=png
useMarkers=1
borders=0
enableAI=1
newClick=1
knight:N:mkNmpafmcpasmWcafmpasmWcafcasmW::b1,g1
bishop::(caf)6mBkB::c1,f1
rook::(caf)6mRkR::a1,h1
queen::(caf)6mQkQ::d1
king::mKisO2::e1
|
Fluidity ChessSeems white has a very easy forced win, though: 1. Qe2+. Since the Queen cannot be captured by displacement it is practically iron when in contact with the enemy King, and threatens that with displacement check. So it drives it very easily to the edge (or actually against the Rook files) for checkmate. |
Daniel Zacharias wrote on 2022-11-16 UTC
https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168
We're having a problem with this game. On move 17, the pawn on g6 is captured when it shouldn't be. This seems to happen no matter what move white makes.
Should be fixed now. Turned out e.p. squares were never cleared until another double push was made. Apparently g8-g6 had been the latest double-push, so when a Pawn then captured to g7... Amazing that no one ran into this problem before.
satellite=ortho
ranks=8
files=8
maxPromote=2
promoZone=1
promoChoice=RGB
holdingsType=1
graphicsDir=/graphics.dir/horizons/
squareSize=57
symmetry=mirror
lightShade=#A08FAF
darkShade=#7D4A8D
holeColor=#111199
whitePrefix=w
blackPrefix=b
graphicsType=png
useMarkers=1
borders=0
Pawn:::pawn:c2-f2
Warrior::ifmnAfmFfceW:berolinapawn:a2,b2,g2,h2
Gold:::gold:b1,g1
Bisroos::mkBkcR:bishop:c1,f1
Roobis::mkRkcB:rook:a1,h1
Torch::(afmpaf)3K:torch:d1
King::KisO2:king:e1
|
Orthodia |
I still had to write a BadZone function for this one, despite my efforts with the captureMatrix parameter. Because the ban on capturing Kings with the capture move for divergent pieces is dependent on the move, not just on the piece type. XBetza can indicate a move can only capture royalty (k modifier), but not that a move can capture anything but royalty. I suppose I could make an XBetza extension for that, by adopting the convention that the combination kc means non-royal capture. This would otherwise be a useless combination, as c already includes capture of royals. So k becomes a kind of toggle modifier, which negates the possibility to capture royalty from what it would have been without its presence.
[Edit] This is achieved now, and the Diagram now is working without any custom scripting.
Thank you for making the diagram so we can test. Unless I'm missing something, it looks like white wins in 3 moves.
One other question: how will the new move generation affect the pieceZone and piecePromotion functions (and other functions that use parameters representing move coordinates)? The new code does not appear to use the old variables that keep track of a move's coordinates. Instead a clicks array is used to store the coordinates for every clicked square in one variable. For obvious reasons, the old parameter list for pieceZone and piecePromotion wouldn't really work all that well.
Also, you should consider adding a section about the user-defined functions so people don't have to read the comments to figure out what they do.
Same here. I tried to get this working in the spring. One of the guys (moderators) even tried to fix it manually for me. It just doesn't work. And it'd be very helpful if it did cause I would get notified when my opponents move.
By the way, I believe I did get the verification emails, they just didn't work.
I guess I forgot to have the callbacks for the Shogi promotion (on the yes/no message) call the new handler for finishing the move.
Should be fixed now.
As to documenting the WeirdPromotion / BadZone scripting stuff. So far I have refrained from doing that, because writing their own JavaScript would be beyond the capability of most prospective users (present company excluded), and dwelling too much on it in the description of the Diagram is more likely to discourage people from using the latter than to help them.
But there are other reasons as well: this part of the Diagram is pretty much experimental and still in development; I already changed the parameters used in the function calls several times, and even the current argument list of WeirdPromotion is not well suited for the new move-entry system, as it only a single e.p. square. I now also regret that WeirdPromotion and BadZone are separate functions. It would have been quite possible to have their tasks shared by a single function, which, when called with the full description of the move, would return whether the move should be rejected, result in game termination, change the piece type in a mandatory way, or offer promotion choice. And in the latter case it would be desirable if it could actually specify what can be chosen. E.g. by returning a string in the format used for promoChoice, overruling the latter.
And I actually consider it an embarassment that such scripting is needed at all. Ideally it should be possible to specify the rules solely through Diagram parameters. The newly introduced parameters morph and captureMatrix make a great step in that direction; these are very powerful features, which could satisfy the requirements for the large majority of Diagrams for which I originally had to write WeirdPromotion aor BadZone functions.
I have implemented k now such that in combination with c it disables capture of royals. (A combination that before was not different from plain c.)
Actually this means that k now can do what the t modifier (for 'tame') does in XBoard. Without using an extra letter!
In the process of testing it I found out there was a horrible e.p. bug in the AI of the Interactive Diagram: it was always considering the destination of any normal moves an e.p. square. But since usually pieces that can e.p.-capture also would have normal capture to the same square, it would not have any effect other than that the capture would be generated twice. With the new move entry routine this would require an extra click on the destination, though, to resolve the 'ambiguity'.
I am surprised that this article was published. The English is rather poor, and I can hardly understand what the rules are. The layout is awful; there is an enormous disparity in the size of the various graphics. The Berolina Pawn is presented like it is a new invention for this game.
It seems the Shielders can push away pieces, but it remains unclear where these pieces then end up. This Diagram assumes you can push one piece, and it goes one square backward.
satellite=horizons
ranks=12
files=12
maxPromote=4
promoZone=1
promoChoice=QMZROBN
holdingsType=1
graphicsDir=/graphics.dir/galactic/
squareSize=50
symmetry=mirror
firstRank=1
lightShade=#CCCC11
darkShade=#339933
holeColor=#111199
rimColor=#111199
coordColor=#CCCC11
whitePrefix=W
blackPrefix=B
graphicsType=gif
useMarkers=1
newClick=0
borders=0
Pawn::::e2-h2
Warrior::ifmnAfmFfceWfcnD:Super:c2,b2,j2,k2
Shielder::ifmnDfmWsceWfmpafabcuW:Soldier2:a2,d2,i2,l2
Warrior::ifmnAfmFfceW:Super:
Knight:N:::d1,i1
Bishop::::e1,h1
Rook::::a1,l1
Ox::nDafafsfW:Taurus:c1,j1
Zip::Waf(afz)10W:Cannon:b1
Magician::afyafyafsK:Fairy:k1
Queen::Q::f1
King::KisO3::g1
|
Horizons |
Diagram parameters would be ideal, but there's one little problem. When rule enforcement require complex decision making (such as in Suzumu Shogi's current version, which forbids burning pieces from burning each other) the diagram parameters would be less than ideal. So there would likely still be a need for such functions even if the parameters eliminate the majority of cases where they would be needed.
I'm not sure how you intend to merge move rejection, game termination, mandatory promotion, and offering promotion choice, into a single function, unless JS allows you to return a value that could be one of many different types.
But I suppose it is better to stick to perfecting the new move generation system for now and focus on the functions later in development.
Some words have been corrected
- (e.g. Surrender -> Resignation)
And some pieces have been renamed to make them easier to read
- (e.g. 雲 ⇒ 云)
I'm not sure how you intend to merge move rejection, game termination, mandatory promotion, and offering promotion choice, into a single function, unless JS allows you to return a value that could be one of many different types.
This is exactly what JavaScript allows. It is a 'typeless language', where any variable can hold, or any function can return any type of data structure. Move rejection and game termination go through numeric codes (BadZone does that now, 1 for rejection, 0 for allowed, -1 and -2 for termination), forced promotion or a choice request as well (by WeirdPromotion, returning the piece-type number or 1000). It would be easy enough to rearrange the numeric codes such that they do not collide. It is just that when you request promotion choice, it uses the same procedure as when you enter the zone, controlled by promoChoice or promoOffset. Here it would increase flexibility if I allowed returning a character string or (more efficiently, but perhaps less user-friendly) the array that such a string would parse to when given as promoChoice. (Such an array would be indexed by piece type, and contain a non-zero value for each piece type that in principle can be chosen. Where 2 means 'if available in the holdings', and 3 means 'not on last rank'.
I understand that it will never be possible to handle everything by parameters. But the main point is that I don't want to realease on afficial specification for something I would have to change later. That would load the whole project with an obligation to remain backward compatibility for the legacy features. Now in this case it would probably not be so hard to maintain such compatibility: I could switch to a usiversal Custom() function that takes care of everything, only invoked when no parameters (such as morph or captureMatrix) are specified that require use of the standard function, and the user specified a legacy BadZone() or WeirdPromotion(). This Custom() function would then call the latter two, and integrate their return values into the new format. This Custom() could just get the complete move description used by the AI passed as an array.
I removed the Unique Pieces tag, because there is nothing stopping other games from using the same pieces, and then they wouldn't be unique any longer. Tags should be used for non-relational properties, not for relational or comparative properties like unique or best.
I can't bear to look at the graphics on this page. I have never liked the Galactic set, and these huge smiley graphics are like something from a nursery room.
25 comments displayed
Permalink to the exact comments currently displayed.
Indeed it does. So this is another use for IllegalUnlessOnly (I'd like to think of a better name for that. IllegalUnlessExclusive maybe?)
For positional evaluation in this game, is everything basically negative? My frist thought was to make the material values of the pieces negative. But it's also bad to have one's pieces in the center, so the PSTs are basically negative also. And maybe everything ... having your rook on an open file is bad. A knight outpost is bad. Is "good" pawn structure also bad? On that, I'm not sure.
And if everything is reversed, maybe just invert the eval after everything? (assuming it's not a mate score, -INFINITY is still -INFINITY). Just thinking out loud. And I don't currently have a "hook" in place for adjusting the whole eval after calculation but I could easily add one. The whole "losing genre" jenre is one I would like to support...