hgm wrote:I guess I have too many obsolete pages on my website. The most recent sources are in my
on-line repository.
It's where google sent me.
The Falcon was a funny idea: it is basically a lame leaper, like the Xiangqi Horse or Elephant: unlike a Knight a Horse goes from b1 to c3 over b2, and cannot make the move when b2 is not empty. Although it can never go from b1 to b2 even if it is empty. The Falcon, however, is a multi-path lame leaper: it needs a clear path to its destination, but several paths lead to the same desitnation. With the Xiangqi Horse (Mao in Chinese) there exists an alternative (the 'Moa') that moves from b1 to c3 over c2, rather than b2, and a multi-path variant ('Moo') that could do both, and so only would be blocked when both b2 and c2 are occupied.
I actually have both the Mao and the Moa in my Xiangqi engine: one is used for move generation, one is used for check detection (basically, a Moa in the location of the king that can capture a Mao means the king is in check). The way I implemented this is to move as a wazir first and a ferz second for a Mao and the other way around for a Moa. In either case, I only accept squares that a knight could move to. This seemed the easiest way to do this in a bitboard engine. Sjaak has the same thing (but none of its current variants have lame leapers).
Maybe I can do something similar to make a Falcon. Maybe.
The Falcon has 3 paths to any destination: b1-b2-b3-c4 or b1-b2-c3-c4 or b1-c2-c3-c4 for a (1,3) move, and b1-c2-d3-d4 or b1-c2-c3-d4 or b1-b2-c3-d4 for a (2,3) move. So it is pretty adept as slithering through enemy lines. It needed some special code in Fairy-Max to implement it, and it would make a nightmare out of pin detection in egines smart enough to have that.
I can imagine.
In practice it is not a very exciting game, though. The Falcon is about as valuable as a Rook, perhaps slightly less. So it is not nearly so tactical as Capablanca variants.
Hmm... could still be interesting to look at. Is it me or does the guy who invented it seem a bit... odd?
As to Ouk: basically the initial moves are like double pawn pushes (without e.p. captures, like in Spartan Chess). In Fairy-Max I had to slightly adapt the code, because it assumed that such a special initial move of a royal piece would always be a castling,and would move the corner piece. So it now more generally separates initial moves with e.p. rights (under which the castling is grouped) from those without, not based on royalty but on the move-rights code, like it already did for Pawns.
Sjaak should be able to do that with little difficulty if I enable special moves for pieces other than pawns (castling is its own thing entirely). Do I remember correctly that you can't move the king as a knight after it has been checked? That'll be more tricky, since I don't have a rule to keep track of that. I could though, which if done right means I could also implement three-check. Maybe I'll add that to my ever-growing TODO list.
I've done some calibration of piece values for Capablanca, mainly the Archbishop. There seem to be a lot of very different values floating around the Internet (based on some dubious numerology), some as low as 6 or 7 pawns. The optimum for me seems to be about 8.25 though (+/- 0.10) so I'll stick with that.
I also wrote a nice pawn structure evaluation routine, but even with pawn hash it reduced the search depth by 1 or 2 ply, which meant it had to go. I've now pulled most of it into the evaluation in a way that's not nearly as expensive and it seems to help ok, although it's not calibrated yet. One of the neat things about not having passed pawn evaluation though was an end-game of KBNPPPPPK, where instead of queening a pawn Sjaak decided to drive the lone king to a corner and mate it with bishop and knight.
Having said that, I've also seen some horrendous games where the score suddenly jumps by over two pawns and then runs away, suggesting the engine just played a horrible blunder. I'll have to track those down.
