Getting ready for Thermopylae

[Daniel Shawul]

What I do is this: I always extend all checks by one ply. A side is considered to be in check iff all of its royal pieces are under attack. That seemed to be the easiest way to implement the Spartan rules and it seems to work well in practice. One of the side attacks is that attacks on a Spartan king are treated like any other type of attack.

Indeed that seems reasonable. I can imagine it would be really detrimental if I did
full ply extensions for every check on one king. I have ofcourse an all_kings_attacked
function that I use for move legality testing. But somehow I thought all checks should be
extended and wrote an is_king_attacked function just for that purpose. The fact that I was
not extending full plies might have helped but this sounds like one thing to remove after testing.

The only deviation from this is in SEE, where I always sort the royal piece to the end of the list, which may not be correct for the Spartans but makes the code simpler. I don't think it makes a big difference in practice.

I use MVV instead of SEE, as I wanted to have something that works for all alien games f.i checkers.
Before that I had big tree explosions but I think difference between MVV and SEE is not much.
SEE is an in accurate localized queiscence search that should be very fast to compute.

Anyway this two kings also mess up eval. For example how to evaluate king safety for spartans,
king-pawn endgames etc.. Also all of them change when there is only one spartan king.
A similar situation I found is in Jetan (martian chess) is that to win the game you have to either mate
the queen, or capture the king with your king. If you catpure the king with any other piece it is a draw!
This later rule made the game very drawish and they modified the capture to be considred like any other.
This was "chessic" modification only this time you would have to mate the queen instead of the king.
It was considered an improvement but IMO lost the essence of the game in some way.
Admittedly it is a good modification as I never saw a win in jetan in my self-play games with that rule on.

[Evert]

I use MVV instead of SEE, as I wanted to have something that works for all alien games f.i checkers.
Before that I had big tree explosions but I think difference between MVV and SEE is not much.
SEE is an in accurate localized queiscence search that should be very fast to compute.

Should do more-or-less the same thing.

Anyway this two kings also mess up eval. For example how to evaluate king safety for spartans,
king-pawn endgames etc.. Also all of them change when there is only one spartan king.

I don't do king safety at all if there's more than one king. On the contrary, I try to encourage the kings to aid in the attack. Without this I noticed too many games where the Spartans were efefctively playing with a piece down because their kings didn't participate.
Probably means the evaluation takes a big dive if one of the kings does get captured though, which might be more likely if they're out in the open. Possibly the correct thing to do is to keep one of them safe and let the other one attack, then use the best safety evaluation as the king safety score and the mobility/centralisation score for the other king. That's a bit harder to code though.

[Daniel Shawul]

I guess that is one strategy that could work. Another would be to use the check immunity effectively, which prevents f.i simple forks of a king and another piece especially with the long-rangers of Spartans that could be significant advantage. So I guess pick one strategy and pursue it.

Another difficulty I encountered is passed pawn & hoplite eval. The hoplite movement make things difficult. They move diagonally and you can't tell if a pawn is passed or not at least not that easily. Same goes also for passed hoplites. What I did is to just stick with absolute passed pawns on the 7th rank , and also generating promotions to queens , warlords & general in quiescence search as well. Once I added that strategy, it started playing good passed pawn moves. Before that, the eval was composed of only piece square table for centralization of all pieces and pawns.

[hgm]

I use the same scheme as Evert. InCheck (conttrolling the Check extensionand staleate test) is set only if all Kings are under attack. I have no terms in my eval for one King of a pair being under attack. As a naive value of the spare King (as used by Fairy-Max) is below Rook, and my eval also does not contain bonus terms for keeping Rooks under attack, that seemed natural.

I could imagine, though, that an extension for actually capturing a King might be of some use. But I did not try it.

Spartacus also does not have any real King Safety yet. (In normal Chess it just tries to freeze the King on c1/g1, and the a/b/c or f/g/h Pawns on 2nd rank, through the piece-square tables). Once I will get to implementing King Safety, I will do it like this:

* There will be a term evaluating King Safety in a standard way, used when there is a single King (KS).
* With two Kings, this term will be calculated for each of them, and the largest one will be counted.
* Each King will alse be avaluated as if it were a normal piece (i.e. as it usually is in the end-game, trying to centralize, PST).
* I will then calculate both T1=KS(1)+PST(2) and T2=KS(2)+PST(1), where 1 and 2 indicate the Kings.
* For the total evaluation I will use something like max(T1,T2)+f*min(T1,T2), with f<1.

So the fact that you keep open the option to make the Kings change role is worth something (which should explain the difference between the empirically determined naive value of a spare King and a non-royal 'Commoner', which moves as King). This is actually similar to the way I would evaluate castling rights, when you have both.


Spartacus also doesn't use SEE; deep SEEs are rare and not very reliable anyway. It uses MVV, but before searching the move tests if the victim is protected. HxL captures of a protected piece are then postposed to after all other captures, or, if it is 'truly bad', meaning that the value of protector and victim together aren't enough to earn back the capturer, (i.e. a guaranteed negative SEE) even after the non-captures (and also treated as non-captures, i.e. not exempt from reduction, and not searched in QS).

[Evert]

Another difficulty I encountered is passed pawn & hoplite eval. The hoplite movement make things difficult. They move diagonally and you can't tell if a pawn is passed or not at least not that easily. Same goes also for passed hoplites. What I did is to just stick with absolute passed pawns on the 7th rank , and also generating promotions to queens , warlords & general in quiescence search as well. Once I added that strategy, it started playing good passed pawn moves. Before that, the eval was composed of only piece square table for centralization of all pieces and pawns.

That's another difficult one. I give major bonuses when pawns (or hoplites) are getting close to their "promotion zone" (back rank) and an extra bonus if one of their moves (in the mobility evaluation) takes them into that zone. This is better than nothing, but still not great.
I've worked out a scheme to test whether a pawn (or hoplite) is passed, in the sense that it has a free path to its promotion zone. The problem is that I can see this would be quite expensive. Perhaps it wouldn't be so bad if I only did it for pawns on the sixth or fifth rank that can advance to the next rank.

One of the difficulties is that Sjaak doesn't know what a pawn (or a king, or a rook, or anything else) is. All it has is a list of piece types with certain properties, and the evaluation terms are based on that using some simple heuristics. This keeps things general and flexible, but it makes formulating an evaluation function more difficult.

[Richard Allbert]

I need to add a hash Table to Catalyst, and some king of evaluation... how long do I have before the tourney starts?

[Evert]

Spartacus also does not have any real King Safety yet. (In normal Chess it just tries to freeze the King on c1/g1, and the a/b/c or f/g/h Pawns on 2nd rank, through the piece-square tables).

I use a modified version of the king safety algorithm described by Ed Schroeder. The main difference is I use the number of attackers on the "king zone" rather than the attack pattern (because Sjaak doesn't know what a "queen" or a "knight" is, and because that doesn't generalise well anyway).

* There will be a term evaluating King Safety in a standard way, used when there is a single King (KS).
* With two Kings, this term will be calculated for each of them, and the largest one will be counted.
* Each King will alse be avaluated as if it were a normal piece (i.e. as it usually is in the end-game, trying to centralize, PST).
* I will then calculate both T1=KS(1)+PST(2) and T2=KS(2)+PST(1), where 1 and 2 indicate the Kings.
* For the total evaluation I will use something like max(T1,T2)+f*min(T1,T2), with f<1.

That's similar to how I would do it as well (not identical though).

So the fact that you keep open the option to make the Kings change role is worth something (which should explain the difference between the empirically determined naive value of a spare King and a non-royal 'Commoner', which moves as King). This is actually similar to the way I would evaluate castling rights, when you have both.

Castling rights is always another headache for me. No matter how I deal with them, it always feels a bit like a hack (not as bad of a hack as en-passant captures though, which always feel like an ugly addon to an otherwise clean move generator). What I currently do is check whether castling rights have changed since the root of the tree and give a penalty for a) having lost castling rights and b) not having castled. It doesn't distinguish between castling types though, but since the evaluation encourages the engine to castle as quickly as possible that's not such a big issue. I should switch off the pawn shield evaluation after a side has castled, however: the king safety will take care of it from then on anyway and it means we can advance the pawns on the other side of the board.

Spartacus also doesn't use SEE; deep SEEs are rare and not very reliable anyway. It uses MVV, but before searching the move tests if the victim is protected. HxL captures of a protected piece are then postposed to after all other captures, or, if it is 'truly bad', meaning that the value of protector and victim together aren't enough to earn back the capturer, (i.e. a guaranteed negative SEE) even after the non-captures (and also treated as non-captures, i.e. not exempt from reduction, and not searched in QS).

I never tested to what extent it helps or not. For move ordering it may not make much of a difference, as you say. In Q-search I also prune captures with a negative SEE, which seems to speed things up without making things too inaccurate (in normal chess anyway).

In other news, the version of Sjaak I sent to you earlier may be fine. I still haven't found the problem, but testing older revisions shows that the problems I have now have been introduced either shortly before or after the revision I sent you. I'll test that exact version and let you know.

[hgm]

I think it would be justified to grant a special status to Pawns / Hoplites. (you know, 'soul of the game' and that). They are relly not normal pieces:

1) Their moves are irreversible
2) They are tactically inept
3) They promote to a piece strong enough to decide the game

Most Chess variants do have a piece type with those properties. (And then usually a lot of them, making it all the more important to handle them properly.)

In Spartacus I do use a Pawn hash table. So it is not really that important how expensive it is to identify passers. I think I do have a reasonably efficient algorithm for determining which Pawns can no longer be blocked by Hoplites. (Though not as efficient as for determining normal passers.) Currently I don't try to determine passed Hoplites. The idea was that Hoplites are so mobile they can usually slip through. The blocking of their path is not nearly such a permanent feature as in normal Chess. I do grant significant bonuses for Pawns that attack Hoplites (and thus block one of their moves).

From watching games, I got the impression that it can be very important if the Hoplite is on the same or different color than an enemy Bishop. The 'good Bishop' vs 'bad Bishop' disticntion could be way more important here than in Normal Chess (but is not in my evaluation...).

[hgm]

Castling rights is always another headache for me. No matter how I deal with them, it always feels a bit like a hack

I think the proper way to do it is to evaluate the castling right as an anticipation to the King Safety you would have in the castled position. You have to discount it a little, of course, to encourage the engine to actually do it, in stead of remaining happy with the rights. To make for smooth castling at low depth, it would be best to discount in proportion to the number of pieces that still block it.

So you can evaluate each right as 0.8, 0.6 or 0.4 times the virtual King Safety on g1/g8, and something similar for Q-side. And then take the maximum of the two, because you eventually will be able to only do one. Or add 0.25 times the minimu, so that when it is also good, you will have some extra bonus for having the choice (as a kind of mobility argument). This could lead to it valuing the choice more than the best actual castling, and thus postponing castling. But I guess that would be justified, if you don't overdo it.

[Evert]

I think it would be justified to grant a special status to Pawns / Hoplites. (you know, 'soul of the game' and that). They are relly not normal pieces:

1) Their moves are irreversible
2) They are tactically inept
3) They promote to a piece strong enough to decide the game

Most Chess variants do have a piece type with those properties. (And then usually a lot of them, making it all the more important to handle them properly.)

You may be right.
At the moment I do have special evaluation terms for pieces that can promote and pieces that have irreversible moves, but no term for the equivalent of "pawn structure". A few generalised terms that I've come up with that I'd like to include with some weight is "pawns on same diagonal" (a pawn chain in normal chess, the analogue of a doubled pawn for Hoplites, although not as severe), "pawns on the same file" (doubled pawns, a phalanx of hoplites) and "can defend or be defended by an own pawn, possibly after advancing" (connected pawns). Along with identifying passers, this should cover the most important things.

In Burmese Chess, pawns optionally promote when they reach the long diagonal on the opponent's side of the board. They promote to Ferz though, and only if the original one was taken. I can probably handle that by downscaling the promotion bonus (at the moment I disallow promotions entirely because I don't have optional promotions or a maximum piece count except for kings).

In Spartacus I do use a Pawn hash table. So it is not really that important how expensive it is to identify passers.

That's a good point. I haven't ported that over, but I probably should.

I think I do have a reasonably efficient algorithm for determining which Pawns can no longer be blocked by Hoplites. (Though not as efficient as for determining normal passers.)

Do you distinguish between pawns that cannot be blocked at all and pawns that are not currently blocked?
By the way, I do like the fact that pawns and hoplites can actually block eachother dynamically.

Currently I don't try to determine passed Hoplites. The idea was that Hoplites are so mobile they can usually slip through. The blocking of their path is not nearly such a permanent feature as in normal Chess.

Could well be true.

I do grant significant bonuses for Pawns that attack Hoplites (and thus block one of their moves).

I have a term for pawn and hoplite mobility, they get a penalty for being blocked. By the way, do you have a sense for how much weaker a rook or knight hoplite is than a centre hoplite? The difference with normal pawns is that normal pawns have fewer attacks but the same number of moves, whereas hoplites have the same number of attacks but fewer moves. It's also easier to centralise a hoplite that is on the edge (easier, in fact, than for a hoplite that starts out on the central files).

From watching games, I got the impression that it can be very important if the Hoplite is on the same or different color than an enemy Bishop. The 'good Bishop' vs 'bad Bishop' disticntion could be way more important here than in Normal Chess (but is not in my evaluation...).

I have plans to include a general "colour weakness" term, but I haven't settled on how to formulate that yet. The idea behind this was more to replace the "pair bonus" for colour bound pieces (which I currently also award for Spartan Lieutenants that are on different colours), but it should cover some pawn structure and good/bad bishop themes as well.

Nice to see how everyone has different ideas, by the way!