02-13-2021, 02:14 PM
(This post was last modified: 02-13-2021, 02:52 PM by dale walton.)
The 2nd point, sounds like killing a fly with a sledge-hammer for most games, even if it is a pesky fly. From a practical point of veiw, added depth could be more important to play than blunders - but could you give the author control of how many previous states to track before giving up?
Or better: maybe store the previous state's hash value as one element of the hashed current state, which should solve the problem by its recursive nature without adding much overhead.
-----------------------------------
OK I see that's too strong a definition of game state - No game would have a repetition under a definition that included its entire history as being part of its state....
But something similar could be done to find repetitions of specific periods but each period would need a separate hash, which would get very heavy fast.
-----------------------------------
Another point. I did a search, and the "repeat in game" in my script is dead code, and the entire define "Finished" can been removed. Ithink I wanted to use it to make the game finite, but it may have given some problem so I took another approach and forgot to review it.
So it may be important for the Ludii environment, but doesn't have to do with this issue.
"The use of such rules essentially means that really the entire history of all game states that have been encountered so far is an important aspect that must be factored into the current game state."
Well... The use of such a rule means that the tree search must include a procedure that compares game states e.g hashes. -- And not factored into the current game state
The state is what actually happened. I don't know of strategy games where what could have happened really means the position is in a different state from the point of view of using a state history comparison. Deduction games?? i.e. the state of the game includes what is known when? -- But repeat in Game, etc, are not relavent to that.
Or better: maybe store the previous state's hash value as one element of the hashed current state, which should solve the problem by its recursive nature without adding much overhead.
-----------------------------------
OK I see that's too strong a definition of game state - No game would have a repetition under a definition that included its entire history as being part of its state....
But something similar could be done to find repetitions of specific periods but each period would need a separate hash, which would get very heavy fast.
-----------------------------------
Another point. I did a search, and the "repeat in game" in my script is dead code, and the entire define "Finished" can been removed. Ithink I wanted to use it to make the game finite, but it may have given some problem so I took another approach and forgot to review it.
So it may be important for the Ludii environment, but doesn't have to do with this issue.
"The use of such rules essentially means that really the entire history of all game states that have been encountered so far is an important aspect that must be factored into the current game state."
Well... The use of such a rule means that the tree search must include a procedure that compares game states e.g hashes. -- And not factored into the current game state
The state is what actually happened. I don't know of strategy games where what could have happened really means the position is in a different state from the point of view of using a state history comparison. Deduction games?? i.e. the state of the game includes what is known when? -- But repeat in Game, etc, are not relavent to that.