Open Anshroid opened 1 year ago
I was thinking of maybe doing some other notation instead of pgn or just an array* for flash that stores last 10 half moves: you can go back up to and inc. 5 moves during the game but can go back all the way in the game at the end. In terms of input to get it moving, F1 and F6 (grey, metallic keys at the top) are most logical. Something like: std::any halfmove1[5] = ("B", "f", 0, "g", 2, "h", 1); // piece, start file at the very start, 0 for black and 1 for white, file, then rank of the start and file then rank of the end. This has no ambiguity. . . . up to halfmove10 Then, when a move is made, halfmove n -> halfmove n-1 Current thing to halfmove10
Also, one of the biggest issues with any rewind system is how much data you need to store. With both PGN and your system we don't actually know what piece is being captured, so if you rewind how do you know what to replace that square with?
My solution (somewhat comprehensive) is here:
2|52m-1|54kq
2 = Type of piece
5, 2 = Coordinate
m
-1 = Type of piece
5, 4 = Coordinate
kq = King and Queen castling rights
6 ints and 2 bools = 26 bytes
BUT if we encode/store it as a string then its just 12 bytes
En passant/castling is detected and filled in on-the-fly This almost definitely can be simplified, but it's food for thought
10 half moves is enough and that should be done in flash memory. The pgn should be kept in storage. The 10 halfmove thing is basically for takebacks. FEN is complete but if this system is not ambiguous, it should be fine.
Okay. Can we standardise the halfmove format?
Check if your version satisfies all of these: https://en.wikipedia.org/wiki/Rules_of_chess
Figure out how to handle moving back and forth in the move timeline. Refer to #3
There are multiple approaches possible: