Ratings & Comments
I was thinking on having the try it section just before the notes section. But I see where you are coming from.
I think it is by far the best to use it as the main diagram in the setup section. That is where you would put a static diagram, and I don't see any reason to place it elsewhere just because it is interactive. Before the availability of Interactive Diagrams the 'gold standard' for articles here was to have an image of the setup accompanied with the names and coordinates of the pieces, either in list or paragraph form.
I see no reason for showing the initial position twice; that is just presenting redundant information.
IMO using a different section for playing is a bad thing; people visiting this website would expect they can play against the main diagram, as this is how most articles have it, and might not look further down if the main diagram is static.
BTW, it is pretty annoying that tables suddenly have a different background color than the page as a whole. It seems the standard style sheets are messed up.
I had though is better to show the user first the setup, then introduce them the rules, and then offer them the chance to play the games. But I 'll do it the way the people with more experience decide
It seems to me that capturing a protected lion by a lion is an available move as long as the diagram understands. Anyway I won't do it and I imagine the AI does not do it either.
I am working on making display of Lion trading restrictions possible in the diagram as a side project. I recently found a way to get the coordinates and pieces from the last move of a game, which will allow enforcement of the counter-strike rule. Still not sure how to do the bridge-capture rule though...
[Edit] Successfully implemented the counter-strike rule in my prototype.
The way I had in mind for indicating illegality of pseudo-legal moves in the NewClick highlighting routine was to make each move, and then generate all replies, and determine their scores. A king-capture score (15000) amongst these replies would mean the original move was illegal. This would then cause the grey cross to be used to highlight it.
Turns out my code was causing bugs with Gote's Whale highlights. So I removed the Anti-Lion-trading code and cleaned up extraneous code in my applet.
It would be nice if we could add a gray highlight for the illegal Lion trading moves for the Chu diagram on this page, but I am not sure how to go about doing that.
Not sure how that is possible since the diagram clearly defines the Tokin has having the p2 image instead of the p image.
Maybe refresh your browser cache?
I tried to load the Seireigi engine you put a link to, but I wasn't able to get it to work. It said it couldn't find the variants.ini file upon loading.
It would be nice if we could add a gray highlight for the illegal Lion trading moves for the Chu diagram on this page, but I am not sure how to go about doing that.
If it was easy I would already have done it...
The AI already pays attention to the Lion-capture rules and other legality issues, so the easiest way is to reuse the AI components. When using the NewClick() move entry routine the entered moves are already performed by the same routine NewMakeMove() as that the AI uses.
The AI uses a recursive routine Search(), which uses the move generator GenAll() to create a move list for the side that is on move. It then loops through the moves in that list to find the best/a satifactory one. To do that it first evaluates the direct gain of the move, through a routine ScoreMove(). This calculates the value of what the moves captures, checks if it destroys opponent or own royalty, and adds some info to the move that was not in the 'raw' moves coming from the move generator. (Such as identifying pieces that have to be burned, and remembering the original occupants of mutated squares, identifying the pieces that are made temporary royal or iron by the move and adapt the score for moves that capture those.) After 'cooking' the move with ScoreMove() it can be applied to the current position by NewMakeMove(), and later taken back with UnMake();
Both GenAll() and ScoreMove() make use of the preceding ply, e.g. to generate e.p. captures, and applying trading restrictions.
Currently NewClick() uses GenAll() to create the list of pseudo-legal moves, and then uses mouse clicks to eliminate those from the list that would not be indicated by those, until a single move is left. This raw move is then cooked by ScoreMove(), and performed by NewMakeMove(). As long as there are still multiple moves in the list, the squares corresponding to the next click these need to be selected will be highlighted.
To do fully legal highlighting we would have to make every move, and then judge the position based on the possible replies in the resulting position. Not just the one that is finally selected. That means that ScoreMove() will have to be applied to each of the moves. So the call to it should be moved to within the loop that selects the moves to be highlighted. And then there should be a NewMakeMove(), GenAll(), {judge}, UnMake() sequence in that loop as well, where the 'judge' part would apply ScoreMove() to all replies, to see if there is an instant win amongst those (which then would make the move to be highlighted illegal). If there is the grey cross should be chosen as highlight marker.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Yeah...I think it's better to just leave it as-is, except maybe passing the full move to the AI, rather than just the origin and destination...but that's a topic for another day.
I think I managed it! There were all kinds of problems, because ScoreMove() only work if the AI tables (such as piece values) are initialized. Which only happened when you actually started playing against it. Otherwise it returns undefined results when pieces get captured. And it was not only that the tables needed to be defined; they actually had to contain the correct values. Otherwise the bridge-capture rule could not be correctly applied.
But I think it works now: pseudo-legal moves that the AI would consider illegal are now highlighted with a grey cross. This applies to intrinsically illegal moves (blowing up your own royal, capturing an iron piece or making a counter-strike) as well as to moves that can be punished in the reply (exposing your royal to capture, or capturing a protected Lion).
In the Chu-Shogi Diagram there are no restrictions on royal exposure, as it specifies royal=100, but as far as I tested the Lion-capture rules are now correctly indicated with the highlights.
Note that you declared the Pawn royal in your Diagram. (Holes are not counted; they do not appear in the table.)
You got most of it. However, I did find a few bugs involving the counterStrike highlights.
In this game, after the Soaring Eagle takes the Queen and then the Lion, the gray highlights are not displayed at all (General Case: double capture that captures non-Lion piece and then Lion):
1. e5 h8 2. De4 Dh9 3. Df5 Dg8 4. Dxf9+ Dxg4+ 5. +De8 +Dh5 6. Qg4 Qf9 7. +Dxf9xg10
In this game, the counter-strike highlight doesn't happen for all the Lions, but only for the piece type that was just captured:
1. f5 g8 2. Of4 Og9 3. Of6 Og7 4. Of8 Og5 5. Og9+ Of4+ 6. Ng5 Nf8 7. Ng7 Nf6 8. Qxf4 or fxf5
In this game, the counter-strike highlight highlights don't show at all for piece that have the option of proomoting after capturing a Lion:
1. f5 g8 2. Of4 Og9 3. Of6 Og7 4. Of8 Og5 5. Ne5 Nh8 6. Og9 Of4 7. j5 c8 8. Hk5 Hb8 9. h5 e8 10. Dh4 De9 11. Dg5 Df8 12. Dh6 De7 13. Di6 Dd7 14. Dxi8 Dxd5 15. Dxi9 Dxd4 16. Hxh8
Otherwise, thank you so much! This saved me a heck of a lot of time.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Thanks for the heads up!
Ummm... I intentionally implemented the counterStrike ban to declare a particular type 'temporary iron', rather than just any type that has the counterStrike property. This to allow multiple types to have it. This appears to backfire in case Ln and +Kn are defined as different types. The other cases I will examine tomorrow.
We should see here what the AI does, so we are now debugging the AI...
I hope there are no errors in the piece movement.
Edit: They're now centered properly, Fuddyduddy image is now used instead of Dumbo
It mostly looks good, but there are a few issues. The pieces are not centered properly, the board is tiled a bit, and you're using the Dumbo image instead of the Fuddy-Duddy image. Also, I'm wondering if there is a way to not have the whole space highlighted when I click on a piece.
There are several ways to cure this. The simplest would be to switch to making all types with the counterStrike property temporary iron after one of those is captured by a piece without this property. A more subtle (and more versatile) approach would be to assign piece types to 'groups', and make all types in the group that was captured temporary iron. This could be done by introducing a parameter group=N, which would then put pieces of that type in group N. (With as default every type being in a group of its own, so that in Chu Shogi only the +Kn would have to be assigned the type number of the Lion.)
I could also use the counterStrike parameter itself for this, giving it a different meaning when used after pieces have been defined: currently counterStrike=N would endow type N with the property, but after a piece definition it could assign the preceding type to group N. This method is already used for antiTrade (which defines relative ironhood), so it might be the best solution.
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.
25 comments displayed
Permalink to the exact comments currently displayed.
I see the point. The diagrams' four functions--setup diagram, individual piece movement displays, move pieces around, and play against AI--each naturally fit into different sections. But breaking it apart into those would be worse. So then do you replace a static diagram at the start of the article, or add the new one later? I don't think it matters too much, but saving some space by replacing the setup diagram is nice, and giving the interactive tool near the beginning of the article is more engaging.