01-30-2020, 10:45 AM
Quote:If to determine the next state, the game needs to access the game history, then the game is not Markov. Anyway, a "isVisualMarkov" method would already be interesting.
Sure, but technically we include quite some parts of the game history as part of the game state representation. So that makes the term a bit ambiguous.
Quote:game.hasSequenceCapture() seems to be what I'm looking for. However, is there also a method to know if we can jump over a piece that has already been taken, that is to say to discriminate games such as International Draughts with games such as Coyote ?
Ah, no. In principle that's exactly what game.hasSequenceCapture() already tells you. If that method returns true, it means that captured pieces are only marked as captured, but not yet removed, until a turn has been fully completed. So if the rest of the game's rules allow it, this would mean you could hop back over that piece.
The thing with International Draughts is that, in the move rules in its .lud file, we also have the following snippet:
Code:
(not (in (step) (captureSequence)))
Also not that this rule is not necessarily a game-wide rule. The same holds for the hasSequenceCapture() that we already do have by the way. It just means that at least some of our move rules somewhere in the game use this mechanism where pieces don't disappear right away. But technically it could be possible that there are also different move rules in the game somewhere for which this does not apply. For instance, we could imagine a variant of International Draughts where the regular Man pieces do use this mechanism, but the Dame pieces do not. Or the other way around.
Quote:It's not what I'm looking for. A game with hands usually requires count. Thus, with a game which requires count and has hands, I cannot know if the board requires count. Maybe there should be a requieresCount for each container?
Ah, I see what you mean. Currently this actually is a game-wide property in Ludii. As soon as one of the containers (like a hand) needs support for counts at sites, ALL of the containers in that game will support counts at sites.
We would very much like to look into making this a per-container property, because indeed we -- as humans -- know that for many games only the hands really need counts, and the larger boards don't. If we find a way to detect -- given a game's .lud description -- that some containers will never need support for counts, we can take this into account for our state representation and get improvements in speed and memory-efficiency for these games. We're not sure yet if or how we can automatically determine this from any given .lud description though. Essentially we need to be able to prove that a set of rules will never allow for moves to be generated that increase the count beyond 1 for any site of a given container. This is often easy to see for humans when reading the rules, but a bit more difficult to really rigorously prove in an automated way.
So... if we find a way to do that, absolutely we will, but we're not yet sure that that will happen (any time soon).