add Gale

[RainRat]

No description provided.

[ianfab]

Thanks. I have some doubts though whether this is worth it, considering that this seems like a very special case and rather many new config values for a single variant, so I currently slightly tend towards not merging this.

However, supporting file wildcards and rank 10 squares in the bitboard parsing of course would be useful, so that might be worth an independent PR. I would just suggest to use a a* syntax for that, since the * was at least by me intended like a wildcard, so *1 means the file is a wildcard, while a* would mean the rank is a wildcard.

[RainRat]

Well, your project so up to you.

The different wildcard for files looks doable.

[RainRat]

Well, I flipped the order in the commit message, but you know what I mean

[RainRat]

Ok, what about instead of four configuration rules, there was a single ConnectionRule config where different connection rules were added as needed.
ie.

# [ConnectionRule]: connection-win rule [cross, cross-rotated, opposite, center, none]
# - cross: white trying to connect north-south, black east-west (ie. Gale)
# - cross-rotated: white trying to connect east-west, black north-south
# - opposite: either player trying to connect north-south, or east-west (ie. Tak)
# - center: either player trying to connect any 4-square corner with 9-square center (ie. Abak)

Any other misc connection rule that was mutually exclusive with the other connection rules could be added here as well.

This config is just an example, I am still only planning to add Gale in this Request.

[ianfab]

I prefer your current approach compared to the new suggestion, it feels more transparent and flexible.

I think there is a bug in your current implementation though if I understand it correctly. It does not seem to check whether the starting zone is occupied, it just loops over all starting squares. That is also where I think the implementation could potentially be much more efficient. E.g., one could first determine the two var->connectRegion1[~sideToMove] & pieces(~sideToMove) and var->connectRegion2[~sideToMove] & pieces(~sideToMove) and both have to be truthy to have a chance of connecting at all.

And one could then beyond that probably also check the connectivity on a Bitboard level, basically the same as you do now, just not doing it per square, like

if (   (var->connectRegion1[~sideToMove] & pieces(~sideToMove))
    && (var->connectRegion2[~sideToMove] & pieces(~sideToMove)))
{
    Bitboard target = var->connectRegion2[~sideToMove];
    Bitboard current = var->connectRegion1[~sideToMove] & pieces(~sideToMove);
    while (true)
    {
        Bitboard new = 0;
        for (Direction d : var->connect_directions)
            new |= shift(d, current | new) & pieces(~sideToMove); // the "| new" here probably saves a few loops
        if (!(new & ~current) || (new & target))
            break; // either got stuck or succeeded
    }
    // check result
    ...
}

Not necessarily the best implementation, but might be a rough direction one could go towards to speed it up.

Edit: Doing the same from both sides and doing a meet in the middle might potentially be more efficient, but haven't really thought much about it.

[RainRat]

1. The ConnectionRule suggestion. I am just looking ahead. Adding the four zones is still a fine solution for the game I want to add. I had a look at Ludii at Connection games. Besides hexes and more complicated geometry there was:

• Crossway, Gale, Resolve, Scaffold, Tara, Troll - would be covered by proposed "cross" or "cross-rotated"
• Gonnect, Tak - would require an additional rule configuration anyway to specify that either player can connect north-south, or east-west.
• Abak - connect any 4-square corner with 9-square center. would require an additional zone and an additional rule configuration to specify how it interacts.
• Pippinzip, Pippinzip (Zipline) - "If Black connects any two sides of the board with a single orthogonally-connected group, they win; White wins if they connect all four sides with a group connected either orthogonally or diagonally." at least one additional rule configuration.

2. Starting zone occupation. Yes, I just tested with Gale, where both sides are guaranteed to be occupied. Using your suggestion.
3. Bitboard optimizations. Using your suggestion.
4. Reserved word "new" can't be as a variable name. Changing your suggestion.
5. I understand what you mean by meeting in the middle. If you think it's worth it, I can take a shot.

[ianfab]

Thanks, it looks good to me now. However, after merging the other PR this now seems to have merge conflicts to resolve.

[RainRat]

I think this solves the conflicts.