improve connection games

[RainRat]

1. Change evaluate.cpp to also take into account connectPieceTypes when evaluating how close to connectN
2. Change evaluate.cpp to also take into account connectValue. There's not many misere variants to go on, but reversing the sign is a start.
3. Expand symphony and picaria to not inherit from tictactoe. There was an empty connectPieceTypes when inheriting from tictactoe.

[ianfab]

Thanks. Have you done any playing strength testing on the eval changes? https://github.com/ianfab/variantfishtest is a simple option if you need a tool to run tests.

[RainRat]

1. Taking into account connectPieceTypes when evaluating how close to connectN: Is necessary for a basic understanding of the position. The change would not affect variants that don't use connectPieceTypes. Currently the only variant that uses it is Three Musketeers, which is not a connectN game, but a collinearN game. The change is more to prepare for future games like Align4, which may be worth testing once it is developed.
2. Changing evaluate.cpp to also take into account connectValue.

• Games with connectValue=win would be unaffected.
• connectValue=loss is currently used by two games: Three Musketeers, which would be unaffected because it uses collinearN instead of connectN. That leaves Connect 4 Misere. The suggestion to reserve the sign on evaluation is indeed based on intuition, since one does not want the engine to work toward a loss condition. It's almost just a placeholder for future work, since misere variants may require totally different scaling. I was considering waiting for more misere variants but I didn't want to forget about this. I know AntiLine4 was also mentioned, but don't know if there are any others worth considering.
• connectValue=draw have not considered, since nothing uses it yet. I suppose that it should skip the connectN evaluation entirely.

3. This is more a bug fix since connectPieceTypes wasn't working correctly when inheriting.

So to proceed, I could look into

• Trying to figure out how to scale connectValue + connectN based on just Connect 4 Misere
• Check for connectValue=draw and skip the connectN evaluation.
• Trying to root cause why connectPieceTypes isn't working correctly when inheriting.

[ianfab]

Thanks, if basically no existing variants are affected by the eval changes regression testing is not required. Regarding the inheritance problem, I think this is because you are inheriting from variants with different (connection) piece types, so one needs to override connectPieceTypes in the inherited variants.

For reference, the below code should be what narrows it down to IMMOBILE_PIECE when defining tic-tac-toe, and then further narrows down piece_set(IMMOBILE_PIECE) & CUSTOM_PIECE_1 to an empty set.

Fairy-Stockfish/src/variant.cpp

Line 2077 in f3c982b

connectPieceTypes = connectPieceTypes & pieceTypes;

[RainRat]

It seems the solution is to leave connectPieceTypes unchanged but have a new connectPieceTypesTrimmed in use during the game.

[ianfab]

Thanks, the fixes for evaluation, passing adjudication, and connection piece type inheritance look good to me. However, the optimizations of the connect adjudication are less clear cut to me. As I would like to be able to evaluate the bugfixes and optimizations independently, may I ask you to separate the optimizations into a different PR?

[ianfab]

To link the corresponding items, this PR fixes #800 and #801.