Do we need a Tafl Programming Wiki?

I thought I’d start this discourse with discussing things related to the wiki I mentioned over on discord.

Since there wouldn’t be much to put on there, I think it’s probably enough to use the Discourse as a temporary knowledge base. If the time comes we can collect the information from here and put it on the wiki.

Here are some things specific to Tablut that I discovered during the development of my engine and which I think might be worth noting in the potential wiki.

  • Null Move Pruning doesn’t seem to be a good optimization*
  • Quiescence Search takes too much time and thus doesn’t seem to be a good optimization either*
  • Considering symmetry via canonical hashing is only worthwhile in highly symmetric positions (like the starting position)

* This might be my fault as well, the implementations were relatively naive test implementations and no further optimizations were attempted. For example, Quiescence Search didn’t calculate any King moves if it didn’t result in captures, which might be important (even though I doubt that the few King moves that pop up are so good that they outshine calculating captures only).

Feel free to share your thoughts.

The claim that quiescence search is not good has been refuted. With proper move ordering and quiet / loud move classification, quiescence search is a strong but not groundbreaking optimization. It primarily reduces the horizon effect and improves pruning, but it doesn’t seem to increase engine strength as much as it promises.

Another important discovery that I made: LMR can be applied asymmetrically. If the move ordering for the defending side is good enough, you can apply LMR to every move but the first one (for the defenders only). For the attackers, applying LMR later is a bit better (around move 4). I also tried applying the LMR reduction asymmetrically, but that didn’t prove to be useful.
This drops the effective branching factor of the defending side down to 0.2-0.5 in some positions, which is excellent.