Ratings & Comments
275. Yey. This is another piece that I built based on a letter of the Tifinagh, and it's one that I'm a little surprised I haven't alraedy posted.
Based on the Berber letter ⴻ, Yey moves one space sideways, or leaps two spaces vertically. If the latter move captures a piece, it may then move without capture from there to any adjacent space. (sW[vD?a(b)K])
I think that this would be an interesting piece to use as a special Pawn, promoted Pawn, or "superpawn."
Sorry, I was out of town for a few days, and had no time to figure out the answer on this one.
The presets you compare with were not automated through the PTA, so there is no reason why these should behave the same.
Are you sure the game ends when the King moves out of check? Normally an illegal move should not terminate the game; it should just be refused (in this case with the message you quote), and then through using the browser 'back' button you should be able to retry another move. This is also what happens if you insist moving a piece to a non-highlighted destination.
If this is the case the only thing that isn't working exactly as it should is the highlighting: the King jumps get highlighted even if they are forbidden because of check. But there is no way to exploit this; in the end legality is enforced by refusing the move.
The way the PTA-generated GAME code enforces 'not out of check' rules is by having the potentially forbidden moves generate e.p. rights on the square of origin. Using such a move then would allow the opponent to capture the moved piece (i.e. the King) en passant, making the move illegal.
Unfortunately the 'accelerated check test' used for determining the legality of the moves to highlight (in order to prevent this from becoming excruciatingly slow for large games) doesn't detect this: it generates all opponent moves from the current position to mark squares that are under attack on the board. And then only rejects King moves that go to such an attacked square. And in this case the problem is not that the destination is attacked, but that the origin is attacked.
I suppose I could solve this in the accelerated check test by suppressing the virginity of a King that is in check during the generation of the highlights.
[Edit] I now changed the move generator to suppress initial moves of a piece that should not move out of check, when it is in check during the accelerated check test. Please test if this solves the problem.
Since the fairychess include file uses a shortcode to display pieces, I changed how the shortcode works instead of any code in the fairychess include file. I modified it to include WIDTH and HEIGHT values in the IMG tag when the image is an SVG image. These will be equal to $width and $height when these variables have values, as they usually do in Game Courier, and they will be 50 otherwise.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
It looks like replacing the corner piece with Limping Queen allows white to do 1.c6 then 2.Ga10. Looks like I have to change it again.
If this Limping Queen is the one that I posted in PotD a few days ago, I'm sorry I missed it.
(I also don't see how the nature of the corner piece affects the above opening.)
If I remember correctly, the PTA does that for all special King moves, such as castling.
Is it a matter of skill or a matter or perceived randomness?
I would ask that same question about nightriders, but they seem popular anyway. If I'm understanding you, the problem with Jokers is that they're too easy to exchange favorably because they're much stronger at the start than the end. I would expect that to be less of a problem with a very large game, since both players would have more opportunities to use their jokers.
If you're using it in a different armies game, the most important thing would be to have a joker in every army. Do you have an interactive diagram to show an example of a game where this piece might not work?
I repost this message which was probably missed:
@ HG Muller: I have a problem that I can't solve. In many of my variants I have a rule of King's leap to a 2nd square replacing castling. As for regular castling, the King may not leap when it is under check. It works fine for Metamachy, Zanzibar, Maasai, Terachess II, etc. But in Bigorra, the GC would let a CHECKED King leap to a 2nd-square! Actually, it marks the destination square as a possible move, but if the player does it (so, violating the real rule), the game ends with an error message saying the King has moved out of chess.
Why the Bigorra GC is behaving like that whereas Metamachy or Terachess II for example don't have this behaviour, I don't know. I would like to fix that bug in Bigorra GC but I don't know what to do.
I ask you because that GC had been made with the PTA from the ID. Could you please have a look on that GC?
https://www.chessvariants.com/play/pbm/play.php?game=Bigorra&settings=Default-PTA
Thank you very much
Since this comment is for a page that has not been published yet, you must be signed in to read it.
I have read Eric Silverman's thoughts on powerful pieces now. Trouble with the joker is that it's value is very volatile. In the beginning it is very powerful though. One could argue that maneuvering him it is a matter of skill. This, actually is my conundrum: Is it a matter of skill or a matter or perceived randomness?
By larger boards I mean strictly larger than 8x8. Even in 10x10(where I have 13 piece types) handling the enemy joker is quite tricky. 12x12 could work, too. But larger boards would make games impossible to play if the joker is present. Just imagine Tenjiku shogi with one or God forbid more jokers.
As I have said in my previous comment I have a large palette of piece types represented. This makes things even more complicated.
It could also be that I worry too much, but who knows.
It looks like replacing the corner piece with Limping Queen allows white to do 1.c6 then 2.Ga10. Looks like I have to change it again.
There's already an Interactive Diagram on the page but
When fairychess is allowed to fill in the rules section for a game that uses svg piece images, some of the pieces end up being much larger than the others. This seems to be because the image is sized according to the piece name, even if the name is very long. Having the css explicitly set the image size could solve this.
I'd call them Berlin Peon/Anti-Peon & Berlin Storz Pawn/Anti-Storz Pawn. Right Anti-Pawn & Left Anti-Pawn would be rmFrcW & lmFlcW.
I recently have broken my table and then sorted things from it. There were many CV drafts and thoughts, and among them I found pieces based on different time controls of standard chess, but pieces weren’t usual at all. One of them is Bullet, but I can call it Storm Trooper. It moves straight up to 4 forward, 1 backward (both are with or without taking), and also 1 sideways without taking, but there it can push one piece (if square isn’t free) in this direction: same logic as my Shieldholder from NDPRC and Horizons.
Have you read Eric Silverman's thoughts on poweful pieces? He suggests that it's good to have a few super pieces that dominate the game.
When you say "larger boards" it's not clear if you're talking about the later mentioned 10x10 CWDA or something else. 10x10 doesn't seem large, and you did use the Joker on 10x10 and 12x12 already. If you are talking about something truly larger than 12x12, the obvious way is to have the Joker start at the back and make sure the average piece strength isn't too high.
If you're worried about the Joker dominating the game by being too powerful, don't forget that if it's really that strong the players would be reluctant to trade it away. In that way, strong pieces can be self-balancing.
I could imagine it possibly being a problem if the Joker loses strength quickly so that there's a large advantage in deploying one's Joker first, which would naturally favor the first to move. If that is a problem, a way to counter it would be to carefully choose the moves of the other pieces. Perhaps have more sliding or other blockable moves instead of leaping moves, to allow for pawns to reveal attacks on the Joker by weaker pieces that could be exchanged for it. Another way is to make sure that pieces have simple moves so that a player would be likely to have good options that limit the Joker.
Given that the practice of "Left" and "Right" has a history in Shogi -- where simply "Left" and "Right" are used in all English translations of which I'm aware* -- I think I'll leave that much as it is.
On the same principle, since those names refer to position, I do think it'd be better to switch the two as far as their moves.
*Allowing that I've been at this for a relatively short time.
I have now updated Mobile Detect to 4.8.06. Since it works differently than the old version, mobile detection was a bit wonky until I got it working correctly.
Given that I usually call for "left" and "right" to be for placement, it may be better to reverse these moves. Opinions on that question are welcome.
My opinion is, don't leave it ambiguous! Even if you use it consistently it will be confusing. If the name refers to the location make it something like "Left Side Berolina Pawn" and if it refers to direction make it "Leftwards Berolina Pawn".
273. Left Berolina Pawn, and 274. Right Berolina Pawn. I had a kind of weird day yesterday; among other things, I hadn't selected a Piece of the Day for today, and as I was hunting around the best I could find was a two-piece pair. Since it was late in the day, I decided to just wait for morning and do them together.
While I was compiling the Icon Clearinghouse, I came across images for these two pieces, but without any clue as to how they were supposed to move. So, I made my guess: I simply turned the standard Berolina's movement 45 degrees.
That gives the Left Berolina Pawn a non-capturing move of 1 space orthogonally forward or to the right, with an optional 2-space move as an opening, and a capturing move of one space diagonally forward and to the right. (mfrWcfrFimfrnD)
And of course the Right Berolina Pawn does the same thing to the left. (mflWcflFimflnD)
As usual with such pieces, "left" and "right" refer to where the pieces should be placed in the lineup, not the direction in which they move.*
The models are just modified Berolina Pawns, with the head not represented by the name (right on the Left Berolina, and vice versa) replaced by a triangular block pointing forward.
*I'd originally done that the other way around, leading to the discussion in the next couple of replies.
That's now corrected.
I see
And maybe you’ll make text in brown dark mode if not whiter but bit brighter?
Yes, the saving worked, but when writing the form on mobile, it was using the wrong condition to add " SELECTED" to the darker option. That's now corrected.
Ah, forgot to say. Color scheme changes’ saving doesn’t work!
No, it works, but sets darker mode when turning to dark and vice-versa.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Most of the Movement/Promotion adjustments have been made. The only point I'm having trouble with is finding a way to extend the number of places for hands. I'd probably have to override the drop model, but I'm not sure I could do it quickly on my own. Anyway, for the time being, it's a good way to get familiar with the rules.
@Daniel: thanks. They are well done and they fit with the set. I hope editors will add them.
But with shuffle.
I have updated PHP to 8.1.28, and I will be going over the error logs for things I have to change to keep up with this new version. If anything stops working, let me know.
try now
For me, light brown text in brown Dark mode is significantly less readable.
That's going to vary with the device and the person. That's why there is now a third color scheme.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
For me, light brown text in brown Dark mode is significantly less readable. And comments’ text is still white and readable.
35 comments displayed
Permalink to the exact comments currently displayed.
Since this comment is for a page that has not been published yet, you must be signed in to read it.