The Peace-Chess Challenge

[hgm]

Thanks for the engine, it was a great fun to play with it! Probably there is no need even to change the rules.
There is a bug: the engine got into a perpetual cycle when tried to play a move. Its rook and queen were exchanging places forever (both of them hugging some other pieces).

Ah yes, I also saw that happen once. There is no repetition detection yet. Forbidding repetitons within a chain should in any case prevent this goig on indefinitely.

There is a real problem here, when the relay plies are not always extended a full ply (like captures in QS of a normal engine). Because then it can use needlessly long release chains to eat up the depth, pushing trouble over the horizon.

What I do now is score chains that do not complete before the horizon (or run into a dead end) as worse than checkmated. But then it just gets out of the chain in a leaf node, with no reply for the opponent left.

Another problem is that it considers different ply in a release chain as different turns, thinking about them separately. So if it originally planned a chain of 9 ply, (because longer would hit the horizon and be ifinitely punished scorewise) the first move of it is played, and then it thinks again, and can now see deeper,, so it adds a 10th ply. Etc. Perhaps I should reduce the search depth for each subsequent release ply. Then it will be reduced to a 1-ply search after a finite number of them, and then it would be forced to leave the chain.

[hgm]

I have achieved some new insights, which I want to share here:

The paired pieces can only move to empty squares as a pair, which make them look less valuable, as they cannot check the King. This is deceptive, though. Pairs in the set can be connected through 'virtual captures', i.e. moves that would have been pseudo-legal captures on another pair if they had not been paired. Such moves could be used as parto f a release chain.

If on average each piece in the set of paired pieces ('the cloud') has more than one virtual capture, the cloud becomes 'super-critical'. The number of possible release chains then on average grows exponentially with the length of the chains. As the number of pairs is only finite, this basically means you can juggle the pieces in the cloud around at will. The 'conveyor belt' of mutually attacking paired Rooks was an example where each piece had one virtual capture, which is at the edge of criticality. This means you won't expect the number of chains to explode, but you do expect an unbranched infinitely long chain. Yet it was already possible to make the Queen, which entered this 'mini-cloud' at one site, come out at another.

Piece pairs in a super-critical cloud can be extremely dangerous, because no matter what piece is in there, any piece already in or entering the cloud could use it as an exit point. It is like any of the pairs could be an Amazon. That is much more dangerous as even an unpaired Queen!

Of course the number of pairs is the same for both players. But the power of the pieces they have in the cloud can be different, and the cloud becomes super-critical the earliest for the player that has the stronger pieces in it.

Of course it also matters how the pieces are positioned, and whether they catch each other's virtual attacks efficiently. The opponent will try to break these connecting links by moving pairs away. But if there are enough paired pieces, it becomes unlikely that this is possible. Cram enough pairs in the easily accessible area between the Pawn ranks, and it becomes impossible to position them such that they won't attack each other on average more than one time, even if you would be allowed to move them all. Of course you can attempt to keep the cloud away from your King, and this can be an important strategic goal. But when the opponent pairs with the Pawns in front of your King, you cannot move these away very effectively. (E.g. Rooks getting out of the pair in front of your King could still hit the King, no matter how far away you move them, unless you also interpose something. And it would also take an extra move to first replace the Pawn in the pair by a more mobile piece to move the pair away. So the opponent might be able to create pairs near you King faster than you can move them away.

[Sven]

Thanks for the engine, it was a great fun to play with it! Probably there is no need even to change the rules.
There is a bug: the engine got into a perpetual cycle when tried to play a move. Its rook and queen were exchanging places forever (both of them hugging some other pieces).

Ah yes, I also saw that happen once. There is no repetition detection yet. Forbidding repetitons within a chain should in any case prevent this goig on indefinitely.

There is a real problem here, when the relay plies are not always extended a full ply (like captures in QS of a normal engine). Because then it can use needlessly long release chains to eat up the depth, pushing trouble over the horizon.

What I do now is score chains that do not complete before the horizon (or run into a dead end) as worse than checkmated. But then it just gets out of the chain in a leaf node, with no reply for the opponent left.

Another problem is that it considers different ply in a release chain as different turns, thinking about them separately. So if it originally planned a chain of 9 ply, (because longer would hit the horizon and be ifinitely punished scorewise) the first move of it is played, and then it thinks again, and can now see deeper,, so it adds a 10th ply. Etc. Perhaps I should reduce the search depth for each subsequent release ply. Then it will be reduced to a 1-ply search after a finite number of them, and then it would be forced to leave the chain.

I would handle each release chain as one single move = one ply, not N plies (if N is the chain length). That should avoid a lot of trouble. It will certainly lower the possible search depth in a given amount of time but it also allows to write a clean negamax search.

[hgm]

I am not saying this is a bad idea, or that my solution was not 'quick and dirty' to be able to base it on a micro-Max-like code. But there are some problems with your proposal, which make it far from trivial:

Without repetition detection, release chains can be infinitely long, and there would be infinitely many of them. With repetition detection that would no longer be true, and many of the remaining chains would run into transpositions. (Which would only help if you hash intermediate states in some sort of release-chain TT for the chain you are currently working on, so that you could cut off chain elongation after reaching an intermediate position that already occurred in a chain you generated before.)

But even with that, the number of reachable permutations within the set of pairs could be huge. Suppose you have 7 pairs into which one new piece enters, together containing Q, 2xR, B, 2xN, 2xP. If they are tightly connected by virtual captures you might be able to completely re-order them in a single chain into any of the 8!/(2!*2!*2!) permutations. And each permutation, after being reached, could make the piece that finally emerges appear in 7 different places, from each of which it would have several moves. And that again would have to be multiplied by the number of different pieces that could have entered in any of the pairs. That makes an incredible number of essentially different chains. And the number of pairs can run up to 14... (At 15 the game becomes an 'insufficient-material' draw.)

And how would I determine which of the permutations are reachable and which not? One obvious way would be to use a tree search of valid releases, with a transposition table to prevent duplicate work. So I would have to do a tree walk (a sort of one-sided release perft) in the move generator.

During the opening and early middle game there will not be enough pairs to get a critical density. But as the game progresses, generating all release chains will take more and more work. The normal search will sometimes hit positions through moving the pairs where the pairs get very well 'connected', and finishing generation of all complete release chains in that single position might not be possible in the available time. By iterative deepening on the length of the chains you would at least get the simple ones quickly, and can abort the job when you run out of time.

[Sven]

I am not saying this is a bad idea, or that my solution was not 'quick and dirty' to be able to base it on a micro-Max-like code. But there are some problems with your proposal, which make it far from trivial:

Agreed - following my proposal is certainly not trivial. But I think it should be the right direction, since otherwise you might run into other problems, like not seeing a mate in 1 that would be possible with a very long release chain. Also I do not understand how you generate "incomplete chains": what do you do with the last piece being released when reaching the horizon (minus one ply)? You certainly do not remove it from the board, so the only way would be to generate normal moves for it and ignore any of its further chain moves.

Without repetition detection, release chains can be infinitely long, and there would be infinitely many of them. With repetition detection that would no longer be true, and many of the remaining chains would run into transpositions. (Which would only help if you hash intermediate states in some sort of release-chain TT for the chain you are currently working on, so that you could cut off chain elongation after reaching an intermediate position that already occurred in a chain you generated before.)

Such a release-chain TT would not be too complicated, and I think it can be quite small. You only need to keep track of friendly non-pawn, non-king pieces that are either part of a pair in the beginning or that start the chain (as a single piece). That would usually be up to 7 pieces, or at most 15, depending on the number of promoted pawns so far. Releasing a pawn makes the former part of the chain non-repeatable.

But even with that, the number of reachable permutations within the set of pairs could be huge.

Of course, in some single rare cases, but I think not on average. Note, for instance, that the presence of pawns within a chain cuts down the number of reachable permutations since pawns only move forward. And only connecting many non-pawns in a way that would allow many permutations will not be easy, so I think in practice "move generator explosions" should be very rare.

And how would I determine which of the permutations are reachable and which not? One obvious way would be to use a tree search of valid releases, with a transposition table to prevent duplicate work. So I would have to do a tree walk (a sort of one-sided release perft) in the move generator.

To slightly reduce the size of that tree you could determine paired but immobile friendly pieces which cannot participate in a chain. That way also other pieces could become "immobile" in a sense that their only pseudo-legal moves would be those that (try to) release an immobile piece. Unfortunately each step of a chain can change the information about which pieces are immobile.

During the opening and early middle game there will not be enough pairs to get a critical density. But as the game progresses, generating all release chains will take more and more work. The normal search will sometimes hit positions through moving the pairs where the pairs get very well 'connected', and finishing generation of all complete release chains in that single position might not be possible in the available time. By iterative deepening on the length of the chains you would at least get the simple ones quickly, and can abort the job when you run out of time.

You may be right. Nevertheless, If I had enough time for such a project I would definitely give it a try because only generating complete release chains sounds straightforward and clean to me.

[hgm]

You may be right. Nevertheless, If I had enough time for such a project I would definitely give it a try because only generating complete release chains sounds straightforward and clean to me.

To start with this last remark: I think we have to distinguish search strategy and implementation. When we agree that release chains should be generated in a perft-like manner, hashing transpositions and detecting repetitions in the process, it becomes so much like normal search that in my minimalist implementation I can use the same function for both, by giving it an extra parameter that restricts the move generation to just one piece (the released one), and doesn't flip side-to-move and eval signs. But that is only an implementation matter. I still can force search of all possible release chains in that implementation, by extending every release move one full ply. Like conventional QS extends all good captures one full ply. So the discussion is really about how much rlease moves should be extended, a full ply or just some fraction of it. Currently I extend 0.75 ply, which protects me from search explosion even without repetition detection, but does cause some undesirable other effects. In a somewhat more advanced engine you could make this dependent on whether it is theoretically possible that a released piece could capture the King (i.e. 'Amazon contact' between the enemy King and a paired piece, and a piece in 'the cloud' that could make that move). You could extend more aggressively whe thi sis the case.

Agreed - following my proposal is certainly not trivial. But I think it should be the right direction, since otherwise you might run into other problems, like not seeing a mate in 1 that would be possible with a very long release chain.

Very true; my engine can currently overlook mate in 1 turn, because the required release chain is too long and exteds beyond the horizon. But so what? If to find that 'mate in 1' by perfting a release tree that is larger that the alpha-beta tree of ordinary moves to find a mate in 4... Why would I then rather see the mate in 1 than the mate in 4? You want to maximize the chances to see any mate, and hunting for those that require very much effort to find before searching for those that could be easy to find doesn't seem a good way to achieve that goal. I realize that mates in the minimax tree are less likely, because the opponent tries to resist them, while in the perft tree it is like searching for help mate. So probably it does help to make the perft tree larger than the minimax tree.

Also I do not understand how you generate "incomplete chains": what do you do with the last piece being released when reaching the horizon (minus one ply)? You certainly do not remove it from the board, so the only way would be to generate normal moves for it and ignore any of its further chain moves.

At remaining depth = 0 I only consider stand pat and King hugging. I set currentEval = -INF for a release node, to suppress stand pat and delayed-loss bonus. So if a release chain uses up the last quarter ply of the depth budget, and cannot capture the King from that point with the released piece, it will score -INF, so it would be preferred to finish the chain on the last ply before the horizon, by playing to an empty square or hugging a lone opponent. So effectively I do not generate incomplete chains, but just refrain from generating chains above a certain length. Which then grows longer on iterative deepening. You could also see that as pruning too long chains near the horizon, and doing iterative widening.

Such a release-chain TT would not be too complicated, and I think it can be quite small. You only need to keep track of friendly non-pawn, non-king pieces that are either part of a pair in the beginning or that start the chain (as a single piece). That would usually be up to 7 pieces, or at most 15, depending on the number of promoted pawns so far. Releasing a pawn makes the former part of the chain non-repeatable.

Well, for detecting repeats the table could be cleared after a Pawn move, but for detecting transpositions you would have to keep everything, because getting to a transposition involves UnMake(). But even then, the number of permutations of 7 pieces can be huge. Look at the following example:
[d]6Q1/8/5B2/3N4/4BR2/2N4k/3P4/8 w - - 0 1
Only the Queen is supposed to be free here; the other white pieces are all paired. Note that Qg3 is checkmate, as the King cannot hug, and cannot escape from being hugged by the Queen. But that is 'hug-in-3' in terms of minimax turns.

Now look what release chains can do. First note that the Knights and Bishops form a 'release cycle': They can alterate BxN, NxB, and after 4 releases get the 'release square' back to where it started. This would 're-activate' the piece that activated them. So after Qxd5-(f6-c3-e4-d5) the Queen is released again (the cycle indicated by parentheses). So the Queen can use d5 as a 'relay point', essentially making two moves. But the pattern of the N & B will have rotated 180 degrees by this, which does not affect their ability to do this. So the Queen can use her second move to step into the cycle at another point, Qxe4-(c3-f6-d5-e4), and the Queen is again activated for a 3rd step. It cannot only emerge from d5, but also from e4! But it doesn't stop there: continue with Qxf4 to release the Rook there, Now the Rook can step into the cycle: Rxf6-(c3-e4-d5-f6), and is re-activated, to go back to f4, activating the Queen for a 4th step. The Queen can also emerge from f6! But it can also countinue the free ride by Qxf6-(d5-e4-c3-f6), then Qxc3-(e4-d5-f6-c3) and finally Qxh3#. A release chain of 26 steps hits the King. There is no other path from Q to K over 'pair squares' than g8-d5-e4-f4-f6-c3-h3, and each step along this path (except the last) takes 4 steps for re-activation.

But now suppose there was a Pawn on d3, blocking the Queens only path to it. We already established a Queen could emerge from any of the pair squares, and certainly a Knight can easily emerge from any of the squares on the B-N cycle. But how about f4? This is a Knight-jump away from the cycle where the Knights are, so there is hope. So start with Qxd5-(...)-e4-(...)-f4, where '...' indicates the B-N cycle (11 steps so far). From there continue with Rxf6 (after two cycles there is again a Bishop there) Bxc3, Nxd5, Nxf4, Qxf6, Rxf4, Nxh3# (18 steps)! This was actually faster than manoeuvring the Queen to c3, and thus could be preferred even without the Pawn.

It seems highly unreasonable to me to require that it should discover these release chains before the simple hug-in-3, just because formally they are hugs-in-1...

(more later).

[hgm]

Of course, in some single rare cases, but I think not on average. Note, for instance, that the presence of pawns within a chain cuts down the number of reachable permutations since pawns only move forward.

This is an important insight, and suggests that it is good to have paired pieces, but bad to have paired Pawns. This can be easily accounted for in the incremental (PST) evaluation: a Pawn in a pair should get a penalty.

And only connecting many non-pawns in a way that would allow many permutations will not be easy, so I think in practice "move generator explosions" should be very rare.

But when it occurs the engine could hang. So 'very rare' isn't really good enough. It is somewhat like mutual perpetual check, which is possible in Nightrider Chess. With check extension this causes infinite recursion, crashing Fairy-Max. It is rare, but not so rare that it would not crash about every other game.

Aother thing that occurred to me: as soon as you have one release chain that causes a beta cutoff, generating any others is a waste of time. If generating the long chains is more work than searching a short one, you would really waste an enormous amount of time generating chains you will never need.

This is why I think it is important to do IID by chain length. Or, in your implementation, do staged generation of the chains, shortest first. In my current implementation, increasing the extension of release moves to a full ply, to emulate yours, should never be done in combination with a depth-first search. It would need some dual depth measure, (fullWidthDepth, maxChainLength), where IID would increase maxChainLength until no new chains are found, and only then step up the fullWidthDepth, resetting the maxChainLength to 1.

To slightly reduce the size of that tree you could determine paired but immobile friendly pieces which cannot participate in a chain. That way also other pieces could become "immobile" in a sense that their only pseudo-legal moves would be those that (try to) release an immobile piece. Unfortunately each step of a chain can change the information about which pieces are immobile.

I guess that by clever analysis of the connection graph could save you a lot of time. E.g. in the example above, if you would recognize that the BN form a cycle you could collapse the cycles to 0 steps and allow any piece that steps on one of these squares to immediately move again. This in particularly helps to quickly detect cutoff conditions, such as whether you could capture the King or not.

[petero2]

Look at the following example:
[d]6Q1/8/5B2/3N4/4BR2/2N4k/3P4/8 w - - 0 1
Only the Queen is supposed to be free here; the other white pieces are all paired. Note that Qg3 is checkmate, as the King cannot hug, and cannot escape from being hugged by the Queen. But that is 'hug-in-3' in terms of minimax turns.

Now look what release chains can do. First note that the Knights and Bishops form a 'release cycle': They can alterate BxN, NxB, and after 4 releases get the 'release square' back to where it started. This would 're-activate' the piece that activated them. So after Qxd5-(f6-c3-e4-d5) the Queen is released again (the cycle indicated by parentheses). So the Queen can use d5 as a 'relay point', essentially making two moves. But the pattern of the N & B will have rotated 180 degrees by this, which does not affect their ability to do this. So the Queen can use her second move to step into the cycle at another point, Qxe4-(c3-f6-d5-e4), and the Queen is again activated for a 3rd step. It cannot only emerge from d5, but also from e4! But it doesn't stop there: continue with Qxf4 to release the Rook there, Now the Rook can step into the cycle: Rxf6-(c3-e4-d5-f6), and is re-activated, to go back to f4, activating the Queen for a 4th step. The Queen can also emerge from f6! But it can also countinue the free ride by Qxf6-(d5-e4-c3-f6), then Qxc3-(e4-d5-f6-c3) and finally Qxh3#. A release chain of 26 steps hits the King. There is no other path from Q to K over 'pair squares' than g8-d5-e4-f4-f6-c3-h3, and each step along this path (except the last) takes 4 steps for re-activation.

But now suppose there was a Pawn on d3, blocking the Queens only path to it. We already established a Queen could emerge from any of the pair squares, and certainly a Knight can easily emerge from any of the squares on the B-N cycle. But how about f4? This is a Knight-jump away from the cycle where the Knights are, so there is hope. So start with Qxd5-(...)-e4-(...)-f4, where '...' indicates the B-N cycle (11 steps so far). From there continue with Rxf6 (after two cycles there is again a Bishop there) Bxc3, Nxd5, Nxf4, Qxf6, Rxf4, Nxh3# (18 steps)! This was actually faster than manoeuvring the Queen to c3, and thus could be preferred even without the Pawn.

It seems highly unreasonable to me to require that it should discover these release chains before the simple hug-in-3, just because formally they are hugs-in-1...

How do you know Qg3 is a hug-in-3? The opponent might be able to hug your king in the next move through a 26 step chain, so Qg3 might actually be losing, hugged-in-2.

It seems to me you can never trust a score other than hug-in-1 unless you analyze all possible chains.

[hgm]

True. But that is not really different from any poisoned sacrifice. Once you reach the depth needed to see the catch, the score reverts and you have to try something else. And it might be possible to prove he cannot possibly hug you on the next move. E.g. because your King is not within Amazon range of any pair, and not attacked by a lone piece.

I forged this idea into a mate puzzle (hug puzzle?), where I force white to find the release chain by giving black an obvious hug-in-1 threat. (This is really very much like tsume Shogi...) But imagine the black Queen was on e5 instead of b2. The white King is in Knight-range from c3. But there is no way black could get a Knight there. Black's 'cloud' is very poorly connected; it contains way too many Pawns, nearly all forced chain terminations and the two Bishops of different color. There are hardly any virtual attacks. The only loop is the Pb4-Bc3 reciprocal attack, which makes c3 a one-time relay point. (Accidentally this defends against the mate threat Qg3, but in the puzzle Qg4 is also mate.) So the black release chains are few and of short length. The longest is 5 steps (I think). So while deepening you reach the depth where all release chains of the 2nd half-turn are all within the horizon long before you can see white's King hug through the release chain. At that point the hug-in-2 is certain, and there wouldn't be any need to search white's very long release chains. If this position was not the root, searching on after the hug-in-2 is guaranteed, just to see if you can improve it to hug-in-1, goes at the expense of searching other branches.

In Shogi they have a term for this situation: Hishi = brink mate. It means there is a mate-in-1 threat against the side to move that cannot be defended against (like after 1. Qg4 in the puzzle), but he is not in check. So there still is the opportunity to checkmate the opponent through a series of checks ('tsume'), but after the first non-check he will be toast. Here there is the possibility for black to escape the brink mate through a release chain that results in a King hug.

The dilemma is thus, after you see the possibility to deliver a brink mate, will you go searching for a tsume mate (all checks, so that nothing can happen to you), or will you try to prove that the opponent does not have a viable tsume, so that you will still live the next turn to cash the brink mate. In general you would like to do what is easiest, then you don't have to do the other. To achieve this you could work on the two in parallel (i.e. iterative deepening both sub-trees at the same rate), and the first to achieve the goal will cut off the other. In the worst case this doubles the work, when the two were equally difficult. But in practice the chances that they are equally difficult are slim. Much more often one of the two is a hundred times more difficult than the other (say 1 and 100). Finishing one of the two before you start the other, without knowing which the difficult one was, would then on average take an effort of 50.5. Deepening both in parallel would give you a result with an effort of 2.

But you would not even know you had that dilemma if you had not seen the brink mate first. And by exhaustively searching all release chains already at 1 ply, you have ot seen that yet.

[hgm]

I have made some further progress in understanding this game. An important concept is '(ir)reversible release cycle'. This is a set of paired pieces where virtual attacks of the members can bring you back to where you started. The simplest example of this is two identical pieces attacking each other. The cycle is reversible when you could undo all the moves on a later turn, which is the case if no Pawns are involved. The simples example of an irreversible cycle is a (paired) Bishop (virtually) protected by a (paired) Pawn.

Every pair in a release cycle can be visited by a (lone or released) piece from outside the cycle, which, after 'running the cycle' once will then be released again, to make another move. They can thus be used as stepping stones for serial moving of the same piece, and become 'stations' of a 'transportation network'. The reversible cycle would form the 'core' of this network. An irreversible cycle would be a network that expires after a certain number of uses; e.g. the P-B cycle can only be used as stepping stone once. Reversible cycles can be used an unlimited number of times, by alternately running the cycle forward or backward.

Any paired non-Pawn outside the core that (virtually) attacks a station of the network becomes a station itself. When released, it can jump onto the station it is attacking, be re-activated there by running the network, and then move back to where it came from, reactivating its activator. This expands the network with a periphery.

As an example, take this:
[d]8/7R/2N5/4N3/8/2R5/7B/8 w - - 0 1
All pieces are supposed to be paired here. The Knights at c6 and e5 form the core of a transportation network. The Bishop and Rooks are periphery. To use Rh7 as station for a Pawn at g6, you would play Pxh7, R*xh2 {I use * to indicate it is a later step in a release chain} B*xe5 N*xc6 N*xe5 B*xh2 R*xh7, and the Pawn is reactivated for P*h8=Q.

Note that every piece in the peripheral 'arm' of your network gets released in two different places, once on the way in, and then on the way out. It could choose to leave the network at that point. This might destroy the network for future use, but you would not care if this move finishes the game by hugging the King.

Pieces that use stations to grant themselves an extra step, can do so repeatedly moving from station to station. You can break up the network into sections that can be used for transporting Rooks, Bishops and Knights. E.g. a Knight (if you had a third one...) could use c6 and e5 to get from a7 to g4 in one turn. It could not travel to any other station of this network, but it could use any other station as 'relay'. There are two Rook sections, {c3, c6} and {h2, h7}, and one Bishop section {c3, e5, h2}. A Queen can travel both the Rook and the Bishop sections. E.g. if your Queen is at a6, and the enemy King at g8, you can hug the latter by moving your Queen over the stations c3, c6 {changing trains to the 'Bishop line'}, d5, h2 {changing trains again} h7 to g8. At any station along this trajectory the Queen could also get out of the network, e.g. to hug a King on e7 (if it were there). The network hugely amplifies the Queen's scope.

Note that each of the stations on the mentioned travel scheme for the Queen requires a significant number of release steps for running the network. E.g. to travel over c3 would require Q*xc3, R*xc6, N*xe5, N*xc6, R*xc3, Q*..., i.e. there are 4 extra 'network steps'. So the total length of the release chain can easily be several dozens. Conceptually they are very simple to plan, however. An engine could also use that, to generate release chains in a more efficient and purposeful way. It could detect reversible release cycles, mark the involved pairs and any pairs attacking them as 'stations', and then just generate moves that travel from station to station, without bothering about running the network. Note that 'running the network' to reactivate a station-visiting piece leaves it in the same state. This would not be true for networks that have a core that is a true cycle, rather than just a reciprocal attack of two equal pieces, (e.g. R->B->N->R). Such network cores alternate between two states, depending on the number of stations that have been visited, and the MakeMove() of a station-visit should account for that.

The engine should also realize that every station visit could release any of the pieces in the used peripheral arm and the network core from its station, or from the station it could get through its network link. E.g. by jumping with a Pawn into h7, you could make a Bishop get out at e5 to hug d6 or b8. But this ca probably be done in the process of generating detailed release chains, rather than just generating travel schemes over stations. The travel schemes can give a very deep preview, however, which would be equivalent to extending all releases for running the network by a full ply (without actually doing them). This channels search effort into coherent sequences of releases that achieve something useful.

I am now inclined to think that the best search strategy would use a triple depth-measurement: one ordinary search depth counting turns, and two special search budgets for release steps during those turns, one for each player. Each release step would eat from the special budget for that player, and when it is zero, he would be forced to prune moves that cause a release. The budget would increase during iterative deepening in the root, e.g. as a fixed multiple of the normal search depth (e.g. 4 times that). This would prevent that one player reduces the 'vision' of his opponent by very long but totally pointless release chains, as these only erode his own abilities, and won't affect the opponent. It also prevents undue attention for very long release chains masking easy pickings just a few ply of other moves away.