AI: Implement Barricaded Subgame

[ghost]

"Middle Game" starts when Black has completely or nearly formed all barricades around the four corners.

Black: Form cordons, if possible, and squeeze the mobility and reduce the number of white pieces until King is captured. Meanwhile, do not let white get into formations to force a draw, and let white pierce through any barricade(s) or cordons it has created.

White: Pierce through Black's cordons and barricades. Preserve enough pieces to force a draw while dwindling number of Black pieces, so it must force a draw or break open its flanks. Also, get into formations to preserve number of pieces.

[apotapov]

Travis said: I moved this comment you had previously to another issue: Corner Control.

[ghost]

1) Preserve minimum MB (depending on # of white pieces). Black needs a minimum of pieces against white's remaining forces to win the game. 2) lengthen barricade(s) until black blocks white on one side of board (cordon formed). Then, block two sides. Then, three. Watch out for center square where black cannot occupy. 3) Do not let white form a loop around the King to form a shield force a draw. Sometimes, white can use an edge to complete the loop, which is called a fort. 4) Trap the King against an edge or in a black loop if possible 5) Stop white from forming formations, such as towers 6) Only give up a corner if you absolutely have to, e.g. to complete a cordon, capture a King, or if there just aren't enough black pieces.

Q: In Feltar Tafl (or even other versions), can a player offer a draw like in Chess? Or must you play it out until conditions of a draw apply? This matters. For example, let's say Black has all corners barricaded, but he doesn't have enough pieces to form a Cordon, and white has a lot of pieces left. Can Black offer a draw, or must he play it out, which will further his chances of a loss--rather than just have a draw.

NOTE: This is a first stab description of heuristics. It's not complete nor do we have to implement all of them. I need to go into more details, so they are programmable.

[apotapov]

I'm just thinking out loud here:

The hard part about things like closing the loop and extending barricades is that we can only evaluate the static state of the board at any given time.

So the type of question we are answering with the eval function is, did the previous move make me better or worse off.

Since we only have a 2 move look ahead, this means that we need to lengthen the barricade in two moves.

What does this mean practically? If you have a barricade in place, adding a piece to the 1st rank or file, would be good, because that allows to move the next piece up without compromising the barricade. Once you have closed off the connection between two barricades, now you have to start advancing the cordon. One way to do that would be to increase the value of squares right in front of the cordon. So it's basically a slow shuffle ahead. We have to be careful here though, because we don't want other pieces on the board to start stacking in front of the cordon creating a double layer.

Perhaps one way to do that is to do that is also devalue the squares that the the cordon is on and the ones that are behind the cordon, so that pieces are moving forward and not back. Again, this is easier said than done.

Because we are looking at a static picture every time we are evaluating.

I'm wondering if there's a simple way to figure out by looking at the static picture whether we are doing well or not with the cordon..

[apotapov]

I'm keeping this bug for posterity because of good comments here. But this will not be done for release.

[apotapov]

On the second thought... Closing