It's like the old ChessV in that regard although I could also provide a separate exe for WB operation. The components aren't as tightly integrated as in old ChessV. I wouldn't expect a lot of interest in this, though. The AI isn't really all that remarkable. The GUI is the really impressive piece. I still want to make a new WB engine to go along with it. That project has been started, but I haven't gotten all that far. GUI work is never-ending, and there are others who are better at writing engines than I am. I'd imagine there is more interest in new GUI features like hexagonal boards, for example.hgm wrote:Is the AI also a WB v2 engine, or is it built in like in the old ChessV?
Oh, I should also give a shout-out to Ilari Pihlajisto and Arto Jonsson. All the code related to controlling the external engines is from Cutechess CLI, which I ported to C#.
Sure. The architecture is very flexible. Rules are all coded as separate objects that are plugged in to games so there are practically no limits to what rules a game can have. There are no arbitrary restrictions like only one promotable piece type because nothing related to promotion, for example, is "baked in". Of course, the trade-off for all this flexibility is reduced performance. There is a hard limit on board size though, which is 16 x 16. The largest games currently implemented are 12 x 12.hgm wrote:I see you support multiple moves per turn. Can this also be controlled on a per-piece basis, so that you could handle the Chu-Shogi Lion?
If so, can you handle Chu Shogi, or does that fall outside the parameter limits for board size and/or number of piece types? (And can you handle promotion of more than one piece type in the first place?)
I don't think I'd do the lion the same way I do Marseillais Chess though, although it could be done that way. For the double-move variants, the moves for each leg are generated independently. Basically, there's a hook that's triggered whenever it is time to update the current side to move so that games can change the turn order. When the engine has stopped thinking and it is time to make its move, it scoops up all the moves from the top of the PV for the current side and plays them. To do the lion I don't think I will mess with the turn order. I'll generate each of the lion's movement options as a single unit. The big question will be how that ties into the user-interface... The easy way would be to have the user move the lion directly to its final square. The user would then be prompted with a pop-up asking which extra piece to capture (if any.) The code to do this is already there. It's used by the forest ox in Odin's Rune Chess. It would be more intuitive, though, to let the user move the lion in steps but I'm not sure how I'd make that work. How does it work in Winboard?
Oh, I don't think I've seen Mighty-Lion. I saw Elven Chess and tried to get a game going on Game Courier but no one accepted the invitation. It looks like a good game. Anyway, once the lion is implemented these should be no problem.hgm wrote:If Chu Shogi is too big, Mighty-Lion Chess and Elven Chess should be no problem, size-wise (if a Lion works). These also have no piece promotions.
I do want to support Tenjiku some day, but there's probably about a million things to come first. Congrats on writing a Tenjiku program by the way! That is a bold undertaking! It was actually when a friend showed me about Tenjiku Shogi that I first became interested in chess variants. Before that I wasn't really aware of variants at all, except for Dragon Chess which I had read about in Dragon magazine as a kid.hgm wrote:(I don't dare to ask about Tenjiku Shogi)
Ok, this shouldn't be that bad. I just need to take the time to do it. I'm more worried about the repetition rules in Xiangqi. I remember a thread you started on here a few years ago hammering it all out. I don't remember any of the details, just that the conversation went on seemingly forever because the rules were so complex and so tricky to get right.hgm wrote:Makruk counting rules should not be so difficult to implement when you implement the reversible-ply counter as a count-down. Then you can always declare draw when it reaches 0. Just when you reset it on a capture you would not always reset it to 100, like in Chess, but to a number that depends on the material present. (And then only if that makes it lower than the value it already has.)
