Variant Abstraction

[JonKo314]

As demonstrated in commit 01c399f982b3ac09000481708fc0b6f4d1b3dbfc variants can share some parts of code. Abstractions like this reduce code redundancy and should make it easier to add similar variants.

The commit introduced an examplary class AbstractAlternatingBlackWhiteOnGridVariant, which was used as superclass for the Baduk and TicTacToe variants. Other variants call for more considerations on how to achieve a better form of abstraction:

A couple of high level design thoughts:

• Is this method of creating an intermediate subclass composable?
  • Example: HexGo might be described as an AlternatingBlackWhite variant, and Go Battle Royale might be described as a Grid variant. If we had two subclasses AlternatingBlackWhiteVariant and AbstractGridVariant, is it possible to compose the two into AbstractAlternatingBlackWhiteGridVariant?
• As far as minimizing redudancy between Go and TicTacToe, it's definitely a useful exercise, but I don't think we want to go too deep into TicTacToe specifically as it was just a demonstration for how a game can be added.
• Looking at the list of games we wanted to focus on in the forum thread, only Pyramid Go fits the AbstractAlternatingBlackWhiteGridVariant
  • Go Battle Royale (grid, cycle/simul?)
  • Simultaneous Fractional Multicolour Go 2 (grid, simul)
  • Thue-Morse (Fair Sharing) Sequence 2 (grid, 2player, but not alternating)
  • Diplomatic Go (simultaneous moves) 3 (grid, simul)
  • Pyramid Go 3 (grid, alternating)

Originally posted by @benjaminpjones in https://github.com/benjaminpjones/govariants/issues/27#issuecomment-1188069005

Also worth mentioning are thoughts on abstraction expressed in the OGS forum.

[JonKo314]

HexGo might be described as an AlternatingBlackWhite variant, and Go Battle Royale might be described as a Grid variant. If we had two subclasses AlternatingBlackWhiteVariant and AbstractGridVariant, is it possible to compose the two into AbstractAlternatingBlackWhiteGridVariant?

Maybe we could achieve that with mix-ins? Or additional generic types? Or a library for utilities?

[benjaminpjones]

I think a library is going to be simplest, and seems like something we're going to need to do for some things anyway (I was already thinking map2d(), copy2d(), fill2d into a grid_utils.ts)

But I'd definitely like to see how mix-ins might work. Without knowing much about them, it sounds like it's possible to have something like this?

class TicTacToe extends GridMixin(AlternatingMixin(AbstractVariant)) {
    ...
}

class BattleRoyale extends GridMixin(PlayersCycleMixin(AbstractVariant)) {
    ...
}

[JonKo314]

Yeah, I've never used them either, but that seems to be the idea.

I've thought about AbstractGame.playMove() again and I think it's a good idea to internally split up its behaviour. To the outside (public perspective) it says to use this method when someone wants to play/submit certain moves, on the inside (protected perspective) it establishes a structure how to handle this by default[^methodNames]:

• preValidate() does some shallow validation checks. It ensures we can proceed to the next step. Baduk examples:
  • Checks whether it's the player's turn to add a move.
  • Checks whether the intersection where the stone should be placed is free.
• playMoveInternal() applies the moves to the game state, so the outcome can be validated. Baduk example: Places stone and removes opponent groups without liberties.
• postValidate() validates the resulting game state and aborts the whole moves submission if that is not the case. Baduk example: Checks whether a move was illegaly suicidal (i.e. has still no liberties because no opponent groups were removed).
• prepareForNextMoves() does whatever needs to be done so the next moves can be played. Baduk example: Ensures nextToPlay() from now on returns the player who's allowed to play a move next.

This should work for most variants where players take turns in series, but for parallel variants (players make moves simultaneously) prepareForNextMoves() should probably be called outside playMove(). Technically it would work to indroduce a special (automated) player who submits a move to end a round, but it would be more intuitive to just change/override playMoves().

Can you think of any good changes to this structure?

[^methodNames]: I'm not sure about the current method names, maybe we can think of something better.

[merowin]

I believe it is possible to split the parts of a variant into pieces in such a way, that these pieces can be implemented differently but compatibly with each other. One way of doing so is by logically splitting the game state into pieces that are largely independent of each other, and then split the transition function in the same way, i.e. have a transition function for each individual piece. Say for example that for a 2-player variant, the game state consists of a grid board and one number that is either one or two, indicating who is on the play. We write two functions, both take possible moves along with the current game state as input. One maps to the new grid board position, one maps the other part, which defines who is next on the play. Of course it won't always be easy / possible to logically separate the rules in such a way.

As far as programming is concerned, interfaces might be an option to define a "blueprint" for an object that defines specific parts of the variant. Class inheritance or mix-ins might also be useful, I must admit that I don't have much experience with those.

[JonKo314]

Good point, that should work at least in some cases. If it's hard for specific variants, we can always handle them separately by just extending AbstractGame.

I've revisited mix-ins and I don't anymore think that they are what we want to combine parts of variants like mentioned above. To me it seems they are used to add properties to a class, but what we want is to change the bevhaviour. Maybe generics are better suited for our purposes.

[JonKo314]

Some insights in what functionalities certain variants would need:

• Go Battle Royale
  • capture go
  • Predefined/semi-random starting position
  • Multiplayer (one color per player)
  • cyclic turn sequence
• Simultaneous Fractional Multicolour Go
  • fractional coloured stones
  • multiplayer
  • simultaneous moves
    • collision handling: merge stones
• Thue-Morse (Fair Sharing) Sequence
  • Baduk
  • but Thue-Morse sequence
• Diplomatic Go (simultaneous moves)
  • simultaneous moves
    • collision handling:
      • passes
      • or players submit alternative moves along with preferred move
      • or something else
• Pyramid Go
  • Baduk
  • but Pyramid scoring (more points if closer to the center)
• Flexible Variant
  • configurable stones
  • add or remove multiple stones per turn
  • sequence?
  • Parallel
  • undo
• Werewolf Go
  • multiplayer
  • teams
  • display colors differ from real team colors
  • players only know team colors of some players
  • cyclic turn sequence
• Detective Go
  • multiplayer
  • one color per player
  • one player places stones that only they can see

[benjaminpjones]

Is there anything actionable in this task at this time? Or can we close it?

My thoughts are - it's definitely good to dedupe functionality where possible, but it's not a once-and-done kind of thing

[JonKo314]

Is there anything actionable in this task at this time?

I don't think so.

it's not a once-and-done kind of thing

Good point!