05-29-2020, 08:46 AM
@Quentin
If you're still interested in experimenting with this, we have some experimental support for tensor representations for both states and moves. Instead of using the Game and Context objects that we normally use, you'd instead have to use LudiiGameWrapper and LudiiStateWrapper objects. These classes provide some methods to construct these tensors.
I don't have much more documentation on this ready right now, because it really is very experimental and hardly tested. I can point you to some example code that using this stuff... but it's not in Java. It's C++ code accessing the Java classes and methods through JNI. So, it's probably a bit more difficult to read than normal code. But if you're interested in having a look at this experimental stuff, it's right here: https://github.com/facebookincubator/Pol...ames/ludii
Of course we do intend to provide proper information about how to use this stuff once we've gotten around to testing it a bit more ourselves and made sure that it actually works.
Technically a game designer could do so, yes. We generally don't do this explicitly for the games we include in Ludii ourselves though, and we don't like relying on the expectation that game designers would have to do this. Basically we only want to have designers explicitly specifying the rules that are really rules, and not require them to inject additional domain knowledge that emerges from what the real rules are. This design philosophy also helps to facilitate the easy creation of variants of games, and automated generation of new games through evolutionary algorithms. If evolution / manually created variants change a rule in a stacking game, we would want new limits on stack sizes to again emerge automatically from the adjusted ruleset; we wouldn't want an old stack height limit that we artificially added, which in reality should just have been emergent behaviour, to linger.
If you're still interested in experimenting with this, we have some experimental support for tensor representations for both states and moves. Instead of using the Game and Context objects that we normally use, you'd instead have to use LudiiGameWrapper and LudiiStateWrapper objects. These classes provide some methods to construct these tensors.
I don't have much more documentation on this ready right now, because it really is very experimental and hardly tested. I can point you to some example code that using this stuff... but it's not in Java. It's C++ code accessing the Java classes and methods through JNI. So, it's probably a bit more difficult to read than normal code. But if you're interested in having a look at this experimental stuff, it's right here: https://github.com/facebookincubator/Pol...ames/ludii
Of course we do intend to provide proper information about how to use this stuff once we've gotten around to testing it a bit more ourselves and made sure that it actually works.
(05-29-2020, 07:08 AM)dale walton Wrote: In most games, the designer could specify the maximum stack height in a rule.
Technically a game designer could do so, yes. We generally don't do this explicitly for the games we include in Ludii ourselves though, and we don't like relying on the expectation that game designers would have to do this. Basically we only want to have designers explicitly specifying the rules that are really rules, and not require them to inject additional domain knowledge that emerges from what the real rules are. This design philosophy also helps to facilitate the easy creation of variants of games, and automated generation of new games through evolutionary algorithms. If evolution / manually created variants change a rule in a stacking game, we would want new limits on stack sizes to again emerge automatically from the adjusted ruleset; we wouldn't want an old stack height limit that we artificially added, which in reality should just have been emergent behaviour, to linger.