Multi-move turns vs multi-part moves

[alexobviously]

This is basically just for myself so I can write out what's in my head for future reference and to clarify stuff for myself, but if you come across this feel free to join in.

For a while I've been wanting to add support variants that have more complicated turns than 'white moves a piece, black moves a piece, etc'. For example, 'white moves a piece, white moves a piece, black moves a piece, black moves a piece', or 'white moves a draught, and if there's another capture for that draught to make then it makes it'. What's been slowing me down is determining whether these are two completely different concepts, and how so, and how to express them in data structures.

Basically the conclusion I've come to is that there are broadly two things that need supporting: multi-move turns and multi-part moves, but the latter is kind of a specific case of the former, where the piece for parts of the move after the first part is restricted to the piece you moved in the first part. At first, I though they should be completely separate things, something like this:

• Multi-move turns are expressed in multiple different state objects, and we somehow express that the turn has not changed but the 'chain' or whatever has increased.
• Multi-part moves are in a single state, in a specific move type called MultiMove which has child moves (I even wrote some of this code).

And then I thought: well actually aren't multi-part moves just a special case of multi-move turns? Why not just do them in the same way?

Just now as I'm writing this I'm realising a huge drawback which is how complicated it will be if there's a variant with both multi-part moves and multi-move turns, so I don't like it any more and am thinking about going back to the original way where they are separate.

Drawbacks of the separate way:

• Added complexity (two systems to understand and maintain instead of one)
• Traversal of multi-move states in clients is going to require some new stuff, but there would have been new stuff anyway

Drawbacks of the special case way:

• Makes having both rule types present in a variant very complicated
• Breaks some rules like counting draws (does the other way too?)
• Breaks zobrist hashing maybe?

So I think I'll do it the separate way. I'm going to start with double move/marsellais chess and then duck chess (since the rest of that is done already).

Implementation details/questions:

• How to encode turn and sub-turn now - this kind of needed changing anyway cos it's kinda weird that we only have fullMoves in BishopState. I guess I'll make it literally just int turn and int part, where turn means which turn we're on in the game, e.g. 1. e2e3 e7e6 2. e1e2 e8e7, we are now on turn 4 (0-indexed), and part will always be 0 in standard chess. Duck chess: 1. e2e4,*@a3 e7e5,a3a4 2. d2d3, we are now on turn 2, part 1 (2/0 was d2d3).
• Hashing changes? Probably not that important but I guess part contributes to the hash.
• Needs to be some sort of function that can be supplied, which determines when to switch turn. I think this is the right way, cos it allows quite simple stuff and complicated stuff and we can write these cases as we write the other customisable functionality like drop/promo options etc.
  • Standard chess is (state) => true (or maybe null, idk how this affects optimisation?)
  • Double move (unbalanced) is (state) => state.part==1 (or would it be ==2? are we analysing the state before or after the move? I think it's probably after since we need to know about the result of the last move in some cases; also my paranoia says >=2 lmao)
  • Double move (balanced) is (state) => state.part == (state.turn == 0 ? 1 : 2)
  • Progressive is (state) => state.part == state.turn + 1
• How to determine which types of moves can be made each turn. This is the main obstacle imo. How, in move generation, do we know, for example, that we can only move the duck in part 1 and cannot move the duck in part 0?
  • Oh man maybe with an action of type beforeMove that invalidates moves? Lol kinda obvious really.

Seems solved? Cool I'll do this, and forget multi-part moves for now and do it separately in a while.

Problem:
BishopState already has turn, which means the player whose move it is, and it's used in a load of logic so probably shouldn't change it. But the question is how to name/encode these three related bits of information:

• Whose turn it is (turn)
• What turn/move number we're on
• What part of the turn it is

Could just have fields for all of them for now since the rules will be relatively simple, but I'm just thinking that at some point I'm likely to make states reference parent states, which could be traversed to figure some of this stuff out (particularly turn/move number), but I don't know whether I want to do that anyway because it might have some performance repercussions and it's not like users are manually manipulating that part of states. Also is turn derived from move number now? Is that futureproof?

Also BishopState.fullMoves is obviously redundant now because it can be derived from move number (~/ 2).

There's some logic to be figured out with like incrementing all of these things but I think it can probably be encapsulated and hidden from the user behind this bool Function(BishopState) turn decider function thingy

[CallumBeaney]

I like ducks but geese I do not appreciate so much

[alexobviously]

that's racist

[alexobviously]

Problem I still need to solve but have some idea of how to do it: checkmate checking. Imagine double move chess, and moving into check in the first part of your move; the checkmate check won't care about next move because it's from the same player

actually I'm half asleep, maybe it works

also pgn output, and preserving enpassant across parts (if you double move a pawn on part 0 it should still be enpassantable next turn)